Bug incompréhensible encodage UTF-8

Bonjour à tous,

Je fais appelle à vos lumières, non sans m'être passablement cassé la tête pour trouver une solution et avoir écumé tous les forums et aide possibles.

Mon problème est le suivant :

Suite à un changement de serveur, j'ai décidé de passé d'un encodage "Europe occidentale" et maintenant "utf-8".
J'étais auparavant chez PHPNET sur un mutualisé, et je suis dorénavant sur un KIMSUFI OVH dédié. Une bonne partie du site est bien passée.

Mais voilà... Plutôt que de vous exposer toutes mes recherches et tests, je vous colle une devinette :

Comment puis avoir des caractères qui s'affichent correctement sur cette page (regardez les pays):
http://www.cecif.com

Et pas sur celle là :
http://www.cecif.com/entreprise/annonces/vente_et_achat_de_produits_ou_de_services.html

PS: Regardez la liste pays en bas à droite, elle provient d'un fichier php en include, et il s'agit du même fichier pour les deux pages.

Comment est ce possible?

J'utilise Dreamweaver CS3 avec utf-8 par défaut en préfs.

Merci de me faire partager vos experiences.

Cordialement
Modifié par mattman (09 Nov 2007 - 19:30)

Le problème vient peut-être de la base SQL, non ? Est-elle en utf8 ? J'avais eu un problème similaire il y a quelque temps et ça provenait de la base de données.

Bonjour,

Pour commencer, es-tu allé faire un tour du côté de la FAQ du forum, pour lire notamment: Comment bien déclarer l'encodage des caractères d'un document ?
Comme ton encodage n'est toujours pas déclaré dans les en-têtes HTTP, je suppose que non?

Déclarer l'encodage dans les en-têtes HTTP sera à faire, mais ça n'est pas ce qui pose le problème à priori.

Tes pages sont déjà interprétées en UTF-8. Mais ponctuellement, tu as des contenus avec des caractères qui ne passent pas et qui sont remplacés par un point d'interrogation. En général, ce sont des contenus en iso-8859-1 (latin1), insérés directement dans une page déclarée en UTF-8.

Donc il te reste des contenus en iso-8859-1 (ou peut-être en iso-8859-15 ou en windows-1252). Il faut repérer lesquels, et se demander d'où ils viennent:
- d'un fichier sur ton serveur?
- de ta base de données?

Le plus souvent, c'est le deuxième cas qui pose problème.
Mais commence déjà par identifier clairement le problème.

Note: j'ai vu des problèmes sur les deux pages indiquées, pas uniquement sur la seconde.

Oui, j'ai bien regardé la FAQ.

Il s'avère que tout est bien déclaré en UTF-8, mais à priori, le problème vient des fichiers.

J'explique, dans dreamweaver, j'ai beau indiqué que le codage est en UTF-8, je sauveegarde, j'upload, puis je redownload, et la , le fichier est revenu en Europe occidentale...
C'est a se casser la tete..
Comment le fichier peut-il changer de codage et surtout, comment le les caractères issus du même include PHP peuvent ils etre une fois interpreté par le navigateur comme UTF8 donc s'afficher bien sur la page d'accueil, puis mal s'afficher dans la page annonces !!!?

C'est parfaitment illogique.

Il y a aussi parfois l'utilisation de certaines fonctions PHP de traitement des chaines de caractères qui ne gèrent pas bien l'UTF-8, il me semble. Mais je connais mal le sujet.

Si tu affiches directement le fichier qui contient ton contenu théoriquement-en-utf-8-mais-des-fois-oui-des-fois-non (ou si tu fais un include simple et echo tout bête dans un fichier créé pour le test), qu'est-ce que ça donne?

Et est-ce que l'affichage du contenu de ce fichier dans les différentes pages se fait exactement de la même manière?

Bonsoir,

le problème vient bien d'un traitement par script à mon avis. En effet changer l'encodage manuellement en iso-8859-1(5) ne corrige pas le problème.
L'UTF8 est corrompu, probablement par une fonction de type str_replace().

Exemple réel rencontré (le sujet doit être un peu plus bas dans ce forum):

str_replace(chr(160), ' ', $str);

Ceci marche parfaitement sur du iso-8859-1 (suppression des espaces insécables), mais corrompt la plupart des accents en UTF8.


Pour en revenir à ton cas: un accent aigu en UTF8 affiché en iso devrait être é hors si l'on regarde ceux qui bug ils sont affichés: ã© (noter la minuscule).

J'avais exactement le même problème :
Vérifie bien que :

- 1 : Dreamweaver soit bien en UTF8 dans les options ;
- 2 : Les pages sont enregistrées sur dremweaver au format UTF8 et que les accents n'aient pas été remplacés lors de l'ouverture du fichier ; en bref : ouvre une page au hazard, avec UFT8 par defaut dans dreamweaver. Vérifies que les accents sont correctement visible dans le code source de dreamweaver. Enregistre et upload à nouveau.
- 3 : Que la base de données (MySQL ?) soit bien au format UFT8 ainsi que les tables et les champs.
- 4 : Si ça ne fonctionne pas, crée une page test.php avec un texte (peu importe lequel) comprenant toute sorte d'accent : si il s'affiche correctement, c'est que celà vient de la base de données et il ne restera plus qu'à effectuer des tests avec celle-ci pour bien cibler le problème.

Pour moi, le problème venait de la seconde solution, lorsque j'ai changé d'éditeur j'ai du tout enregistré de nouveau toutes mes pages avec le nouvel éditeur alors que l'encodage n'avait pas changé ... allez savoir pourquoi ...

Un autre exemple concret sur sur mon site, tout est en UF8 :

Le message affiché à l'écran :
- Test de la messagerie privée.
Le message tel qu'il est enregistré dans ma base de données :
- Test de la messagerie privée.

Gaylord.P a écrit :
Le message tel qu'il est enregistré dans ma base de données :
- Test de la messagerie privée.

Il est enregistré comme ça, ou bien il est affiché comme ça par PHPMyAdmin?
Parce que PHPMyAdmin, c'est une application web, donc au final une page web, qui peut être servie en iso-8859-1... si tu as des données en UTF-8 et que tu les affiche dans une page en iso-8859-1, tu auras bien sûr ce genre de résultat.

Il est enregistré ainsi dans PHPMYADMIN en tout cas ... mais du moment que ça s'affiche bien moi je m'en fiche hein.

Gaylord.P a écrit :
Il est enregistré ainsi dans PHPMYADMIN en tout cas

Le champ n'est pas enregistré dans PhpMyAdmin, il y est uniquement affiché (il est enregistré dans la base de données qu'affiche PhpMyAdmin). Si toute la base est en utf-8, il peut être utilise de configurer PhpMyAdmin pour que les pages qu'il affiche soient en utf-8 également. Ça facilite aussi la saisie de données dans PhpMyAdmin.
Modifié par Florent V. (10 Nov 2007 - 17:36)

Certes et j'aimerais pouvoir le faire. Maintenant, dans mon navigateur, l'encodage est UTF8 et dans PHPMYADMIN, l'encodage par defaut est utf8_unicode_ci ; la question est donc d'où vient l'erreur ? Même s'il n'y en a pas vraiment.

<mode=partially HS>

Florent V. a écrit :
Il y a aussi parfois l'utilisation de certaines fonctions PHP de traitement des chaines de caractères qui ne gèrent pas bien l'UTF-8, il me semble. Mais je connais mal le sujet.

Pour info : Ce sont toutes les fonctions qui prennent en compte la longueur des chaînes (ce qui s'explique assez facilement puisqu'un caractère unique peut prendre jusqu'à 4 octets en utf-8), donc strlen bien sûr, mais également strncmp, etc... Du coup, les scripts non prévus pour un fonctionnement en utf-8 sont à déconseiller.
</mode>

Gaylord.P a écrit :
J'avais exactement le même problème :
Vérifie bien que :

- 1 : Dreamweaver soit bien en UTF8 dans les options ;
- 2 : Les pages sont enregistrées sur dremweaver au format UTF8 et que les accents n'aient pas été remplacés lors de l'ouverture du fichier ; en bref : ouvre une page au hazard, avec UFT8 par defaut dans dreamweaver. Vérifies que les accents sont correctement visible dans le code source de dreamweaver. Enregistre et upload à nouveau.
- 3 : Que la base de données (MySQL ?) soit bien au format UFT8 ainsi que les tables et les champs.
- 4 : Si ça ne fonctionne pas, crée une page test.php avec un texte (peu importe lequel) comprenant toute sorte d'accent : si il s'affiche correctement, c'est que celà vient de la base de données et il ne restera plus qu'à effectuer des tests avec celle-ci pour bien cibler le problème.

Pour moi, le problème venait de la seconde solution, lorsque j'ai changé d'éditeur j'ai du tout enregistré de nouveau toutes mes pages avec le nouvel éditeur alors que l'encodage n'avait pas changé ... allez savoir pourquoi ...

1. Dream est bien en utf8 dans les preferences

2. Je change la proprieté de la page en utf8 d'une page php. JE sauvegarde, je ferme la page tjrs en local, je la réouvre depuis le local.. et la je re-regarde le codage de la page et bim le revoila en europe !!
C'est quoi cette hallu !!

3. Ma base est bien en utf8_unicode_ci, par contre voilà ce que je trouve à propos de ma table :
format : dynamique
Interclassement : utf8_general_ci
et à part l'interclassement, je n'ai pas la possibilité de changer quoi que ce soit, et la base en elle meme est bien en utf-8.

4. j'ai créée la page test.php.. dans le même dossier que le menu de droite.
CA marche nickel :

http://www.cecif.com/static/test.php

Merci pour votre temps.

Dreamweaver CS3 crée les fichiers en UTF8, mais je ne pense pas que les données soit en UTF8 ...
Quand je crée un fichier avec Dreamweaver, que j'enregistre des données (avec accents). Si j'affiche ce fichier dans une page UTF8, j'ai des ? dans un losange.
Pour corriger ca, j'ouvre le fichier avec le bloc note, et je l'enregistre en précisant Codage : UTF8. plus de problème ...

Personnellement, j'ai trouvé beaucoup d'informations pour convertir un site en utf-8 sur ce blog avec, la necéssité de convertir les structures et les données et, la requête miracle à lancer immédiatement après la connexion avec la base de données (elle notifie des échanges en utf8) :

mysql_query('SET NAMES utf8');

Bon courage, mais l'utf8 ne constitue pas actuellement la panacée pour les traitements de chaînes de caractères...

En particulier, la réécriture de noms et prénoms en bonne et due forme (avec leurs éventuelles particules et majuscules initiales parfois accentuées) et la constitution de listes alphabétiques nécessite quelques traitements (suppression des accents, rejet des particules...) beaucoup plus aisés en iso-8859-1 qu'en utf-8 (voir le sujet supression des accents en utf8).

Par ailleurs, l'utilisation d'Ajax semble imposer l'utilisation de l'utf8 ???

Dans ces conditions, sous réserve de vérification du fonctionnement des inclusions (proposées par Hayoan dans le sujet déjà cité), nous semblons condamnés à devoir jongler avec les conversions...