Bonnes pratiques d'encodage des caractères spéciaux (MySQL) ?

Slt tout le monde !

J'aurais besoin d'un avis éclairé, qui est sans doute évident pour certains, concernant la meilleure façon de gérer les caractères spéciaux dans une base de données.

C'est hier, en rencontrant un problème d'import/export d'une base avec des versions différentes de phpMyAdmin, que j'ai été confronté à un problème. Après quelques tests et grâce aux couleurs syntaxiques de mon IDE, je me suis rendu compte que phpMyAdmin 4.1.14 (WampServer 2.5) transformait les apostrophes des valeurs par 2 guillemets simples (ce qui fonctionne très bien à l'import), mais que phpMyAdmin 4.4.15.5 (WampServer 3.0.4) ajoutait un antislash devant les apostrophes pour les échapper lors de l'export. Cet échappement fait planter l'import de la base par la suite. Pensant à un bug, j'ai résolu le problème en utilisant une autre version de phpMyAdmin sur mon serveur local, la version 4.4.15.5 (qui a l'avantage d'être compatible à la fois avec PHP 5.4 et PHP 7) qui se comporte comme la version 4.1.14 (2 guillemets simples). Par curiosité, j'ai aussi fait des tests d'export avec Adminer. Toutes les versions que j'ai essayé (de la 3.7.1 à la 4.2.4) ont échappé les apostrophes avec un antislash. Du coup je me suis dit qu'il ne s'agissait sans doute pas d'un bug de phpMyAdmin, mais que je devais revoir mes habitudes et qu'il ne devait pas être "correct" d'injecter des caractères spéciaux dans une base.

Aujourd'hui, j'ai lu à plusieurs reprises qu'avec les requêtes préparées de PDO (que j'utilise), il ne fallait pas s'occuper des caractères spéciaux lors de l'insertion dans la base. A vrai dire, c'était mon cas jusqu'à maintenant, mais plus par ignorance qu'autre chose ;) J'ai remarqué aussi que TinyMCE, quant à lui, injecte du code html dans la base, mais qu'il transforme le tout en entité html avant, apostrophes compris.

Du coup, je ne sais plus quoi penser. Ce qui est sûr, c'est qu'il est plus facile de lire une table si besoin, dont le contenu à conservé ses caractères spéciaux. Par contre, ça oblige l'utilisation de htmlentities() ou htmlspecialchars() dans certains cas.

Bon j'espère que toute cette suite de versions en tous genres n'a pas été trop indigeste ;) Merci de m'avoir lu.

Mysql accepte \' et '' pour échapper le caractère '

Code:

---

INSERT INTO unetable (colonne) VALUES ('une apostrophe '' encore une \'')

---

Il faudrait voir précisément pourquoi ton importe n'a pas fonctionné.

La préparation des requêtes permet effectivement d'envoyer tous les caractères sans travail préalable et tous les caractères sont les bienvenus dans les tables.

C'est uniquement lors de l'export que phpmyadmin est obligé de faire des échappement. Les données brutes, elles, n'en ont pas besoin.

Le fait que TinyMCE encore en entité HTML est paramétrable.
Mettre des entités HTML dans une base de données va fausser les classements et les recherches.

Slt sabotage !

Je viens d'appliquer ton exemple depuis la version phpMyAdmin qui me pose problème (v 4.5.5.1) et l'insertion s'est déroulée sans erreur.

Je viens de reproduire l'erreur à l'origine de la discussion en faisant des captures d'écran de phpMyAdmin 4.5.5.1 à chaque étape (avec des petits montages pour éviter de multiplier les fichiers).

Pièce jointe 210448

1. Import de ma base avec phpMyAdmin 4.5.5.1 (fichier SQL généré depuis phpMyAdmin 3.5.1 avec 2 guillemets simple comme échappement - WampServer 2.2e) = OK
2. Export de cette même base (sans aucune modif) depuis phpMyAdmin 4.5.5.1 (WampServer 3.0.4) = OK
3. Import du fichier SQL dans une nouvelle avec la même version phpMyAdmin = ERROR

Pièce jointe 210441

Pièce jointe 210442

Pièce jointe 210443

Si j'édite le fichier sql en remplaçant tous les apostrophes échappés (\') par 2 guillemets simples ('') et que j'essaie à nouveau d'importer la base avec phpMyAdmin 4.5.5.1, ça marche.

Le problème vient peut-être tout simplement d'une configuration par défaut différente entre les versions de phpMyAdmin ? Je ne suis pas super calé en bases de données, donc si ça se trouve c'est un truc tout bête.

Si j'ai bien compris tes explications, sans tenir compte du problème que je rencontre qui serait anecdotique, tu conseilles d'insérer de préférences des données bruts (sans aucun traitement donc) dans une base, mais tout est "autorisé". Par exemple, les données d'un espace d'admin que l'on peut qualifier de "sûres" pourraient être insérées sans traitement préalable et les données plus sensibles telles que les commentaires d'un article de blog pourraient être passées à la moulinette avant insertion. C'est bien ça ?

Citation:

---

Le fait que TinyMCE encore en entité HTML est paramétrable.
Mettre des entités HTML dans une base de données va fausser les classements et les recherches.

---

Merci pour l'info, c'est bon à savoir !

Citation:

---

Par exemple, les données d'un espace d'admin que l'on peut qualifier de "sûres" pourraient être insérées sans traitement préalable et les données plus sensibles telles que les commentaires d'un article de blog pourraient être passées à la moulinette avant insertion.

---

Non, tu peux tout insérer tel quel. Le passage des valeurs en paramètre d'une requête préparée garantie la sécurité de la requête.
Evidemment après il y a d'autres aspects en jeu comme l'ajout de javascript malicieux dans le contenu ; tes données doivent donc être converti en entités HTML au moment de l'affichage avec ENT_QUOTES

Code:

---

htmlentities($text, ENT_QUOTES)

---

Citation:

---

Envoyé par sabotage

Non, tu peux tout insérer tel quel...

---

Oui, bon...

Ca n'empêche pas de faire avant une "Gestion d'Erreurs", et de tester/filtrer les valeurs rentrées pas l'utilisateur.

• filter_var() (-> Types de filtres)

Slt,
Oui effectivement, je pense qu'on est tous les 3 d'accord avec ça.

Par contre, au final, quelqu'un sait pourquoi l'import de ma base plante ? Je veux bien injecter les données en dur dans une base, mais si je ne peux plus faire d'import/export, c'est bien qu'il y a un problème quelques part. Ou alors c'est bel et bien un bug de phpMyAdmin...

j'avais pas encore essayé avec Adminer d'importer la base à partir du même fichier sql qui ne passe pas dans phpMyAdmin et bien l'import c'est déroulé sans erreur. En fait, j'étais parti du principe que antislash = erreur, mais pas obligatoirement visiblement.

D'un autre côté, si j'ouvre le fichier dans un IDE (vrai avec Notepad++ et Netbeans) la couleur syntaxique est toute niquée lorsque les apostrophes sont échappés avec un antislash. En, remplaçant l'antislash par un guillemet simple, la couleur syntaxique est à nouveau correcte. Y'a pas un moyen d'imposer à phpMyAdmin d'échapper avec un guillemet simple, comme il le fait avec la version 4.4.15.5 ?