galère encodage (ma bête noire)

Bonjour,

Je suis actuellement en train de développer un petit module sous la forme de quelques pages php (avec mon fidèle notepad++). Ces pages s'intègrent dans notre site Internet développé par un prestataire.

En gros, les utilisateurs devront y déclarer leurs chiffres chaque mois.
Aussi, dans mon formulaire de déclaration, j'ai une liste déroulante (issue d'une fonction dans un fichier inclus fonctions.php, cf code ci-dessous) de 13 items (blanc par défaut + les 12 mois). Une fois le formulaire validé, il est représenté pour relecture, les champs sont les mêmes (liste déroulante pour les mois, donc).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

function ListeMois($lemois){ $lesmois=array("","Janvier","Février","Mars","Avril","Mai","Juin","Juillet","Ao&ucirc;t","Septembre","Octobre","Novembre","D&eacute;cembre"); //j'ai fait exprès de mettre tantôt les accentués en html, tantôt en dur pour tester $listemois = '<select id="fmois" name="fmois" onchange="change(this.select)">'; foreach($lesmois as $valeur){ if ($lemois==$valeur) { $listemois .= '<option value="'.$valeur.'" selected="selected">'.$valeur.'</option>'; } else { $listemois .= '<option value="'.$valeur.'">'.$valeur.'</option>'; } } $listemois .= '</select>';   return $listemois; }

---

Le problème, c'est que les mois avec accents (transmis en post) ne sont pas remis dans la liste :(
Pour cause, si je fais un echo de la variable, j'ai un beau "Février" :(

Donc un énième souci d'encodage...
Sachant que :
- mon prestataire m'a recommandé d'encoder mes pages php en iso-8859-1 (charset du serveur)
- que le header (fourni par le prestataire) présente les pages en utf-8 (qui est donc l'encodage appelé par défaut par le navigateur)
- que la base de données mysql est en utf8, interclassement latin_swedish_ci (mais là je ne fais même pas appel à la db pour cette liste... j'ai aussi des galères avec les valeurs en base mais ce sera un autre topic si je ne m'en sors pas :/)

[edit] : précision, les mois sont TOUS bien écrits dans la liste déroulante (que ce soit février ou août dans l'array)

Que puis-je tester pour arriver à mes fins (à part mettre mes mois sans accents ^^)

Merci d'avance pour vos lumières,

Bill

Je ne comprends pas bien ce que tu attends de nous : Tu sais toi même que tu travailles avec des encodages différents, donc tu ne peux pas être surpris d'obtenir des caractères mal écrits.

Ben... est-ce que ce serait un mauvais conseil de mon presta que de m'inciter à encoder en 8859-1 (sous prétexte que c'est le charset par défaut de leur serveur) ?

Parce que clairement j'ai des doutes quand je vois que le header html de toutes les pages du site contient :<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Mais comme les questions d'encodage ne sont pas mon fort et que je ne sais pas tout ce qui se passe sous le capot du site :/

Je cherche des pistes de résolution... Mais si ça vous semble si évident, alors je vais reconvertir des pages en utf pour tester.

Citation:

---

Envoyé par ibill

...alors je vais reconvertir des pages en utf pour tester.

---

Remis mes pages php en utf 8 sans BOM...

Et bien c'est encore pire : ce sont des caractères encore plus cabalistiques qui se placent au lieu des caractères accentués :(

Aucune trace d'utf dans mon phpinfo()...

Ce que je comprends, c'est que la page étant présentée en utf 8, le renvoi d'une variable en post se fait aussi en utf8. J'ai bon ?
Si c'est ça, et vu que je n'ai pas la main sur le "moteur" du site (c'est un back office propriétaire, mes développements le contournent...), ça sent le truffage de code avec des utf8_decode.

Ce n'est pas pire, ça inverse le problème.

Pour reprendre bien les choses :

Si, comme dans ton exemple, tu écris "Février" dans le fichier .php et que tu obtiens

- Février : c'est que ton fichier est en UTF8 mais que ton navigateur affiche de l'ISO
si tu as déjà sur cette page une balise meta indiquant UTF8, ajoute

Code:

---

header('Content-Type: text/html; charset=utf-8');

---

- F�vrier : c'est que ton fichier est en ISO mais que ton navigateur affiche de l'UTF8

Erf, quand je dis "encore plus cabalistique", j'évoque le codage sur 4 octets d'un caractère accentué -> gégé :(

L'ajout de la ligne du header ne change rien (je suppose que l'include du presta (qui contient le head et ses balises meta ainsi que les includes de base du site) que je ne peux visualiser ou modifier - fait déjà référence au charset utf8...

Bon avec utf8_decode sur mes variables $post je vais arriver à quelque chose... un peu de gymnastique :/

Mais je me pose toujours la question de la recommandation d'encodage en iso de pages présentées en utf8 :(

Et sinon encore une question : on est bien d'accord que si ma base est en utf8, je ne devrais jamais voir des "é" et consorts dans les données, n'est-ce pas ?

Merci :)

Bonjour,

• le fichier fonctions.php est-il aussi en UTF-8 sans BOM ?

• la connexion à la base de données renvoie bien aussi du UTF-8 ? ("SET NAMES utf8")

Comme on n'a pas de vision d'ensemble, on ne peut que supputer...

• Passez à l'UTF-8 sans manquer une étape

Bonjour :)

Citation:

---

le fichier fonctions.php est-il aussi en UTF-8 sans BOM ?

---

Non, il est en iso-8859-1 (enfin sous np++ il met ça en ANSI). Il était en utf-8 jusqu'à ce que j'ai trop de problèmes et que je demande à mon presta quel encodage était préférable pour mes fichiers ; j'ai donc suivi sa recommandation bien qu'il m'impose la base mysql en utf8 et que le fameux header de toutes les pages du site spécifie lui aussi l'utilisation du charset utf8

Citation:

---

la connexion à la base de données renvoie bien aussi du UTF-8 ? ("SET NAMES utf8")

---

Alors là... disons que j'utilise une fonction de connection old school (avant PDO) :

Code:

---

1 2 3 4 5 6

//fonction connexion BDD function ConnectDbCli() { $base = mysql_connect('localhost', 'cxxx', 'password'); mysql_select_db('cxxx', $base); }

---

Et que je ne sais pas où je devrai mettre ("SET NAMES utf8") avec cette syntaxe :(

Citation:

---

Passez à l'UTF-8 sans manquer une étape

---

Merci, je vais aller réviser ;)

EDIT 10 minutes après :
...et c'est là que ça me bloque :
Pourquoi si tout est en utf-8 on me recommande de coder en ISO ?

...et si je pouvais juste avoir une réponse à cette question du post précédent concernant le fait qu'il ne devrait pas y'avoir de caractères spéciaux dans une base en utf8

Merci... encore :)

Citation:

---

Envoyé par ibill

...on me recommande de coder en ISO ?...

---

C'est à se demander si ce n'est pas ton prestataire qui est... obsolète...

Citation:

---

...si je pouvais juste avoir une réponse à cette question du post précédent...

---

On veut bien, mais vu tous les bidouillages (encodage différents, utilisation ou pas de fonctions telles que uft8_encode, uft8_decode, htmlentities,.... ou autres ?),
ça va être difficile...

Et pour la connexion avec mysql_ :

Code:

---

1 2 3 4 5 6

//fonction connexion BDD function ConnectDbCli() { $base = mysql_connect('localhost', 'cxxx', 'password'); mysql_select_db('cxxx', $base); mysql_set_charset( 'utf8' ); }

---

Citation:

---

C'est à se demander si ce n'est pas ton prestataire qui est... obsolète...

---

Ben c'est sur que cette réponse m'a plus embrouillé qu'aidé :/ et surtout j'ai appliqué et en conséquence converti tous mes fichiers en utf8 vers iso :(

Je viens de tester ça :

Code:

---

1 2 3 4

ConnectDbCli(); //l'appel de ma fonction présentée plus haut mysql_set_charset('utf8'); //une instruction que je n'avais encore jamais utilisée !   $insert_compte = 'INSERT INTO...

---

Et en effet ça rentre bien propre dans la db (à condition de supprimer les utf8_decode que j'avais mis avant sinon "gégé" devient "g?g")
Faut encore que je voie le résultat quand je fais un select pour présenter la page web...

EDIT : Oups je n'avais pas vu toute ta réponse... Ok je vais glisser le mysql_set_charset directement dans la fonction...

Citation:

---

...si je pouvais juste avoir une réponse à cette question du post précédent...
On veut bien, mais vu tous les bidouillages (encodage différents, utilisation ou pas de fonctions telles que uft8_encode, uft8_decode, htmlentities,.... ou autres ?),
ça va être difficile...

---

--> je pensais que la réponse devait juste être théorique^^

++

Re,

Je continue mes pérégrinations...

Donc avec le mysql_set_charset, c'est super pour alimenter la db sans faire de l'utf8_encode
Par contre en récupérant les données de la db pour affichage, là je passe par des fonctions utf8_decode sinon c'est pas "beau"...

Et si ma fonction de connexion au SGBD ne spécifie pas

Code:

---

mysql_set_charset

---

, alors le texte est bien présenté sans passer par les fonctions utf8_decode.

Question : est-il judicieux d'avoir 2 fonctions de connexion (une pour l'écriture dans la db, avec spécification du charset) et l'autre juste pour la lecture (sans notion de charset) ? (oui, ça sent l'usine à gaz...)

Merci en tout cas de m'aider à avancer :)

Il faut TOUT PASSER EN UTF-8 !

Et, si nécessaire, L'IMPOSER au développeur / prestataire extérieur !
(ou en changer)

Déjà que mysql_ est obslolète... depuis au moins 10 ans...

Je voudrais bien tout mettre en utf8 (ce que je fais sur mon Lamp où j'ai la main, mais là ce n'est pas le cas)

Le presta nous a proposé une upgrade mais je travaille en collectivité (=pas beaucoup de sous > pas urgentissime)

Je fais avec les moyens du bord (et mes compétences limitées en php...)

Bon, je retourne ramer...

Citation:

---

gégé

---

C'est que qu'on obtient quand on sur-encode ; par exemple si tu fais uf8_encode sur Février tu obtiens Février

J’arrive un peu tard mais j’aimerais apporter mes cinq centimes : je pense, moi aussi, que le prestataire ne sait pas de quoi il parle.

J’espère que le contenu de la base de données est bel et bien UTF-8, car l’interclassement, lui, ne l’est pas. En fait, latin1_swedish_ci est l’encodage par défaut de MySQL. Heureusement, l’interclassement n’a qu’une petite influence : il agit sur la façon dont les résultats sont ordonnés. Si d’aventure tu demandes à la base une liste ordonnée de mots, et si certains de ces mots commencent par un caractère spécial, tu te rendras peut-être compte qu’ils ne sont pas rangés dans le bon ordre. Par exemple, un mot commençant par « é » sera interprété comme « é » par un interclassement latin, et sera donc rangé parmi les mots commençant par « a ».

Touches-en mot également à ton prestataire. Conseille-lui un interclassement commençant par utf8_ ; personnellement, je recommande utf8_general_ci car il est rapide et convient bien à du texte majoritairement occidental (Europe de l’Ouest, États-Unis).

Fais-lui comprendre que tu maîtrises le sujet ;)

Ok, merci pour vos lumières et conseils.
Dans la précipitation, j'ai joué avec utf8_encode, stripslashes et consorts. C'est lourd mais c'est propre.
A la prochaine :)

Bill