Assistance #522
fermé
mysqldump en utf-8 et contenu surprenant
Ajouté par Marc-Henri Pamiseux il y a presque 12 ans. Mis à jour il y a presque 12 ans.
0%
Description
Bonjour,
J'effectue un dump de la base de données, et je constate en utilisant "vim -b" que les caractères accentués dans le fichier dump sont modifiés :
le é => é
le è => è
le ë => ë
le ç => ç
...
Voici la commande mysqldump que j'ai utilisé :
mysqldump --create-options --add-drop-table --add-locks --complete-insert --default-character-set=utf8 --extended-insert --flush-logs --hex-blob --quick -u root -p galette >galette-dump.sql
Mon environnement de fonctionnement est un serveur Linux Debian, dont les locales par défaut sont fr_FR.UTF-8
@ vous lire,
Mis à jour par Roland Telle il y a presque 12 ans
Marc-Henri Pamiseux a écrit :
[...] J'effectue un dump de la base de données, et je constate en utilisant "vim -b" que les caractères accentués dans le fichier dump sont modifiés :
le é => é
le è => è
le ë => ë
le ç => ç
Moi également (PhpMyAdmin) :
Et je m'en porte très bien ;)
[...] Mon environnement de fonctionnement est un serveur Linux Debian, dont les locales par défaut sont fr_FR.UTF-8
C'est parfait. Où est le problème, à part l'effet de surprise ?
Mis à jour par Marc-Henri Pamiseux il y a presque 12 ans
A mon sens, fonctionnant en environnement Full UTF-8 (la console Linux), lorsque j'effectue un dump de la base de données dans un fichier texte, les caractères accentués devraient s'afficher correctement (c'est à dire en UTF-8). Le fait qu'ils s'affichent différemment me laisse à penser qu'ils ne sont pas sauvegardés en UTF-8 dans la base de données mais en iso.
Or, s'ils ne sont pas sauvegardés dans le bon format dans la base de données c'est qu'il y a une altération du format lors de l'affichage. Donc je me tourne maintenant vers Smarty et la gestion des "utf8_encode"...
J'ai lu à ce propos une remarque intéressante sur le site (oui, je sais...) de developpez.net :
http://www.developpez.net/forums/d467241/php/bibliotheques-frameworks/templates/smarty/utf8_encode-template/
@ vous lire,
Mis à jour par Johan Cwiklinski il y a presque 12 ans
Je ne présume de rien concernant l'encodage avec MySQL. C'est juste une horreur à gérer, la plupart du temps, une vraie base en UTF-8 comme celle de Galette va poser plein de soucis ailleurs (phpMyAdmin par exemple).
La base doit être UTF ainsi les tables, les champs et les données à l'intérieur ; sans parler de la connexion (utf n'est pas par défaut sous mysql à ce que j'en sais, ou alors c'est plutôt récent) ! Alors, bon, ce que va sortir un mysqldump...
Tant qu'il est capable de dumper et de recharger la base et que c'est bon dans Galette, je ne cherche pas en ce qui me concerne. Que donne un file ou un utrac sur le fichier en question ?
Mis à jour par Marc-Henri Pamiseux il y a presque 12 ans
Bonjour Johan,
Oui, je sais parfaitement combien il est compliqué de mettre en oeuvre une application gérant de bout en bout l'encodage UTF-8 et je te soutiens à 100% dans cette démarche.
phpMyAdmin est une horreur pour gérer l'encodage UTF-8, et c'est la raison pour laquelle je préfère me baser sur un jeu de commandes mysql de base, commandes exécutées depuis un système natif UTF-8...
Je n'ai pas accès à utrac, il semble que les différentes distributions l'aient abandonnées, d'autant que ma distribution de test est en 64 bits. J'ai téléchargé les sources, compilées sans erreur et lorsque j'invoque la commande sur le fichier, j'ai droit un à beau code dump de l'application... A mon avis, le 64 bits est mal géré sur cette vieille application !
Revenons à nos moutons, la commande file, pour rester fidèle à elle même me retourne une information trop éloignée de la réalité; plus exactement, voici ce qu'il m'est retourné : "application/octet-stream; charset=binary". Logique, le dump contient des images qui sont sauvegardées en base de données (table galette_pictures).
Mais je reste fidèle à ma commande "vi -b monfichier" puisque l'option -b de vim permet de démarrer le "Mode Binaire", sous-entendu sans interpréter le contenu du fichier, ni son encodage justement. Et c'est justement dans ce mode que je parviens à voir correctement les caractères UTF-8. Normal, ma console SSH est en UTF-8, l'environnement shell d'ouverture de session fonctionne sous la locale UTF-8, etc...
Donc, quand je laisse vim décider de l'encodage d'affichage du fichier, j'ai droit à des caractères non lisible, tandis que lorsque j'impose à vim de ne rien interpréter, j'ai droit à l'affichage associé à l'encodage du système, c'est à dire UTF-8.
C'est ce constat qui me laisse supposer que le fichier, et donc le contenu de la base de données est bien en UTF-8.
Mais alors je m'inquiète pour rien, puisque j'ai la preuve que les données sont enregistrées en UTF-8 et qu'elles s'affichent correctement depuis l'interface de Galette.
J'ai envie de dire mais pourquoi tout ce tintamarre ???
Heu....
Désolé !
@ bientôt,
Mis à jour par Johan Cwiklinski il y a presque 12 ans
- Statut changé de Nouveau à Rejeté
Marc-Henri Pamiseux a écrit :
Bonjour Johan,
Oui, je sais parfaitement combien il est compliqué de mettre en oeuvre une application gérant de bout en bout l'encodage UTF-8 et je te soutiens à 100% dans cette démarche.
phpMyAdmin est une horreur pour gérer l'encodage UTF-8, et c'est la raison pour laquelle je préfère me baser sur un jeu de commandes mysql de base, commandes exécutées depuis un système natif UTF-8...
Oui... Les problèmes d'encodage ne font pas partie des mes amis... Loin s'en faut :)
Je n'ai pas accès à utrac, il semble que les différentes distributions l'aient abandonnées, d'autant que ma distribution de test est en 64 bits. J'ai téléchargé les sources, compilées sans erreur et lorsque j'invoque la commande sur le fichier, j'ai droit un à beau code dump de l'application... A mon avis, le 64 bits est mal géré sur cette vieille application !
Concernant utrac, je l'ai sous Fedora en 64 bits, mais ça a été un peu patché (http://pkgs.fedoraproject.org/cgit/utrac.git/tree/?h=f18 pour les détails ;)).
Revenons à nos moutons, la commande file, pour rester fidèle à elle même me retourne une information trop éloignée de la réalité; plus exactement, voici ce qu'il m'est retourné : "application/octet-stream; charset=binary". Logique, le dump contient des images qui sont sauvegardées en base de données (table galette_pictures).
Ok, je ne suis pas étonné ;) je ne connais pas d'autre alternative que utrac (mais bon, s'il fonctionne, il lui arrive assez souvent de segfaulter tout de même :/).
Mais je reste fidèle à ma commande "vi -b monfichier" puisque l'option -b de vim permet de démarrer le "Mode Binaire", sous-entendu sans interpréter le contenu du fichier, ni son encodage justement. Et c'est justement dans ce mode que je parviens à voir correctement les caractères UTF-8. Normal, ma console SSH est en UTF-8, l'environnement shell d'ouverture de session fonctionne sous la locale UTF-8, etc...
Donc, quand je laisse vim décider de l'encodage d'affichage du fichier, j'ai droit à des caractères non lisible, tandis que lorsque j'impose à vim de ne rien interpréter, j'ai droit à l'affichage associé à l'encodage du système, c'est à dire UTF-8.
C'est ce constat qui me laisse supposer que le fichier, et donc le contenu de la base de données est bien en UTF-8.
Je ne connaissais pas l'option -b de vim ; qui m'aurait pourtant été fort utile à maintes reprises... Mais pourquoi n'ais-je pas lu le man ?? :-D
Mais alors je m'inquiète pour rien, puisque j'ai la preuve que les données sont enregistrées en UTF-8 et qu'elles s'affichent correctement depuis l'interface de Galette.
J'ai envie de dire mais pourquoi tout ce tintamarre ???
Je pense que le titre choisi était adapté : c'est surprenant :)
Heu....
Désolé !
Pas de problème :)