Le blog de Mr Schnaps

Et encore, je pèse mes mots ! Si vous utilisez un CMS comme Wordpress, ça va, vous n’avez pas tellement à vous interesser au choix de l’encodage pour vos pages web. Grosso modo, il y a deux encodage possibles :

• Utiliser l’encodage local : Latin-1
• Utiliser l’encodage universel : UTF-8

Alors à première vue, on peut se dire que le mieux est d’opter pour la seconde solution, pour ne pas être bridé par la suite. J’ai fait ce choix pour le développement d’un site, et maintenant je m’en mords les doigts !

Déjà, UTF-8 est rarement l’encodage par défaut des éditeurs de texte, donc dans un premier temps il vous faut convertir tous vos fichiers. Une fois que vous avez terminé cette tâche longue et fastidieuse, vous vous dites que la migration est enfin terminé.

Eh bien c’est pas du tout le cas, parce qu’il est maintenant impossible de stocker un texte avec accents dans une base de donnée.

En fait, MySQL a besoin qu’on lui dise qu’on travaille dans un encodage spécial avant toute requête :

SET NAMES ‘utf8′

Mais ce n’est pas terminé, parce qu’il faut toujours veiller à ce que les variables que vous manipulez, et en particulier les chaînes, soient toujours encodés en utf-8 grâce aux fonctions php utf8_encode et utf8_decode.

Et comme certaines fonctions PHP ne fonctionnent pas (un comble pour une fonction !) avec les chaînes UTF-8 (comme strrtr), je vous laisse imaginer le bordel qu’on obtiens à la fin !