FPDF indice faux

Bonjour à toutes et à tous, J’ai deux pages, une admin et une ouverte au public. Les mêmes "mécaniques" envoient un indice via un bouton. Côté admin, avec les mêmes éléments, les mêmes images, le même script JS, le même traitement FPDF que pour le public (mais moins de renseignements), pour éditer une fiche et tout fonctionne bien pour tous les éléments demandés. Côté public certains PDF s’affichent bien mais beaucoup me font une erreur "Fatal error: Uncaught Exception: FPDF error: Unsupported image type: /img/img-coins/" ? J’ai cherché depuis des jours sans savoir comment un indice prêt à envoyer "0100122", qui fonctionne parfaitement côté admin, arrive "32850" côté public quand j’inspecte le modal ??!! mais certaines fiches fonctionnent bien, dans le même contexte, leur indice est correct !!!! Le MSG ERR donné ne m’apprend rien car ce n’est pas le format d’image qui est incorrect, la même img et le bon chemin sont utilisés dans les deux cas, mais c’est la clé que j’envoie qui arrive erronée et donc ne trouve pas la ligne correspondante dans la base (clé composée 2+5 chiffres) et plante le traitement FPDF. Auriez vous une idée ? Lien vers le site

Salut

Plutôt qu’un lien vers ton site, il nous faudrait plutôt ton code afin de pouvoir y jeter un œil neuf, non ?

Salut. Grave erreur dans ma panique. Mais tu l’as vue…

Non, je ne l’avais pas vue jusqu’à ce que je voie ta réponse.
Le nombre est juste, simplement dans deux bases différentes… Il faudrait éviter de mettre les zéros initiaux quand tu envoies la valeur.

Merci de ta réponse. Non Ymox c’est pas ça ! J’ai pas deux bases !!! à quoi ça servirait une base s’il faut la doubler à chaque page ! Ce ne sont pas les zèros du début car, je te l’ai dit, la même fiche FPDF fonctionne côté admin et pas de côté public, enfin, en public elle fonctionne sur certaines listes et pas d’autres ??? alors qu’il n’y a qu’une seule moulinette pour toutes les pièces Tu penses bien que j’ai essayé de changer le 0 en 6… J’ai vérifié ma base, changé pas mal de code, fouillé où je pouvais sur le net, mais c’est pas ça. Comment un indice 0100122 arrive en 32850 côté public, donc tombé du ciel je suppose, et parfait (0100122) de l’autre ?! De plus, si tu as inspecté côté admin (que je suis con d’avoir montré mon fichier FPDF test ! Bref passons.. en plus personne ne me l’a dit !). J’ai essayé de trouver une séquence mais rien qui puisse m’aiguiller… Quand je saurais je te dirais, ça joue ? ;-)

Salut @Gregor,

Il y a incompréhension entre vous. Quand on parle de deux bases, ici, ce ne sont pas deux bases de données, mais deux bases au sens mathématique du terme. Et c’est en effet la cause du problème.

Explication du problème : les bases (au sens mathématique), ou comment compte-t-on ?

Usuellement, on compte en base 10, c’est à dire qu’on utilise dix symboles pour noter les nombres (0, 1, 2, 3, 4, 5, 6, 7, 8, et 9). Le nombre après celui noté 9 (en base 10), c’est… 10 (le nombre des unités repasse à zéro, et on ajoute un chiffre à gauche, qu’on appelle communément une dizaine). Rien de surprenant jusque là, c’est comme ça qu’on compte depuis tout petit.

Mais le choix de dix symboles est totalement arbitraire. C’est pratique, on a dix doigts, tout ça, mais on pourrait totalement repasser à zéro et ajouter un chiffre à gauche à un autre moment (en ayant plus ou moins de symboles pour écrire les nombres). Par exemple, on pourrait se contenter de deux symboles (base 2 : binaire, les deux symboles étant typiquement 0 et 1), ou seize (base 16 : hexadécimal, les symboles étant les chiffres de 0 à 9, ainsi que les lettres A, B, C, D, E, et F).

Ou 8 symboles (base 8 : octal, les symboles étant 0, 1, 2, 3, 4, 5, 6, et 7).

Compter en octal, c’est comme en décimal, sauf qu’on ajoute une “dizaine” (une octaine ? — bref, un chiffre supplémentaire sur la gauche) quand on atteint le dernier symbole, soit 7.

Donc, en base 8, le nombre après 7₈, c’est 10₈ (quand on veut être explicite, on note la base utilisée en indice, comme ci-avant : je le ferai à l’avenir pour être extra clair). Le nombre représenté par “10₈” (en base 8, donc) étant le même que celui représenté par “8₁₀” (en base 10) : c’est exactement le même nombre, le même concept numérique, seule sa représentation est différente — tout comme on pourrait le représenter par le texte huit, ou par “••••••••”.

Différencier les bases en informatique, ou l’origine du problème

Le souci comme on l’observe plus haut, c’est que pour certains cas c’est difficilement différenciable. Le nombre 100122_?? pourrait être écrit en base 10, ou 8, ou même en base 3 (avec les trois symboles 0, 1, et 2 : même principe que plus haut, on compterait dans l’ordre 0₃, 1₃, 2₃, 10₃, 11₃, 12₃, 20₃, etc.).

Pour différencier, il y a des conventions. Un nombre écrit en base 16 (hexadécimal) est préfixé par “0x” : si on donne à plus ou moins n’importe quel langage de programmation un nombre commençant par “0x”, il sera interprété comme un nombre en hexadécimal. Par exemple, en JavaScript (mais ce serait pareil dans n’importe quel autre langage !) :

>> console.log(0x100122)  // Base interprétée : 16
1048866

JavaScript n’affabule pas, ici : il interprète simplement le nombre 100122 en base 16 (donc en considérant qu’après le nombre 9₁₆, vient le nombre A₁₆, puis B₁₆, etc. jusqu’à F₁₆, suivi de 10₁₆ (qui correspond à 16₁₀). Par contre, l’affichage, lui, est toujours fait en base 10 (JavaScript affiche quelque chose qui nous est naturel). D’où l’impression que JavaScript lit mal le nombre, mais non, tout est bon.

Là où c’est plus fourbe, c’est que pour l’octal, la base 8 donc, une convention similaire existe : préfixer un nombre par un zéro est une convention pour dire que le nombre qui suit est en base 8.¹ Par exemple, avec l’exemple plus haut :

>> console.log(10)   // Base interprétée : 10
10

>> console.log(010)  // Base interprétée : 8
8

Et je te le donne en mille :

>> console.log(100122)   // Base interprétée : 10
100122

>> console.log(0100122)  // Base interprétée : 8
32850

Piste de correction

Le problème vient donc qu’un nombre pourtant en base 10 est interprété comme étant en base 8, à cause du zéro en préfixe. Je ne peux expliciter comment corriger cela sans savoir quelles technologies sont utilisées, mais l’idée sera toujours la même.

1. Quand des nombres sont lus depuis un ou une utilisateur/ice, expliciter qu’il faut les interpréter comme étant en base 10. La méthode va changer d’un langage à l’autre, mais c’est généralement un paramètre d’une fonction de conversion de chaîne de caractère vers nombre. Par exemple, en PHP, c’est le second paramètre d'intval :
   // Explicite qu'on est en base 10 : le langage ne tentera pas de deviner (mal).
   // On peut imaginer que le texte "0100122" viendrait du formulaire utilisateur.
   >>> echo intval("0100122", 10);
   100122
   

2. Préfixer les nombres par un ou plusieurs zéros pour les aligner, c’est un problème d’affichage, pas de stockage. Les nombres seront stockés comme des nombres, non préfixés (en réalité, ils ne seront même pas stockés en base 10, mais certainement, en base 2 : en binaire). À l’affichage, on explicitera qu’on veut un padding de zéros. C’est une option classique de formatage. Toujours en PHP, on pourra utiliser sprintf, ou tout autre fonction ou outil de templating utilisant la même syntaxe — cela dépendra, toujours, des outils utilisés.
   // Affichage du nombre en 7 caractères, quitte à ajouter des zéros si besoin
   >> sprintf('%07d', 100122);
   0100122
   

Si les technologies utilisées sont explicitées, la réponse pourra être précisée . Vue la tête des messages d’erreur, je repère PHP, mais en fonction de la présence ou non d’un moteur de template (Twig, Blade…) ou d’un framework (Symfony, Laravel…), la correction précise changera.

Bon sang ! Alléluia ! Bonjour à toutes et à tous…
J’avais envisagé une piste du genre, j’avais divisé, multiplié l’un par l’autre, pour voir s’il y avait moyen de redresser ça en cas de résultat favorable, mettre une règle, une conditionnelle… Je m’arrachais le peu de cheveux qui me restent, en vieux développeur cobol/rpg de la fin du siècle dernier s’attaquant au web En ce sens, je parlais même de la main de Dieu P….. ! BASE oui, mais base 8. Merci, merci je me jette sur cette piste "octo" presto ! Cependant une bonne partie des pièces passait bien dans ma moulinette… J’en avais mal à la tête !!
Et, de plus, j’ai, à un moment, changé ma base de MyISAM en ImmoDB, puis, suite au problème, revenu en MyISAM… est-il possible que ma base soit corrompue ? Oui PHP pour arriver au traitement FPDF (pas simple le garçon, pointilleux comme pas deux)
Bref j’y vais et je vous dis…
Merci encore de votre aide et de votre disponibilité et bonne journée à toutes et à tous.

le javascript :

  function afficherFiche2(element_id) {
    var string = './php/fiche_pdf3.php?indice=' + element_id;
    url_pdf = document.getElementById('source_pdf');
    url_pdf.src = string;
    dialog.showModal();
  }

  var dialog = document.getElementById('mydialog');

Et le fichier FPDF. Là je ne suis pas sûr du "string()" et de la suite sub. Je ne sais pas s’il interprète du txt ou un entier ?

$new_pdo =              $dbco = new PDO("mysql:host=$servname;dbname=$dbname", $user, $pass, array (PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'utf8'"));
                        $dbco->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
function fiche_piece()
                      {
                        $string = strval($_GET["indice"]);
                        $volume = substr($string,0,2);
                        $page = substr($string,2,5);
                        global $dbco;
                        $sth = $dbco->prepare
                        ("
                          SELECT p.nom_pays, c.date_edit, c.tirage, s.serie, c.volume, c.page, c.dispo, c.etat, c.vendeur, f.date_achat,
                          f.prix, f.id_facture, c.nom_piece, c.img_1, c.def_piece, c.img_2, c.id_piece
                          FROM coins_list c
                          LEFT JOIN coins_series s
                          ON c.id_piece = s.id_piece
                          LEFT JOIN pays p
                          ON c.id_pays = p.id_pays
                          LEFT JOIN confdef f
                          ON c.id_piece = f.id_piece
                          WHERE c.volume = '".$volume."' AND c.page = '".$page."'
                        ");
                        $sth-> execute();
                        $resultat = $sth->fetch(PDO::FETCH_ASSOC);
                        $sth->closeCursor();
                        return $resultat;
                      }

Re bonjour,
J’ai beaucoup prié, vous m’avez montré la voie. J’ai trouvé la foi !
Il m’a fait "insigned" et m’a dit « ce n’est pas la "clé" du paradis, changes-la et "zéro file" de là».
Et le miracle se produisit… Alléluia. Alléluia… En vérité je vous le dit : je crois en vous et ne cesserai de faire vos louanges.
Merci à Saint Imox et Saint Amaury de leurs interprétations de l’évangile selon MySQL.
Votre obligé. Bonne journée à toutes et à tous.

Pour les non croyants
J’ai changé la clef qui me donnait les PDF, au départ une clef multiple qui avait un usage particulier côté admin (là j’ai rien changé…) avec des 01, 02, ou 66 ou plus (les 66 ou + fonctionnaient, mais comme sur l’autre page les 01, 02 ne posaient pas de PB je me suis buté à les conserver).
J’ai mis une autre clef, simple, dans ma moulinette et enlevé les "zerofill" dans ma table MySQL.
Mais je ne sais toujours pas comment éviter ces transformations (base 8 ou bas 10), je pense à mon javascript, particulièrement. Je verrai… un jour…
Je voudrais remercier la bienveillance des intervenants de ce forum.
Je vois tellement de réponses lapidaires sur les autres, genre on te répond en un temps record «si tu avais consulté cette doc , tu saurais»… Lui, on lui demande l’heure dans la rue il répond «achètes toi une montre !»
Franchement, avant de consulter un forum, perso, je fouille pendant des heures et je craignais ce genre de réponse qui n’en est pas une…
Mais ici, non ! Merci encore pour cela.