Bonjour à tous,
Attention, c'est un peu long. Voici quelques interrogations et les tests que j'ai pu faire. Si vous pouviez éclairer ma lanterne, ou confirmer ou infirmer mes suppositions, ça serait pas mal.
Sans être totalement ignorant des questions relatives aux encodages de caractères, j'avoue que leur gestion par divers programmes et langages me dépasse un peu.
J'ai un site construit avec Movable Type 4, dont les données sont en UTF-8. Mais lorsque je les visualise avec phpMyAdmin, ces données apparaissent sous la forme suivante: «Téléchargement» pour «Téléchargement». Pourtant, la page servie par phpMyAdmin est bien en UTF-8. J'ai vérifié. Si je demande à Firefox de m'afficher la même page en ISO-8859-1, j'obtiens «Téléchargement».
Pourtant, sur mon site Movable Type, tout est bien affiché, je suis en UTF-8 sur toute la ligne (j'utilise d'ailleurs régulièrement des caractères typographiques inexistants en ISO-8859-1), etc.
Le problème me semble donc être du côté de phpMyAdmin. Le coup des données corrompues à l'affichage (c'est à dire avec un affichage type «données utf-8 affichées en latin1» alors qu'on est déjà en utf8) me semble révélateur.
À tout hasard, je me suis écrit un micro-script PHP pour interroger directement ma base. La page produite est servie en UTF-8, et les données s'affichent bien. J'en conclus donc que mes données sont bien en UTF-8 dans la base, malgré ce qu'affiche phpMyAdmin.
Maintenant, une petite subtilité. Si je rajoute à mon script PHP:
Série de suppositions:
1. Ma base de données a été créée avec l'encodage utf8 (me dit phpMyAdmin).
2. Lors de l'installation du blog, Movable Type a créé les tables en indiquant pour chaque table un "CHARSET=latin1".
3. Par la suite, Movable Type insère ses données en UTF-8 (c'est à dire qu'il envoie des valeurs numériques correspondant à de l'UTF-8, qui sont enregistrées telles quelles par MySQL, et restituées telles quelles également, en ignorant le "CHARSET=latin1".
4. Si j'utilise SET NAMES ou SET character_set_results, MySQL essaie de transcrire les données quand ça lui semble nécessaire. Si je demande des données d'une table (ou à fortiori d'un champ) marqué comme étant en latin1, et que je demande de l'UTF-8, alors MySQL transcrit les données de latin1 vers UTF-8, et comme les données sont déjà en UTF-8 elles sont alors corrompues.
5. J'imagine que phpMyAdmin doit faire la même chose que moi: comme la base de données a été créée en UTF-8, il utilise un SET NAMES 'UTF8' ou équivalent, et paf corruption des données.
La grande question est: pourquoi diable Movable Type crée-t-il des tables en latin1 pour y insérer des données UTF-8 par la suite? Et là je parle de Movable Type, mais il me semble que CMS Made Simple fait exactement la même chose. (Du moins si je ne me fourvoie pas complètement pour l'un comme pour l'autre.)
Une idée comme ça: ce serait un mécanisme pour pouvoir utiliser l'enregistrement des données en UTF-8 avec de vieilles versions de MySQL, MySQL 3 ou peut-être même 4. Ces versions ne supporteraient pas UTF-8, et donc on ne pourrait pas leur demander de tout gérer en UTF-8. On se contenterait alors de leur passer des données brutes, sans faire appel à leurs facultés de conversion des données.
Ça vous semble plausible ou bien je délire à plein tube?
Enfin, la question corrolaire: quel type d'export faut-il faire avec mysql_dump?
Si j'utilise mysql_dump sans rien indiquer de spécial, il travaille par défaut en UTF-8 et dans le fichier d'export j'ai... des données corrompues. Si je lui demande de travailler en latin1 (--default-character-set=latin1), dans le fichier d'export j'obtiens... des données en UTF-8. Bref, même topo qu'avec mon script PHP de test.
Mais, à tout hasard, les données «corrompues» ne sont-elles pas nécessaires sous cette forme pour pouvoir faire un import qui marche (dans une nouvelle base de données sur un autre serveur, par exemple, ou sur le même en cas de restauration nécessaire)?
Demain matin je dois faire un transfert de base de données pour un site CMS Made Simple qui semble présenter exactement le même problème. Je vais tenter les deux type d'export avec mysql_dump, et je vous dirai ce qui marche bien.
Modifié par Florent V. (13 Mar 2008 - 12:05)
Attention, c'est un peu long. Voici quelques interrogations et les tests que j'ai pu faire. Si vous pouviez éclairer ma lanterne, ou confirmer ou infirmer mes suppositions, ça serait pas mal.
Sans être totalement ignorant des questions relatives aux encodages de caractères, j'avoue que leur gestion par divers programmes et langages me dépasse un peu.
J'ai un site construit avec Movable Type 4, dont les données sont en UTF-8. Mais lorsque je les visualise avec phpMyAdmin, ces données apparaissent sous la forme suivante: «Téléchargement» pour «Téléchargement». Pourtant, la page servie par phpMyAdmin est bien en UTF-8. J'ai vérifié. Si je demande à Firefox de m'afficher la même page en ISO-8859-1, j'obtiens «Téléchargement».
Pourtant, sur mon site Movable Type, tout est bien affiché, je suis en UTF-8 sur toute la ligne (j'utilise d'ailleurs régulièrement des caractères typographiques inexistants en ISO-8859-1), etc.
Le problème me semble donc être du côté de phpMyAdmin. Le coup des données corrompues à l'affichage (c'est à dire avec un affichage type «données utf-8 affichées en latin1» alors qu'on est déjà en utf8) me semble révélateur.
À tout hasard, je me suis écrit un micro-script PHP pour interroger directement ma base. La page produite est servie en UTF-8, et les données s'affichent bien. J'en conclus donc que mes données sont bien en UTF-8 dans la base, malgré ce qu'affiche phpMyAdmin.
Maintenant, une petite subtilité. Si je rajoute à mon script PHP:
mysql_query("SET character_set_results = 'UTF8'");Série de suppositions:
1. Ma base de données a été créée avec l'encodage utf8 (me dit phpMyAdmin).
2. Lors de l'installation du blog, Movable Type a créé les tables en indiquant pour chaque table un "CHARSET=latin1".
3. Par la suite, Movable Type insère ses données en UTF-8 (c'est à dire qu'il envoie des valeurs numériques correspondant à de l'UTF-8, qui sont enregistrées telles quelles par MySQL, et restituées telles quelles également, en ignorant le "CHARSET=latin1".
4. Si j'utilise SET NAMES ou SET character_set_results, MySQL essaie de transcrire les données quand ça lui semble nécessaire. Si je demande des données d'une table (ou à fortiori d'un champ) marqué comme étant en latin1, et que je demande de l'UTF-8, alors MySQL transcrit les données de latin1 vers UTF-8, et comme les données sont déjà en UTF-8 elles sont alors corrompues.
5. J'imagine que phpMyAdmin doit faire la même chose que moi: comme la base de données a été créée en UTF-8, il utilise un SET NAMES 'UTF8' ou équivalent, et paf corruption des données.
La grande question est: pourquoi diable Movable Type crée-t-il des tables en latin1 pour y insérer des données UTF-8 par la suite? Et là je parle de Movable Type, mais il me semble que CMS Made Simple fait exactement la même chose. (Du moins si je ne me fourvoie pas complètement pour l'un comme pour l'autre.)
Une idée comme ça: ce serait un mécanisme pour pouvoir utiliser l'enregistrement des données en UTF-8 avec de vieilles versions de MySQL, MySQL 3 ou peut-être même 4. Ces versions ne supporteraient pas UTF-8, et donc on ne pourrait pas leur demander de tout gérer en UTF-8. On se contenterait alors de leur passer des données brutes, sans faire appel à leurs facultés de conversion des données.
Ça vous semble plausible ou bien je délire à plein tube?
Enfin, la question corrolaire: quel type d'export faut-il faire avec mysql_dump?
Si j'utilise mysql_dump sans rien indiquer de spécial, il travaille par défaut en UTF-8 et dans le fichier d'export j'ai... des données corrompues. Si je lui demande de travailler en latin1 (--default-character-set=latin1), dans le fichier d'export j'obtiens... des données en UTF-8. Bref, même topo qu'avec mon script PHP de test.
Mais, à tout hasard, les données «corrompues» ne sont-elles pas nécessaires sous cette forme pour pouvoir faire un import qui marche (dans une nouvelle base de données sur un autre serveur, par exemple, ou sur le même en cas de restauration nécessaire)?
Demain matin je dois faire un transfert de base de données pour un site CMS Made Simple qui semble présenter exactement le même problème. Je vais tenter les deux type d'export avec mysql_dump, et je vous dirai ce qui marche bien.
Modifié par Florent V. (13 Mar 2008 - 12:05)
