Stockage des caractères spéciaux et internationaux en base de données

Bonjour à tous,

je suis à la recherche d'un avis, je développe actuellement un site multilingue. (LAMP)
Mes pages sont en UTF-8, mes tables également déclarées comme tel.

Afin de ne pas rencontrer de problème avec les caractères spéciaux, internationaux, cotes et guillemets, j'ai décidé de stocker les codes html de ces caractères en base (fonction htmlentities de PHP)

À la vue des différents CMS existants, je me suis rendu compte que peu d'entre eux avaient opté pour ce choix, cela est-il déprécié ? pour quelle raison ? quelle solution adoptée ?

Merci pour vos réponses

François

mrtrois a écrit :
À la vue des différents CMS existants, je me suis rendu compte que peu d'entre eux avaient opté pour ce choix, cela est-il déprécié ? pour quelle raison ? quelle solution adoptée ?

En UTF-8 tu peux coder tous les caractères. Si tu encode en entités HTML avant de stocker en base:
- pour restituer ton contenu dans des pages HTML, ça va, tu récupères le contenu tel quel;
- pour le restituer dans des fichiers XML, ça peut poser problème, il faut soit utiliser des sections CDATA dans tous les sens... soit décoder tes entités HTML pour retrouver les bons caractères;
- pour le restituer dans des fichiers JSON, rebelote, il faut décoder tes entités pour retrouver les caractères d'origine.

De fait, le texte que tu stockes est moins «pur» et moins polyvalent si tu le gaves d'entités HTML. Alors qu'en UTF-8 tu pourrais garder ton texte sans modifications.

Autre problème de stocker des entités HTML: c'est plus lourd (ça prend plus de place). Ça peut être gênant:
- Pour des valeurs limitées en nombre de caractères.
- Pour des textes dans des graphies qui utilisent pas ou peu de caractères latins (cyrillique, idéogrammes, kanjis, caractères arabes, etc.).

La solution, c'est de travailler en UTF-8 d'un bout à l'autre de la chaine. Il faut apprendre à déclarer correctement le codage des caractères côté client (balise META, en-tête HTTP...). Et si tu as des problèmes dus à un langage de programmation ou à un système de base de données, il faut apprendre à gérer l'UTF-8 correctement avec ces outils (ça fait partie du bagage nécessaire de tout développeur qui se respecte).

fvsch a écrit :
La solution, c'est de travailler en UTF-8 d'un bout à l'autre de la chaine.

Merci pour ces conseils, je les ai donc suivi.

Pour ceux que ça intéresse, et pour ceux désirant apporteur leur pierre à ce topic, voici ce que j'ai donc fait (pour rappel, je parle de PHP) :

une fonction d'encodage des données (insertion en base)
- utf8_encode -> encodage des caractères spéciaux et internationaux en utf8
- htmlspecialchars (ENT_QUOTES) -> encodage des caractères HTML

une fonction de décodage des données (récupération des données de la base)
- utf8_decode -> récupération des caractères spéciaux et internationaux pour traitement
- htmlspecialchars_decode (ENT_NOQUOTES) -> décodage des caractères HTML sauf guillemets et apostrophes

Cette solution me paraît (à l'heure d'aujourd'hui) optimale pour mon cas, je l'ai testé pour l'utilisation de caractères arabes, mandarins, spéciaux etc...
Merci de m'indiquer s'il en est de même pour vous !

mrtrois a écrit :
Cette solution me paraît (à l'heure d'aujourd'hui) optimale pour mon cas, je l'ai testé pour l'utilisation de caractères arabes, mandarins, spéciaux etc...
Merci de m'indiquer s'il en est de même pour vous !

Heu... en PHP, utf8_encode permet de convertir une chaine de ISO-8859-1 à UTF-8, tandis que utf8_decode fait l'inverse.

Donc tu récupères des données en ISO-8859-1, les stocke ainsi en base, puis les récupère de la base avant de les reconvertir en UTF-8 pour l'affichage sur le site. C'est pas tout à fait être en UTF-8 d'un bout à l'autre de la chaine, ça.

Il se peut aussi que tu récupères des données en UTF-8 pour l'insertion en base. Je connais mal PHP, mais je suppose que si tu fais utf8_encode($une_chaine_utf8), tu te retrouves avec des données corrompues. Données corrompues que tu stocke en base. Puis tu fais le chemin inverse qui te permet de retrouver des données correctes. Pas mieux.

Normalement tu n'as besoin ni de utf8_encode, ni de utf8_decode. Si c'est le cas, tu as un problème quelque part dans ta chaine (par exemple la connexion à MySQL ouverte en ISO-8859-1, des tables ou champs de ta base avec un interclassement latin1_trucmuche, ce genre de chose.

Pour le htmlspecialchars, c'est peut-être une bonne solution pour éviter les injections SQL. À vérifier, je connais pas vraiment le sujet. Si ce n'est pas une mesure de sécurité, je suis pas sûr de l'intérêt au moment de l'insertion en base. Par contre ça peut être intéressant lorsque tu affiches tes données, pour éviter les insertions de balises <script> par exemple.
Bon, j'y connais vraiment rien donc je vais pas dire plus de bêtises sur ces questions de sécurité.

fvsch a écrit :

Autre problème de stocker des entités HTML: c'est plus lourd (ça prend plus de place). Ça peut être gênant:
- Pour des valeurs limitées en nombre de caractères.
- Pour des textes dans des graphies qui utilisent pas ou peu de caractères latins (cyrillique, idéogrammes, kanjis, caractères arabes, etc.).

Peut être aussi pour le moteur de recherche interne du site. Si tu fais une recherche sur "écrire" tu ne trouvera pas "&eacute;crire".