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.
Partager