Choix de l'encoding

Je viens de tester la manip’ d’Aour mais le fichier dump était déjà en UTF-8. Donc, c’est rapé.

Ce que je ne comprends pas, c’est qu’en local, déjà, ce filou m’enregistre les é et à dans la BDD avec des é et à (donc c’est sur qu’après, il ne sait plus où il habite le pauvre !)

Marc, j’ai déjà fait la manip pour le fichier langue. Ca règle le problème des caractères utilisés dans l’admin, mais pas ceux qui sont enregistrés dans la BDD.

Bien, je vais bosser en ligne et attendre la prochaine version en espérant que le réglage de MODX en UTF-8 par défaut règle mes problèmes (j’y crois pas trop parce que le problème semble venir d’une incompatibilité entre mes 2 BDD mais bon... comme on dit, l’espoir fait vivre ! )

En fait je n’ai pas creusé la question mais quelqu’un avait évoqué (plus le thread en mémoire) le fait que ce problème pourrait venir de l’échange de données entre les formulaires et la base.... donc un problème d’encodage lors de l’insertion des données dans la base (probablement en ISO et pas UTF-8).

A creuser !

Lu

cela ne peut être que cela, le site en utf-8 qui stocke les infos dans une base en ISO car les caractères affichés dans ta base sont la répresantation par ISO de caractères UTF-8.

Est ce que lors de la création de la base de donnée, UTF-8 a bien été choisi ?

SI j’ai bien tout compris, tu avais Modx qui fonctionnait en ISO-8859-1 avec une base de données en UTF-8 ? et lorsque tu passes Modx en UTF-8, les soucis apparaissent ?

Je suis de ton avis David, je pense que c’est un problème avec les formulaires puisque dès la modification du nom du site (qui utilise un é), le caractère est mal enregistré dans la BDD. Donc, ta proposition semble logique. (D’ailleurs, après vérification, je me rends compte que ce problème n’apparait pas en distant... e-Déaliz est enregistré e-déaliz sans problème avec l’accentuation). Donc cette mauvaise communication entre formulaires et bdd est présent qu’en local.

Pourtant, quand j’ai créé la base de données en local (et j’ai bien pris soin de refaire la manip’ pour être sure), je l’ai créé en utf-8. Enfin, avec un interclassement utf8_general_ci. Voir l’interface de mon phpmyadmin avec les infos entrées, en fichier joint.
En fait, je stipule l’interclassement mais pas l’encodage. Est-ce différent ?
Pour le reste, on voit que phpmyadmin est bien en utf-8

Guillaume : c’est intéressant ce que tu dis. Voici le test que je viens de faire

- l’admin est en UTF-8. e-Déaliz dans l’admin apparait bien e-Déaliz... mais dans la bdd, e-Déaliz s’affiche e-Déaliz
- je passe l’admin en ISO, e-déaliz s’affiche toujours e-Déaliz (normal, c’est le contenu de la BDD)
- je modifie e-Déaliz par e-Déaliz dans l’admin, j’enregistre => e-Déaliz apparait bien e-Déaliz dans l’admin, mais aussi dans la BDD. Preuve qu’en ISO, l’enregistrement fonctionne bien et que ma BDD doit être en ISO.
- je repasse l’admin en UTF-8, j’enregistre, e-déaliz apparait e-D�aliz
- je remodifie e-Déaliz pour e-Déaliz, dans l’admin ça s’affiche bien, dans la bdd on retrouve le fameux e-Déaliz. La boucle est bouclée.

Pourtant, d’après le screenshot de phpmyadmin en fichier joint, vous voyez tous comme moi que la base est en UTF_8 non ?

J’ai examiné un peu plus avant les choses.

Apparemment, la version de MySQL a son importance... la version 4.1 inclu une déclaration CHARSET qui n’est pas comprise par la 4.0 (d’où le fait que le mode compatibilité MYSQL40 avais amélioré les choses pour moi lors du transfert serveur local -> OVH).

Ceci dit, même lorsque je transfère une BDD MySQL 4.1.x ISO vers une BDD aussi en 4.1 comme chez TextDrive, j’ai toujours des problèmes. Plus de problèmes d’accents, en fait, mais tout les ’ sont transformés en ?

Par exemple "d’une" devient "d?une" et ainsi de suite.... si on regarde le fichier export "d’une" est encodé "d ’ ’ une". J’ai procédé à un remplacement des ’ ’ par l’entité correcte " ’ " et ça a quasiment réglé tous mes problèmes, mais c’est pas encore ça...

Apparemment c’est un problème complexe (pas compris grand chose à l’article en question...).

Je pense qu’il faut vraiment mettre une priorité haute au passage de MODx en utf-8 par défaut, faute de quoi ça va rester compliqué à gérer...

Re

Bon j’ai crée un nouveau site avec tout en UTF-8 :
Fichier de lang, fichier setup.sql et DB en UTF8-General

- J’ai desactivé l’editeurs pour saisir une article en html. les caractères UTF8 sont stockés au format ISO : à éùà è
- Je me suis mis sur le site et j’ai modifié le texte avec quickedit. Je reourne dans ma base et les caractère sont sauvegardés en ascii : àéùàè
- je reactive FKCeditors et je créer un articles, caractères ascii : àéùàè

Si vous regarder le fichier de config de FKC editors, il applique htmlspecialchars à la chaine de texte saisie (htmlspecialchars -- Converti tous les caractères spéciaux en équivalent HTML.)
Mais cela ne me pose pas trop de souci car à la limite c’est plus propre et le site affichera correctement.

En ce qui concerne les champs des formulaires de l’admin les caractères sont stockés éà ù. Pas glop. Cela pourrait être du au traitement des caractères par le script qui reçoit les infos pour les sauvegarder dans la base : save_settings.processor.php ou du formulaire de mutate_settings.dynamic.action.php

La déclaration du formulaire : <form name="settings" action="index.php?a=30" method="post"> pourrait être enrichi du paramêtre d’encodage : accept-charset=.$etomite_charset

Le souci de l’echapement des ’ vient des protections contre l’injection sql. le script de sauvegarde des documents fait un mysql_escape_string, fonction dépréciée par ailleurs.

La déclaration du formulaire : <form name="settings" action="index.php?a=30" method="post"> pourrait être enrichi du paramêtre d’encodage : accept-charset=.$etomite_charset

Après recherche, je confirme : c’est la seule solution pour être sûr que les données sont bien envoyées en UTF-8.

Re

Il y a pas peut etre pas que cela mais c’est une piste car en plus le formulaire est encapsulé dans du javascript ...

Aour

Ca pourrait être une solution mais comment expliqué qu’en local (mysql 5.0.18-nt) l’enregistrement de caractères accentués soient si problématiques et en distant (mysql4.0.25-standard-log (j’vous marque tout hein ) ), ça fonctionne. Si le problème avait été dans l’autre sens, on aurait pu comprendre mais là, le problème survient sur la version 5.

Bref, je rejoins David sur le fait de passer MODx en UTF-8 (en même temps je l’ai facile à dire ça, c’est pas moi qui fais ) et en attendant, je bosse en ligne.

Ceci dit, si je n’avais pas eu le choix, bosser en local aurait effectivement été possible à condition de faire un rechercher/rempacer dans le fichier dump, avant injection dans la bdd distante.