Josselin Mouette wrote:
Le sam 06/03/2004 à 23:56, Denis Barbier a écrit :Quand le codage peut être spécifié, ce qui est le cas dans l'immense majorité des cas (le contre-exemple flagrant étant le nommage des fichiers), on n'a pas besoin d'imposer un codage unique.Nous sommes bien d'accord (à part pour « immense majorité des cas »). Mais un codage en particulier ne peut pas tout décrire. Si j'envoie un mail ne contenant que des caractères pouvant être décrits en iso8859, il sera encodé ainsi par evolution (cf. les autres mails de cette discussion). Maintenant, si je mets des kanji (日本), il va être encodé en utf-8. On en revient au même point. Et c'est pareil pour le web : si tu veux une page avec à la fois du Français et du Japonais dessus, tu auras du mal sans utiliser utf-8.
En fait, on peut très bien mettre du français et du japonais sur la même page, aussi bien en SJIS qu'en ISO8859-1... il suffit pour ça d'utiliser des entités à la place des caractères qui sont pas supportés par le codage utilisé... Mais c'est plus lourd que les 3 octets max d'un caractère en UTF-8. D'ailleurs, c'est con pour les japonais, mais la plupart des caractères japonais prennent 3 octets en UTF-8... alors qu'ils n'en prennent que 2 dans les codages "à l'ancienne". Cela dit, les japonais n'utilisent que très peu UTF-8...
Quand bien même c'est possible d'avoir l'information sur l'encodage, ça ne suffit pas toujours. Je suis encore tombé sur un exemple à la con : les signets à paramètres de galeon (ou autre). Quand tu vas sur google.fr et que tu cherches un mot avec des accents, il se démerde avec l'encodage en envoyant le formulaire, car la page de départ contient un encodage (iso8859-1 ici). Mais quand tu veux faire une recherche en utilisant directement un signet, tu n'as pas l'information sur l'encodage dans lequel le site à l'autre bout veut ses informations. Et, corrigez-moi si je me trompe, autant HTTP précise un encodage pour ce que le serveur envoie, autant le client ne peut pas préciser en quoi son URL est encodée, et doit donc présupposer qu'elle est en utf-8. Et ma recherche sur Rémi se transforme en Rémi.
Oui, c'est le truc le plus con à propos d'HTTP : la plupart des échanges entre serveur et client n'ont aucune indication de codage. Autrement dit, c'est le foutoir. On ne peut pas savoir si les champs d'un formulaire ont été remplis en UTF-8, en ISO-bidule ou en ISO-machin...
Alors oui, généraliser les méta-données sur l'encodage est une bonne chose, mais ça ne suffit pas, et c'est de toute façon inutile si tu veux un système vraiment multilingue.
C'est d'autant plus indispensable que l'UTF-8 fait des recouvrements de glyphes entre le chinois, le japonais et le coréen, ce qui peut poser des problèmes, parce que ces caractères qui sont censés se ressembler, ne s'écrivent en fait pas de la même manière dans les 3 langues. Du coup, il faudrait une méta donnée pour savoir quelle police utiliser pour que le texte soit correctement écrit. Un comble, quand même... Et sans rentrer dans ces détails pervers de l'UTF-8, si j'écris un truc du genre :
日本の女性が美しい。Quelqu'un qui serait aware peut facilement dire que c'est du japonais, du fait qu'il y a des hiraganas, et du coup saurait comment le lire.
Par contre : 無能薬栽培Chinois ? Japonais ? Personnellement, je ne connais pas le chinois. Ce mot existe peut-être et si tel est le cas, il aurait une certaine lecture. En tout cas, en japonais, il existe, et il se lit munôyakusaibai. Notez qu'il y a le même genre de problématique dans les langues occidentales... puisque les racines lointaines sont les mêmes... certains mots s'écrivent pareil. Dans de tels cas, s'il n'y a pas de contexte, on ne peut pas savoir le mot de quelle langue est utilisée.
Bref, les problématiques de m17n sont loin d'être résolues... Mike