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
