Question

Si tout ce que vous voyez, ce sont de vilaines cases sans caractères, quels outils ou stratégies utilisez-vous pour comprendre ce qui n'a pas fonctionné ?

(Le scénario spécifique auquel je suis confronté est celui des cases sans caractères dans un <select> alors qu'il devrait afficher des caractères japonais.)

Était-ce utile?

La solution

Premièrement, les « vilaines boîtes sans caractères » ne sont peut-être pas un problème d'encodage, elles peuvent simplement être le signe que vous n'avez pas installé de police capable d'afficher les glyphes dans la page.

La plupart des problèmes de codage de caractères surviennent lorsque des chaînes sont transmises d'un système à un autre.Pour les applications Web, cela se situe généralement entre le navigateur et l'application, entre l'application et le système de fichiers et entre l'application et la base de données.

Vous devez donc vérifier d'où proviennent les données mal codées, quel codage de caractères elles ont à la source et sous quel codage elles sont reçues.Le meilleur moyen est d'envoyer des personnages avec lesquels vous savez que le système rencontre des problèmes et de les examiner à chaque niveau de l'application.À quoi ressemblent-ils dans l’application ?Dans la base de données ?Quand les récupérerez-vous de la base de données ?Quand sont-ils affichés dans le navigateur ?

Désolé d'être si général, mais la question ne donne pas beaucoup plus de travail.

Autres conseils

Si les données que vous envoyez au navigateur sont mutilées (moji-bake), vous obtiendrez des caractères indésirables.De plus, si vous spécifiez un mauvais jeu de caractères dans vos en-têtes META, votre navigateur affichera la page de manière incorrecte, provoquant à nouveau un moji-bake, parfois à des endroits aléatoires de la page.

Lors de la manipulation des jeux de caractères CJK, vous devez vous assurer d'utiliser le codage de caractères UTF8 tout au long de la durée de vie de votre programme (stockage des données, récupération, manipulation des données dans votre code, affichage dans le navigateur etc...)

Qu’est-ce que UTF8 ?UTF8 gère les flux de données binaires, pas les chaînes.Cela signifie que les combinaisons de bits peuvent avoir une longueur variable.Les caractères ASCII ont une longueur fixe de 8 bits représentant 1 octet, cependant les caractères UTF8 peuvent être composés de 6 bits, 8 bits, 12 bits, etc...En tant que tel, UTF8 est sujet à ce que les Japonais appellent « mojibake ».

En tant que codeur, de la base de données à la base de code en passant par le navigateur, vous devriez essayer d'utiliser complètement UTF8.Pour le courrier électronique, vous pouvez utiliser UTF8, mais vous constaterez probablement que la plupart des serveurs et clients de messagerie sont encore anciens et utilisent un méli-mélo de jeux de caractères différents (par ex.ISO9022X).

Paramètres de base de donnéesSi vous êtes un utilisateur MySQL, assurez-vous que toutes les connexions à la base de données utilisent UTF8 et que toutes les tables/champs utilisent UTF8.Par défaut, MySQL utilise des jeux de caractères latins (suédois).Ces Suédois fous adorent leur sens de l'humour !!

Vérification de votre base de codeD'après mon expérience, des éditeurs comme Notepad++, Notepad2, UltraEdit, e, etc...tous ont des problèmes de support UTF8.Ils fonctionnent pour la plupart, mais comme leurs développeurs n'utilisent pas eux-mêmes les langages CJK, ils ne sont pas perfectionnés.Des problèmes tels que la désactivation de la nomenclature (Byte Order Mark), des onglets mutilés, une mauvaise conversion du jeu de caractères, etc.tous les problèmes actuels.

Je recommande fortement d'utiliser un éditeur UTF8 éprouvé comme Maruo.Ceci est réalisé par une société japonaise, mais il existe une version anglaise (et une version d'essai) sur http://www.hidemaru.interlink.or.jp/software/

Enfin, vous devrez peut-être convertir vos fichiers sources en UTF8.Surtout si la base de code elle-même contient des chaînes de langage CJK.

Manipulation des chaînesToute fonction de chaîne doit être sécurisée sur plusieurs octets.Remarquez que je n'ai pas dit double octet.UTF8 n'est pas un double octet mais un multioctet, en fonction du nombre total de bits utilisés pour représenter un caractère.En PHP, vous devez appeler spécifiquement les fonctions de chaîne MB.Ruby et d'autres langages ont une prise en charge plus transparente, mais vous devez vérifier la documentation pour votre version de serveur d'applications !

Balises METAConsultez google.co.jp ou yahoo.co.jp pour leurs en-têtes META.Ce sont des sites qui savent s’y prendre correctement.Incluez essentiellement la balise META suivante dans le document <HEAD>

<meta http-equiv="content-type" content="text/html;jeu de caractères=utf-8">

Il est généralement prudent de mélanger également les attributs de type de document HTML anglais avec le caractère ci-dessus.Ainsi, l'ajout de la balise META ci-dessus semble fonctionner dans un document HTML contenant :

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">

E-mailIl s’agit là d’une boîte de Pandore totalement différente.UTF8 fonctionne beaucoup, mais de nombreux clients japonais plus anciens utilisent davantage ISO2022X.Cela ne vaut pas la peine d’être abordé ici.

Débogage des problèmes UTF8Une fois que vous disposez d'un éditeur UTF8 fiable comme Maruo, vous pouvez créer des pages statiques et résoudre vos problèmes.

J'espère que cela pourra aider

Redirigez les données vers le disque et utilisez un Éditeur hexadécimal.La plupart des éditeurs/visualiseurs de texte effectuent leurs propres conversions en coulisses, il est donc difficile d'être sûr que vous voyez les données sous leur forme réelle.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top