cs_zeguizmo
Messages postés138Date d'inscriptionvendredi 1 août 2003StatutMembreDernière intervention16 juillet 2009
-
19 juin 2008 à 18:08
cs_zeguizmo
Messages postés138Date d'inscriptionvendredi 1 août 2003StatutMembreDernière intervention16 juillet 2009
-
19 juin 2008 à 22:34
Bonjour à tous !
J'ai un petit problème avec une requête là, ca fait deux heures que je suis dessus, et pas moyen de voir ce qui merdouille :)
Je fais des tests, et dans mes tests, je tape un peu n'importe quoi pour voir ce qui passe.
Symptômes : Pour un champ texte tout con, limité à 64 caractères en base de données, j'entre 44 caractères :
)à'ç&é)"(ç_à&é"à'_&éà"'_é&à'"_éàç"_'àé"&'_)
Et la requête d'insertion de ce champ dans la base passe sans problème.
Le même champ texte, j'entre 57 caractères :
)à'ç&é)"(ç_à&é"à'_&éà"'_é&à'"_éàç"_'àé"&'_)àé"'_à'àé_"')
Ca merde.
Le code :
$mysqli = $this->db;
$puName = $mysqli->real_escape_string($this->getName());
$queryInsert = "INSERT INTO publisher (pu_name) VALUES ('$puName');
if ($mysqli->query($queryInsert) === false)
throw new exceptionErrorDB(DB_UP,$queryInsert,__FILE__,__LINE__);
Vous l'aurez compris, je travaille dans la classe publisher et cette requete ajoute un éditeur à la base de données. Il n'y a aucun soucis entre le champ texte de mon formulaire et ce qui est renvoyé par getName(), c'est identique.
OUI, j'échappe bien les caractères spéciaux avec real_escape_string
Le driver MySQLi ne renvoie pas de message d'erreur !! ($mysqli->error == NULL !) par contre le sqlstate renvoie un code d'erreur : HY000 qui correspond a une erreur générique (on est avancé avec ca :) )
Le problème devient rééllement étrange lorsque j'observe les requêtes qui sont loggées.
Cette requete est la bonne requete :
INSERT INTO publisher (pu_name) VALUES (')à\'ç&é)"(ç_à&é"à\'_&éà"\'_é&à\'"_éàç"_\'àé"&\'_)');
Cette requête est la mauvaise requête :
INSERT INTO publisher (pu_name) VALUES (')à\'ç&é)"(ç_à&é"à\'_&éà"\'_é&à\'"_éàç"_\'àé"&\'_)àé"\'_à\'àé_"\')');
Elles semblent toutes les deux correctes, et pour cause, elles sont toutes les deux valides !!! Quand je les execute à la main, elles passent toutes les deux, mais en php, seule la première passe...
En résumé, dès que je flirte avec la limite de caractères, il semble impossible d'insérer un élément avec MySQLi :(
Je me suis dit que peut etre il comptait les \ dans le total de caractères, mais que nenni, lorsque j'insère 64 apostrophes ( simple quote ) il insère également 64 \ devant les apostrophes donc il y a 128 chars dans la requete, mais comme seulement 64 seront insérés, la requete passe comme une fleur ! Je n'y comprend rien du tout.
A tout les coups j'ai encore loupé un truc, mais quoi ? :(
Quelqu'un a une idée ?
Merci beaucoup et bonne fin de journée,
Guizmo
PS : si je ne suis pas clair dite le moi, je m'expliquerai autrement.
Je ne comprend pas grand chose a ces histoires. Quand j'effectue une insertion en base de données avec MySQLi, c'est encodé en UTF8 (puisque je vois une bouillie de à ) mais je ne lui ai rien demandé moi a MySQLi, donc c'est qui qui fait cet encodage ? C'est parceque les tables sont au format UTF8-unicode ?
Dans ce cas pourquoi une requete à la main n'insère pas des données en UTF8 mais des données en clair ?
Et pourquoi quand j'ai une bouillie de à je peux récupérer mes enregistrements sans traitement alors que quand les données apparaissent en clair je dois réaliser un utf8_decode() ?
Cela m'amène à penser que les à correspondent a des données non encodées en utf8 et les données que je vois en clair sont en fait encodées en utf8 (puisque j'ai besoin d'un utf8 decode pour les récupérer). Dans ce cas, comment insérer les données en utf8 dans la base ?
Car moi ce qui m'interesse, c'est de voir mes données en clair dans la base, car ca résoudrait mon problème de longueur de champs (ben oui, si les lettres ressemblent toutes à des Ã'Ã le nombre de caractère inséré n'a plus grand chose a voir avec le nombre de caractères saisis par l'utilisateur !)