Problème d'encodage sur les sites web suite à la migration Etch

cf CR migration hebergeur et tests sur osti pour l'historique.

Je (NM) recopie ici le bilan fait par ProgFou et posté sur la liste tech.

Contexte

"[Je publie ce compte-rendu d'étude sur Tech@Auf dans l'intérêt général de notre communauté technique. Contexte : problème de caractères mal encodés sur les sites web hébergés à Montréal, suite a la migration vers Debian Etch des serveurs.]" -- ProgFou

Bon... Finalement ça devrait se passer beaucoup mieux que prévu !

Premières observations

Moussa NOMBRE a écrit :

•   > > Chose curieuse, le même test (SHOW VARIABLES LIKE 'char%') via un
    > > script php effectué depuis intranet.auf renvoyer de l'UTF-8 partout  :-( .
    > > En rappel, le test depuis osti renvoie un mélange de latin1 et
    > > d'UTF-8. Et via le client mysql, depuis osti, j'ai tout en UTF-8.
    > > Ce qui fait que je pense que le noeud du problème est côté
    > > configuration PHP,
    > > [...]
    > > Pourquoi alors sur intranet, on n'a pas le même résultat ? Ou bien on
    > > a pu alors modifier le comportement du PHP ? Je me demande bien comment ?

Suite à ces remarques de Moussa, qui révèlent une situation plus qu'étrange, j'ai décidé d'aller faire un tour sur intranet.auf et osti.auf pour en avoir le cœur net.

Confirmations des observations

• Et effectivement, depuis intranet, qui est en Sarge avec un PHP 4 lié à une librairie MySQL 4.0, on obtient une connexion vers db.auf 100% en UTF-8, que ce soit depuis Apache ou en ligne de commande.
• Effectivement aussi, depuis osti, qui est en Etch avec un PHP 5 lié a une librairie MySQL 5.0, on obtient une connexion vers db.auf mixée ISO-8859-1 et UTF-8, que ce soit depuis Apache ou en ligne de commande, alors que l'environnement de osti est 100% UTF-8.

Premières hypothèses

• Vu que le comportement est le même depuis Apache ou en ligne de commande, ça écarte tout de suite l'hypothèse d'une option de configuration dans Apache.
• Vu que la connexion a été effectuée vers le même serveur MySQL pour les deux, ça écarte également l'hypothèse d'une option forcée côté serveur MySQL.

• Il ne reste que la configuration de PHP lui-même, or changer l'option default_charset ne change strictement rien au résultat obtenu (ça je le savais déjà).

Dernière hypothèse

La dernière hypothèse qui m'est alors venue est celle d'une différence au niveau de la librairie libmysqlclient avec laquelle le module MySQL de PHP est lié. Je me suis dit que la libmysqlclient 4.0 devait prendre le jeu de caractères proposé par le serveur MySQL (UTF-8) alors que la libmysqlclient 5.0 devait prendre celui proposé par le client (ici PHP, donc ISO-8859-1).

Vérification de l'hypothèse finale

Afin de vérifier cette hypothèse, il me fallait modifier le jeu de caractères du côté serveur MySQL pour voir si les réponses en seraient aussitôt différentes, ce qui n'était évidement pas faisable directement sur le serveur db.auf (en production !). Moussa m'a proposé, merci a lui, de faire des tests sur db-secours, qui est une copie exacte de db.auf. C'était exactement ce qu'il me fallait car cela m'a permis de vérifier mon hypothèse qui s'est révélée exacte !

En changeant l'option "default-character-set" du côté serveur, cela provoque immédiatement un changement de comportement pour les clients liés a la librairie libmysqlclient 4.0 ! En particulier, mettre default-character-set = latin1 côté serveur donne immédiatement une connexion 100% ISO-8859-1 depuis intranet et osti.

Explications

Mon explication est que la librairie MySQL 4.0 avait un support Unicode bogué qui ne tenait pas compte du jeu de caractères du client et prenait à la place celui par défaut du côté serveur. Alors que la librairie MySQL 5.0 supporte officiellement Unicode et corrige ce bogue en tenant compte du choix de jeu de caractères côté client.

Le truc amusant est que ce bogue nous a facilité les choses dans le sens qu'il nous a évité d'avoir à configurer le bon jeu de caractères du côté client. Mais c'est à double tranchant puisque du coup nos scripts ne spécifient pas le jeu de caractères voulu ! Et la migration Etch qui nous apporte la librairie MySQL 5.0 nous révèle alors ce défaut.

Bilan

• le serveur db.auf en production ayant été configuré depuis longtemps avec server-character-set = utf8, il est bien en UTF-8 de son côté ;

• le serveur db.auf en production ayant été configuré depuis longtemps avec default-character-set = utf8, tous les clients MySQL 4.0 sont aussi automatiquement passés en UTF-8 de leur côté ;

• le module MySQL de PHP4 dans Sarge étant lié avec la librairie MySQL 4.0, toutes les connexions PHP depuis nos serveurs Sarge sont déjà bien à 100% en UTF-8 ;
• le module MySQL de PHP4 (ou PHP5) dans Etch étant lié avec la librairie MySQL 5.0, toutes les connexions PHP depuis les serveurs Etch sont en ISO-8859-1 côté client (jeu de caractères imposé avec PHP4 et par défaut avec PHP5).

Conclusion

• nous sommes déjà potentiellement fonctionnels en UTF-8 à Montréal (MySQL, PHP et connexions entre les deux) !

• la migration Etch impose cependant soit de corriger tous les scripts PHP, soit d'imposer le jeu de caractères client du côté serveur avec init-connect = 'SET NAMES utf8' (ce qui donne bien une connexion 100% UTF-8 pour osti comme pour intranet) ; cette dernière solution étant parfaitement utilisable ici (comme solution de dépannage rapide) étant donné que toutes nos connexions PHP avec db.auf étaient déjà 100% en UTF-8 ;

• restera à voir si les données sont effectivement en UTF-8 dans les bases (ce qui n'est pas obligatoirement le cas), mais ce n'est pas indispensable dans l'immédiat et cela pourra être traité plus tard, tranquillement.