MySQL codage et autres billevesées.

[icebreak]

Je me disais comme ça la, j'ai ma base en UFT-8 depuis quelques temps car mon projet au boulot était billingue.
Mais ca risque d'être unlingue... Je me pose maintenant la question de voir si mon choix de l'UTF-8 est bien justifité à présent, je suis perplexe.

Ce que je pense avoir compris c'est que les Browsers sont en SJIS, les mails c'est un format différents.
Maintenant, j'étais satisfait avec l'UTF, mais ce qui m'interresse c'est de savoir quel est la norme 100% japonaises qui a des chances de rester dans la compétition des encodages dans les 5 prochaines années...
Autant faire le bon choix maintenant...
Alors SJIS ?

En tout cas j'ai mater le NET, et je dis merci a Erwan Et Glandium pour leurs articles sur le sujet que je potasse en ce moment...
Surtout que c'est idiot, j'ai eu Glandium a 20 cm de mois a Okazaki, ai pis la ben maintenant que j'y penses, si j'avais su... je lui en aurais parlé.

Voila

[Wallabee]

Je suppose que tu veux faire une application web.

Pour résumer, tu sais qu'il y a trois charsets japonais principaux:
* JIS (Japanese Industrial Standard), ou ISO-2022-JP
* Shift_JIS
* EUC_JP (Extended Unix Code)

Le JIS est sur 7bits, contrairement aux deux autres (8bits), mais tous sont "multibyte". Sachant que pour des raisons historique, certains serveurs de mails encore en fonctionnement sur internet ne gère que des messages sur 7bits, le JIS/ISO-2022-JP est le format recommandé pour les e-mail. Mais en réalité, la plupart des serveurs actuellement en prod gèrent sans problème les charsets plus modernes sur 8bits. On se demande d'ailleurs s'il existe encore de tels relais en fonctionnement qui ne supportent que les charsets 7bits... Enfin, aucune importance.
Pour l'info, cette histoire de mails avec des charsets sur 7bits ne concerne pas seulement les messages en japonais, mais aussi ceux en français. Et c'est "mal" d'envoyer des messages français en utilisant des charsets ISO-8859-1 ou ISO-8859-15 (8bits), et encore plus mal d'utiliser de l'UTF-8. Il faut normalement utiliser de l'ASCII 7bits (sans accents) en échappant les accents selon les règles du "quoted-printable".

Bref, rappelons que plus personne ne se donne tant de peine aujourd'hui, Internet est moderne, moi-même j'envoie mes mails sur 8 ou 16 bits et je n'en ai pas honte, et l'histoire de JIS/ISO-2022-JP ne concerne pas les clients de mails, ni les serveurs modernes, mais seulement quelques relais historique qui pourraient encore peupler Internet.

Pour Shift_JIS et EUC-JP, il s'agit globalement de deux charset japonais 8 bits (mais multibyte), très utilisés sur le web japonais. Shift_JIS est developpé par Microsoft, mais n'est pas très "standard": la version normalisée ne correspond pas à celle répandue, ce qui peut entrainer des erreurs. Cependant, personne n'utilise la version "standard" et tout le monde utilise la version "Microsoft", ce qui résoud les problèmes. EUC-JP est maintenu par le membre JVC du OpenGroup (http://www.opengroup.or.jp ), et est un peu plus standard, même s'il existe plusieurs versions de ce charset.

Shift_JIS est utilisé pour les codages internes historiques des systèmes Windows et DOS, EUC pour les systèmes UNIX. L'analogie la plus simple est de revenir à l'histoire des différents retours au chariot pour DOS/Windows et UNIX: \r\n pour Windows, \n pour Unix. Quand tu développes sous Windows, tu utilises généralement des retours Windows, mais si tu développes sous Unix, tu utiliseras plutôt des retour Unix. Si tu développes sous Windows et que ton site est hébergé sous Unix, tu vas aussi faire en sorte qu'il soit au retour Unix ("transfert FTP ASCII" et non BINARY).

Pour les charsets, c'est à peu près pareil, et comme je suppose que ton serveur/ta DBMS sont sous Unix, il vaut sûrement mieux que tu choisisses un encodage "EUC-JP" pour ta base de donnée.

Les navigateurs afficheront la page correctement, qu'elle soit Shift_JIS ou EUC-JP. Si tu prends les sites existant, il y en a en Shift_JIS (ex: www.sony.co.jp ), d'autres en EUC-JP (www.yahoo.co.jp ), etc.. Pas de quoi tirer de règle générale donc.

Par contre, certains système à part auront des exigences sur le charset à utiliser, par exemple les sites compatible imode doivent être dans une certaine version de Shift_JIS.

Pour ce qui est de l'avenir, ce qui marche aujourd'hui fonctionnera probablement encore dans plusieurs années: les japonais ne sont pas moins feignants que les autres pour ce qui est de mettre à jour et abandonner les vieux standard.

Enfin pour finir, et pour t'embrouiller un peu avec des question de pérennité, on pourra remarquer les recommandations du W3C concernant les charset japonais dans des documents XML, qui disent globalement:



For full interoperability in the Internet, migration from Shift-JIS|EUC-JP|etc.. to UTF-8/UTF-16 is highly recommended.


http://www.w3.org/TR/japanese-xml/

EDIT: tu aurais pu donner les références des articles que tu étais en train de lire, ça m'aurait (sûrement, parce que je ne sais toujours pas de quoi il s'agit) évité de répéter certaines choses.

[icebreak]

Non non c'est parfait comme explication.
Je me sens faire du Shift-JIS, d'abord parceque c'est le codage que j'ai vu le plus en action (Et je suis full windows, base sous Windows etc...).
J'ai pratiqué récemment les notes pour Ezweb et mes tests en Shift-JIS ont eu l'air d'être concluant.

J'ai pour le moment ma base en UTF-8 mais si mes pages le deviennent j'ai peur du Mojibake, car on a tous l'expérience d'un browser qui sur une page de français vous met des kanjis a la place des accents, et ceux sans règles logiques puisqu'une fois sur deux parfois vous avez la page normale.

Et comme le péquin habituel ne sait pas changer le codage...
L'UTF-8 c'est bien quand même je trouvais ;)

[erwan]

Tous les navigateurs recents gerent bien tous les codages, sauf sur les telephones portables (pour le moment). Donc si tu veux faire un site ezweb tu n'as pas le choix du codage, c'est je crois sjis.

Mais sinon une regle generale si tu ne veux pas avoir de problemes a l'avenir (en particulier si tu veux passer a du multilingue ou autre) c'est d'utiliser l'unicode quand c'est possible. Il y a quelques polemiques sur l'unification des caracteres Han, mais c'est quand meme nettement meilleur que les codages monolingues, et dans le cas d'utf8 ca ne prend quasiment pas plus de place.

[icebreak]

Ce qui me fait peur c'est le Mojibake.
Je vois mon cas, avec un PC sur Windows FR, toutes les polices installées, la gestion des caractères japonais, IME, etc.. et bien sur la mise des deux langues avec le français en préférée dans le navigateur....

Et parfois sans raison apparente, dans un même site, mon codage "saute" et me mouline les accents en kanjis.
Parfois une page parfaitement reconnu en japonais, passera un jour, sans savoir pourquoi, en mojibake.

Si je sais comment résoudre cela en deux coup de click de souris, il n'en vas pas de même de tous les utilisateurs lambda. Et c'est ce qui fait que je trouve le Shift-JIS si attrayant, je l'ai vu dans nombre de codage pour site japonais. l'unicode fais tout mais ce n'est pas encore la panacée à mon goût.

[Wallabee]

Laisse-moi deviner.. tu déclares correctement le charset dans tes en-têtes HTML (Content-type), mais tu utilises un sale apache 2 mal configuré, qui force par défaut un charset à ISO-8859-1, en ignorant celui que tu as défini dans le document HTML ?

Si c'est le cas, désactive la directive AddDefaultCharset (AddDefaultCharset Off) dans ton httpd.conf, ou remplace sa valeur par défault ISO-8859-1 par celle souhaité, UTF-8 par exemple.

Le navigateur choisi le charset à utiliser selon la valeur Content-Type fournie par le serveur web. Si le serveur web ne fournie pas de telle valeur, celle indiquée dans le document HTML par HTTP-EQUIV (ie: comme son nom l'indique) prendra effet. Mais celle-ci sera ignorée si le serveur web déclare autre chose dans les en-tête HTTP (qui ont donc précédence sur les en-tête HTML HTTP-EQUIV).

Mais, comme le dit erwan, tu n'as peut être pas le choix du codage. Commence donc plutôt par configurer correctement ton serveur web.

[icebreak]

Attention, le cas du mojibake faisait allusion a un site lambda et il ne s'agissait pas d'un problème inhérent a mon serveur.
D'ailleurs en y réfléchissant, avec MySQL en UTF-8 et mes pages en SJIS (mais qui sorte pour le moment que du Français) je n'ai pas eu de problèmes de mojibake....

Mais je ne sais plus trop a quel saint me vouer apres avoir lu cela :
http://jp2.php.net/mbstring


Dont EXTRAIT :
Exemple 1. Jeux de caractères qui risquent de ne pas fonctionner en PHP
JIS, SJIS, ISO-2022-JP, BIG-5

Et mention a Erwan(Encore un Extrait) :
Les pages Web créées pour les téléphones portables comme i-mode, Vodafone live!, ou EZweb sont supposées utiliser l'encodage Shift_JIS.

[erwan]

Wallabee a raison, le mojibake vient generalement des pages qui n'annoncent pas leur codage ou qui sont sur un serveur qui envoie des en-tetes fausses.

Pour Mozilla et Firefox il y a la fonction Character Coding -> autodetect -> Japanese pour resoudre ca, pour les autres navigateurs je ne sais pas.

En tout cas ce genre de probleme ne se resoud pas en choisissant un codage plutot qu'un autre, il faut simplement que le serveur soit bien configure.

Pour savoir d'ou vient le probleme:
http://validator.w3.org/

[Kelesis]

Merci erwan pour ce lien très utile.

En ce qui concerne les webmails, étant donné que le codage ne se sélectionne qu'au niveau de la page, j'ai déjà eu droit à de belles surprises lorsque mon navigateur tente de m'afficher la liste des sujets des messages dont certains sont codés en Unicode/UTF-8 et d'autres en Shift-JIS.

Quelquefois j'obtient une suite interminable de kanjis sans aucune signification...

Je vois pas vraiment de solution possible dans ce cas...