Pas facile de faire un site en coréen ou de surfer sur le web israélien quand on n’a pas acheté le super kit linguistique ou fait installer son ordinateur à Moscou. « Ne mettez pas d’accents dans vos mails ! » se fait-on intimer dès qu’on a des correspondants à Hongkong, à Gaza ou sur Vénus...
Les accents et l’internet ? une histoire d’huile et de vinaigre.
Défrichage
Au commencement était l’ASCII [1]. Les ordinateurs devaient pouvoir se parler, ils n’avaient pas vraiment envie de déclamer l’« ΙΛΙΑΔΟΣΑ » (l’Illiade) mais plutôt de dialoguer sur le mode
220 rezo.net ESMTP Postfix
EHLO dido.nowhere.edu
250-rezo.net
250-PIPELINING
250-ETRN
250-XVERP
MAIL FROM: <jacques@nowhere.edu>
250 Ok
RCPT TO: <spip@rezo.net>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>Il fallait que ça circule, peu importait vraiment comment, on verrait plus tard...
Un peu plus tard, on a vu : l’ordinateur personnel est arrivé, et pour le vendre sur le marché européen, il a fallu ajouter quelques accents pour pimenter un peu la sauce. Chaque constructeur a donc dispersé un peu au hasard les caractères qu’ils n’utilisaient pas : comme tout était codé sur 8 bits, cela faisait 255 codes à remplir (255 = 28 - 1, tu vois), et les tables de « codes ASCII » (au pluriel) ont commencé à se multiplier, évidemment incompatibles entre elles.
A l’est, on inventait d’autres codages pour caser quelques idéogrammes ou passer du cyrillique. Nos amis grecs s’envoyaient des mails en greeklish (une translittération, qui attribue une lettre de la table ASCII à chaque lettre grecque), nous pestions contre le manque d’accents dans les forums, bref, tout partait à vau-l’eau.
Ces bricolages étaient parfois sympathiques, parfois franchement grotesques. Il suffit de regarder comment est composé le pur délire nommé quoted-printable, celui-là même qui pendant des années a transformé les mails en séries de =E9=E7=3C=3C illisibles, et qui continue à nous pourrir la vie, ou de voir en détail le codage des lignes Subject: des mails dès qu’ils contiennent des accents [2].
|
Une faute de Français
C’est un certain D., négociateur français représentant l’AFNOR (Association française de normalisation) auprès de l’ISO (Organisation internationale des standards) qui a sacrifié, en 1987, l’e-dans-l’o (œ) - tout simplement parce que ce caractère n’existait pas sur les imprimantes de son employeur Bull... Oublié des premières listes de caractères dits latins, au même titre que le ÿ majuscule, notre ami l’e-dans-l’o le paie encore, et s’il est facile sur le net de voler un oeuf, il est plus dur d’y voler un bœuf ou de se rendre à L’HAŸ-LES-ROSES. Toute la lumière sur cette sombre histoire d’imprimante est faite par le chercheur en informatique Jacques André dans cet article (fichier au format PDF, publié sur le site GUTenberg). |
Mais ce qui nous intéresse aujourd’hui - soyons positifs ! - c’est ce qui marche, ou en tout cas ce qui peut marcher.
Déchiffrage
Une foultitude de listes de caractères se disputent le marché de la comprenance informatique : évidemment incompatibles les unes avec les autres, elles tentent de caser un alphabet dans les pauvres 255 cases qu’offrent les représentations sur 8 bits.
Une page web qui parle cyrillique commencera donc par déclarer « j’utilise le jeu de caractères windows-1251 » [3], et enverra ensuite les caractères numéros 162-165-137 pour dire ляю ; évidemment, un navigateur mal-comprenant croira qu’il s’agit de caractères iso-latins et affichera àÉè [4]. Tout cela ne nous avance guère. D’ailleurs vous avez certainement du mal à lire ce texte si vous avez un navigateur mal-comprenant.
|
Pause téléchargement
Il y a des navigateurs corrects aujourd’hui sur le marché : Mozilla ou Chimera sur certains systèmes, Omniweb, certaines versions récentes d’Internet Explorer, etc. Il faudra aussi probablement installer des polices de caractères. Si vous n’avez pas déchiffré ci-dessus quelque chose qui évoque, en grec, ILIADOSA ou, en russe, lyayu, il est temps d’aller télécharger quelque chose de plus moderne, ou d’abandonner toute idée de faire un site en navajo... Voici, pour vous allécher un peu, un petit échantillon
l’ordi sur lequel ce texte a été édité ne connaît ni l’arabe, ni l’ourdou, ni l’hébreu, ni... [5]. Pour savoir ce que vous devriez voir ci-dessus, je vous renvoie à la page kermit95, qui contient des photos d’écran. |
Codages
Ils sont nombreux, les codages qui circulent sur le réseau : rien que pour l’iso-latin, il en existe deux versions, l’une appelée iso-8859-1 (celui qui a oublié l’œ), l’autre dénommée iso-8859-15 où le symbole euro (€-€) fait son apparition aux côtés du malheureux œ. Le cyrillique, le japonais ont plusieurs versions aussi, les deux versions du chinois occupent beaucoup plus de caractères que les malheureux 255 possibles si on se cantonne à 8 bits... c’est le bazar, mais en même temps c’est le « standard du marché » : si vous faites un site en cyrillique, c’est pour être lu par des gens qui ont peut-être un vieux PC avec Mosaic 1.3, lequel ne sait peut-être lire que le codage windows-1251.
Pour servir le maximum de monde, il faut trouver un plus petit dénominateur commun, et la fragmentation des différents charsets bidouillés à droite et à gauche ne facilite pas la tâche. Faites des essais, demandez à vos correspondants de vous montrer des sites qu’ils « voient » correctement et essayez de voir comment elles sont encodées...
La voie d’unicode
Après des années de tergiversations, le petit monde des standardiseurs et régulateurs a fini par accoucher d’une norme unique appelée (bel optimisme !) unicode et qui contient tous les caractères utilisé sur la planète, et plein de cases libres pour accueillir la riche typographie martienne ou vénusienne quand SETI@Home aura débouché sur quelque découverte...
Unicode, donc, affecte un numéro à chaque lettre, qu’on peut donner avec la notation U-0000004A (U- suivi du code hexadécimal à 8 chiffres du nombre qui représente le caractère choisi, ici un point-virgule « ; »). Mais que faire de ce numéro ? Il faut, là encore, choisir un codage pour représenter les suites de caractères unicode.
La chaîne de caractères « l’ΙΛΙΑΔΟΣΑ », en unicode, se compose ainsi de la série de numéros 108, 39, 921, 923, 921, 913, 916, 927, 931, 913. Pour mettre cette série de nombres dans un fichier, il y a, comme toujours, plusieurs manières de procéder.
Les entités HTML
Dans ce codage, on représente chaque caractère « exotique » par l’entité &#numéro ;. Notre chaîne est donc représentée par
Cette représentation a l’avantage d’être totalement compatible avec le HTML existant. Au pire, si le navigateur ne connaît pas le caractère demandé, il affichera un point d’interrogation ou le numéro de l’entité. Mais elle a un gros désavantage en termes de stockage et de traitement de l’information : un article écrit en russe et stocké sous forme d’entités HTML prend beaucoup plus de place que le même article stocké dans le charset windows-1251 (chaque caractère en effet se voit représenté par 5 ou 6 octets : &, #, chiffre, chiffre, point-virgule). Et pour faire des traitements sur ce genre de choses (un moteur de recherche en texte intégral, par exemple), c’est coton !
Le codage UTF-8
UTF-8 est un mode de représentation des chaînes unicode complet, qui, à l’encontre de tout ce qu’on a montré précédemment, ne procède pas d’infâmes « bidouillages ».
Pour savoir si votre navigateur comprend l’UTF-8, pointez-le sur cette page de tests.
Ca n’est complet sur aucun des navigateurs que j’ai testés, mais on affiche déjà pas mal de choses.
Disons-le tout de suite : UTF-8 est le mécanisme qu’il aurait fallu adopter dès le départ, en lieu et place de l’ASCII ; tous les programmes auraient été programmés avec cette représentation des chaînes de caractères, et on n’aurait pas eu à écrire des usines à gaz pleines de filtres et de convertisseurs. Les programmeurs auraient tous eu à disposition des bibliothèques de fonctions compatibles UTF-8, et tout fonctionnerait sans poser de question.
Il est toujours temps de remettre les pendules à l’heure. Chacun va s’employer à rendre ses programmes compatibles UTF-8, et bientôt le Net aura repris le chemin de Babel (... rêve ! Encore aujourd’hui, dans certaines facs américaines, et des plus prestigieuses, on ne peut pas recevoir d’emails avec des accents français : les « é » sont transformés en « i »...). Disons, de manière plus réaliste, que certains logiciels vont s’améliorer, et qu’on pourra surfer en japonais sur certains sites, ce qui n’est déjà pas si mal et tellement beau (surtout quand on ne lit pas le japonais).
A quoi ressemble l’UTF-8 ?
Chaque caractère unicode, on l’a vu, est un nombre compris entre 0 et 2^31-1 (soit, en hexadécimal, 0x7FFFFFFF, et en représentation décimale le très parlant 2 147 483 647). Evidemment, si on n’a que peu de caractères « exotiques » à faire passer, il n’est pas très efficace de passer à chaque fois les 31 bits d’information.
Les plages de numéros sont donc découpées en strates superposées, la première plage (caractères ASCII de base) étant représentée sur un octet (7 bits, car le premier des 8 bits qui composent un octet vaut 0 pour signaler qu’on est sur le dernier octet de la série), la deuxième (caractères composés, accentués, etc.) sur 2 octets (11 bits), la troisième (caractères exotiques) sur 3 octets (16 bits), etc., la dernière (la plus vaste, tout l’empire des caractères martiens et vénusiens) occupe 6 octets (pour un total de 31 bits de données) :
| caractères unicode | octets |
|---|---|
| 0 à 127 (U-0000007F) | 0xxxxxxx |
| U-00000080 - U-000007FF | 110xxxxx 10xxxxxx |
| U-00000800 - U-0000FFFF | 1110xxxx 10xxxxxx 10xxxxxx |
| U-00010000 - U-001FFFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
| U-00200000 - U-03FFFFFF | 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
| U-04000000 - U-7FFFFFFF | 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
Ainsi en UTF-8, pour écrire « tête », on aura la séquence d’octets
116-195-170-116-101116 (« t ») est inférieur à 128, donc correspond à la première plage de caractères. Octet suivant : 195 est supérieur à 128, et 170 compris entre 128 et 128+63, donc on est dans la deuxième plage (« ê »). Ensuite 116, et 101 (« e »).
Remarque : le « masque » 10xxxxxx du dernier octet permet ainsi de savoir, à n’importe quel endroit de la suite de nombres qui définit la chaîne, si l’on est sur le début d’un caractère UTF-8 ou au milieu : une fonction qui analyse un flux de données UTF-8 saura donc toujours où elle en est, malgré la longueur variable des caractères : on dit que c’est un format de données auto-synchronisé.
Pour plus de détails sur le format, il y a la FAQ Unicode et UTF-8 pour Linux où l’on découvrira les petits frères d’UTF-8, en priant pour que les standards ne se multiplient pas, une fois de plus, à l’infini.





Vos commentaires
# Le 21 août 2002 à 04:52, par Erwan
Bonjour, français au Japon je suis bien au fait de ces problèmes...
Cela dit ça se résoud très bien sous Windows supérieur à 2000 ou sous Linux (configurer plusieurs méthodes de saisie étant un peu plus dur sur ce dernier).
En effet, il existe trois encodages pour le japonais : ISO, sjis (au depart sous Windows) et euc-jp (au depart sous Unix).
Concernant l’unicode, les japonais ne l’aiment pas. D’une part parcequ’il manque de compacité (ce qui est un peu inévitable quand on veut coder tous les langages) mais surtout parce qu’il code de la même façon le chinois et le japonais.
Les Japonais ont importé les caractères chinois il y a environ 1000 an, mais ceux-ci ont évolué dans les deux pays. Maintenant la façon de les écrire est un peu différente. Selon les auteurs d’unicode, on code les caractères mais pas les glyphes : c’est le rôle des polices de caractère.
Conclusion : si vous voulez mélanger japonais et chinois dans un texte, vous devrez choisir le "style" japonais ou le "style" chinois pour l’afficher. De plus le navigateur ne peut pas savoir s’il s’agit de chinois ou de japonais. Ca s’affiche alors a la japonaise sur les ordinateurs japonais et a la chinoise sur les ordinateurs chinois...
Pour répondre à cela un professeur de l’université de Tokyo a créé un OS (utilisé surtout dans les téléphones portable) avec son propre système d’encodage qui code absolument tous les caractères existant mais aussi ayant existé.
# Le 22 août 2002 à 10:01, par Trajan
Bonjour, connais-tu le nom du professeur en question ? L’url de sa page perso, ou une description de son encodage ?
Merci :)
# Le 23 août 2002 à 04:34, par Erwan
Voila. C’est la.
# Le 16 novembre 2006 à 02:09, par hall
# Le 24 août 2002 à 10:53, par Jefferson
Je me permet d’émettre cette petite remarque.
En HTML ou en XML, un document dans un langage donné doit porter la mention de la langue utilisée (xml:lang="EN") par exemple.
Donc, un visualiseur HTTP doit être capable de pouvoir choisir le bon jeu de caractère grâce à cette information de langue mais il est vrai que bien peu de pages se donnent la peine de fournir ce genre d’information.
Néanmoins, il reste vrai que les caractères chinois/japonais prennent bien plus de place en UTF-8. Là aussi XML fait quelque chose en acceptant la plupart des encodages standards en 8 ou 16 bits sans préférence de langue. Il ne faut donc pas désespérer.
# Le 24 août 2002 à 12:46, par jul
XML décrit des données, et les encapsule dans des méta-données. XML ne fait rien d’autre que décrire. L’internationalisation que ne résous pas le XML. Il faut un standard qui pré-existe.
Si il spécifie qu’il faut une fonte il y a intérêt à ce que la donnée soit compréhensible éxemple
livre sterling => £
Cette association pour exister nécessite que tout le monde soit d’accord sur la table d’association
symbole => glyphe (représentation graphique)
Et cela s’appelle un standard. Par exemple ISO 8859-15 décrit les fontes européennes avec le symbole euro.
Le rédacteur à raison. Il faut respecter des normes et c’est suffisant. Et même si dans le logiciel libre nous avons une image de "farfelus" nous respectons les normes les plus strictes au pied de la lettre, c’est ce qui fait que mon fureteur affiche toutes les pages webs du monde sans coup férir.
Sauf celle sous windows mal faites. En effet quand vous faites "sauver sous HTML" sous windows il ne respecte pas les standards (donc on voit des ? à la place des guillemets apostrophes ou autres). C’est très bien expliqué dans le lien.
Bref, la sérieuse société miscrosoft code l’internationalistaion de manière farfelus, les dilettantes du logiciel libre les codes de manières strictes.
# Le 31 août 2002 à 00:04, par le corbeau
"Le rédacteur à raison" ou "Le rédacteur a raison" ?
# Le 1er septembre 2002 à 21:48, par jul
L’argument n’est pas bon parce qu’il y a une faute d’ortografe ?
MS n’est pas méchant, MS n’est juste pas rigoureux, leur service qualité ne doit pas être ISO-9000.
Sinon, je suis sûr qu’ils sont de bons bougres. Je ne suis pas un anti microsoft, j’aime juste un peu plus les personnes qui font leurs oeuvres rigoureusement.
# Le 2 septembre 2002 à 09:05, par ?
Hum, je ne pense pas que ce soit un manque de rigueur de leur part. C’est juste qu’implementer les standards ca ne les arrange pas.
Ce n’est pas propre a MS mais a la grande majorite des entreprises d’informatique : la division des Unix dans les annees 70 a ete un bon exemple de non-respect (volontaire) des standards. Pas besoin de MS pour ca.
# Le 16 novembre 2006 à 07:08, par idea
# Le 18 septembre 2002 à 19:26, par Jean-Marc
Salut, Erwann
Ton message décrit bien ce que certains japonais reprochent à unicode, mais passe à coté des raisons pour lesquelles c’est injuste et délirant.
Il est vrai que unicode pose cette difficulté quand on veut mélanger japonais et chinois dans un même texte, mais comment cela se passe-t-il si on utilise un des encodages japonais ou chinois courants à la place pour ce texte ?
Eh bien, non seulement on a le même problème, mais en fait la majorité des caractères chinois ne seront tout simplement pas représentables en sjis. Avec 20 000 caractères chinois de base dans unicode, il est même beaucoup plus probable d’arriver à y représenter un caractère rare qu’en sjis ou même big-5. Et cela, c’est sans compter avec l’extension récente de 40 000 caractères suplémentaires.
Il est vrai que si l’on parle par exemple de deux sites web différents l’un en chinois et l’autre en japonais le problème est d’actulité en théorie.
Mais que constate-t-on en pratique ? Les auteurs de pages web ne se donnent même pas la peine d’indiquer l’encodage de leurs pages, et un navigateur configuré pour le japonais n’affichera pas un site chinois sans intervention manuelle.
L’utilisateur lambda sera bien en peine de deviner quel encodage il faut choisir pour corriger cela, alors que si tous utilisait unicode, il aurait au moins vu le texte.
Il reste qu’unicode se concentre sur l’aspect sémantique d’un caractère, et pas sur le fait de coder chaque différence d’aspect par un caractère différent, ce qui est délibérément et définitivement délégué au niveau du choix de la police utilisée pour l’affichage.
Pour représenter l’infinie variété des variantes possible et les innombrables caractères qui peuvent être inventés à tout moment un ressource spécialisée est nécessaire comme celle de mojikyo :
http://www.mojikyo.org/html/abroad/...
Mais ce type de site répond à un besoin de spécialistes et pas à celui d’échanger des données sous une forme correctement standardisée et sera disponibles par avance sur l’ordinateur du destinataire.
Quand a l’inconvénient de compacité, elle oublie un peu vite que c’est surtout dû à des choix par lesquels unicode simplifie énormément la manipulation des chaînes par rapport aux autres encodages.
La forme sur deux octets compense l’inconvenient de représenter l’ASCII sur deux octets par la simplicité d’une longueur fixe, et la forme a longueur variable doit le fait qu’elle représente les caractères chinois sur trois octet au lieu de deux, a des propriété de synchronisation garantie extrêmement utiles dans les déplacement et les recherches de texte.
Je peux rechercher une chaîne dans un texte UTF-8 par comparaison binaire sans connnaître rien aux propriétés d’UTF-8. En EUC-JP, pour faire la même chose, il faut un utilitaire qui sait se synchroniser sur tout le texte.
# Le 19 juillet 2005 à 22:39, par dYnkYn
Je n’ai rien compris au msg au-dessus de moi lol
# Le 23 août 2002 à 19:04, par Sam
> [...] comme tout était codé sur 8 bits, cela faisait 255 codes à remplir (255 = 28 - 1, tu vois)
Pardonnez mon ignorance, mais pourquoi pas 256 (de même qu’il y a dix chiffres et non neuf de 0 à 9, tu vois ) ?
# Le 24 août 2002 à 10:47, par Cassé Hugues
Comme la plupart des logiciels (système ou non) sont codés en C, il est plus facile que les jeux de caractère se conforment à la représentation des chaînes en C qui a le caractère 0 ou ’\0’ comme terminateur, ce qui nous laisse 256 - 1 = 255 caractère pour coder des choses intéressantes.
# Le 24 août 2002 à 12:32, par jul
Il ya aussi un certain nombre de caratcère "non imprimable" dans les tables ascii. L’ascii était pour les télétypes (espèces de machines à écrire reliées par des lignes spécialisée au départ) des commandes spécifiques à faire. Par exemple il y a dans la table ascii :
CR (Carriage Return) (0xD) retour du chariot en début de ligne (dégagement du ressort tenant le chariot)
LF (Line Feed) (0xA) faire tourner le tambour de une ligne.
Sous windows si vous regarder un fichier texte en héxadécimal, vous verrez en "fin de ligne" 0D0A.
Et oui à l’heure de la haute technologie, nos fichiers textes sont fait pour être imprimer directement sur des imprimantes "texte" (comme les imprimantes à margueritte).
Sous unix seul LF est spécifié.
J’aime l’archéologie informatique. On y voit souvent les travers de la croyance : on imprimera toujours sur des imprimantes texte, tout programme suffisamment bien fait tiendra dans 640Ko.
Le standard se suffit à lui même et l’utilisateur n’a que peu son mot à dire.
# Le 16 novembre 2006 à 15:52, par gift
# Le 9 juin 2005 à 22:12, par ?
parce que le code 0 ne peut pas être utilisé pour représenter quelque chose ; c’est le code ’nul’
# Le 17 novembre 2006 à 01:33, par personalized
# Le 15 novembre 2006 à 18:06, par gamesandcasino
# Le 27 août 2002 à 21:16, par Priareos
Pour y a t-il 5 chiffres pour le mot tête ? D’après ce que j’ai compris c’est le chiffre hexa EA qui code ê.
D’autre part si je veux écrire en cyrillique, ne serait-il pas plus économique de spécifier que le nombre hexa 400 doit être ajouté à tous les chiffres qui suivent, un peu comme une balise HTML ? Par exemple le chiffre 34 serait interprété comme étant 434 soit la 5ème lettre de l’alphabet cyrillique.
Je sais que ca ne marche pas vraiment puisqu’il manque les chiffres par exemple mais l’idée est là.
# Le 16 novembre 2006 à 23:06, par boxes
# Le 14 septembre 2002 à 11:04, par Siva
[je comptais signaler une erreur pour l’orthographe du mot « Iliade » mais mes caractères Unicode ne passant pas, je suis forcé de les transmettre en tant qu’entités HTML ; je ne sais pas si cela marchera]
Article intéressant, mais je pense que le mot « ???????? » est une erreur.
En grec ancien, le poème d’Homère se nomme « ????? », ou « ??????? » au génitif, en capitales : « ????? / ??????? », en capitales et sans diacritiques : « ????? / ??????? ».
De plus, je me permets de signaler l’existence du forum de discussion fr.comp.normes.unicode ainsi que celle de trois forums (peut-être bientôt un quatrième) qui, sur la hiérarchie francophone, acceptent des articles codés en utf-8 :
– fr.lettres.langues-anciennes.grec ;
– fr.lettres.langue.japonaise ;
– fr.lettres.langue.chinoise.
Unicode est une norme très utile tout autant pour Internet qu’Usenet.
Enfin, il est dommage que vous donniez comme exemple pour le vietnamien un texte rédigé dans une écriture qui n’a plus oficiellement cours, le « chu nom » (cf. ce document), composée de caractères d’origine chinoise. Le vietnamien s’écrit maintenant dans un alphabet latin très riche en diacritiques, dit « quoc ngu », pour lequel Unicode s’avère aussi très pratique (cf. ce document).
Siva
# Le 8 mars 2003 à 21:54, par Fil
Merci pour la précision concernant le vietnamien.
La version internationalisée de SPIP, d’ailleurs, contiendra prochainement le vietnamien, et les diacritiques signalés sont en effet assez nombreux (et très jolis !).
# Le 5 avril 2005 à 19:38, par Laurent
Euh... tous les mots grecs (je suppose) donnent des ???
C’est un gag, un bug de Mozilla 1.6 ou ?
# Le 16 novembre 2006 à 20:11, par bridal
# Le 30 avril 2003 à 00:25, par ?
Bonsoir !
Pour un non initié !! Je trouve que vous débrouillez fort bien ! De plus votre prose reste lisible pour les sombres crétins que nous sommes !
Allez bon courage.
POLO
# Le 9 mai 2003 à 18:33, par Banzaï
Et vous savez quoi ? Quand on laisse le champ libre aux américains, la première chose qu’ils font c’est se croire seuls sur terre (i.e. : comme ils n’ont pas d’accents - les pauvres - dans leur alphabet, forcément personne n’est censé en avoir => codage ASCII C.Q.F.D. !)
# Le 15 octobre 2006 à 05:00, par ?
Sa t’arrive de réfléchir a la base le net sa a été developper pour l’us army et en anglais pas d’accent donc la question ne saity même pas posé elle ne sait posé que quand le pc a fait sont apparition et qu’il est sortie hors des USA a grande echelle donc la ils ont essayé avec tout le monde de faire de tables mais c’est c’etait le bordel d’ou l’invention d’unicode et notamment d’utf-8 qui arrange tout sa.
# Le 7 novembre 2006 à 17:02, par ?
Sauf que l’ASCI existait bien avant le net ...