Galette

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 ?

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,

Je passe la main ... ;)

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 ?

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,