Thierry Bézecourt, 19 août 2001. Mis à jour en septembre 2001.
Cette page décrit sommairement les principaux encodages couramment utilisés pour les textes japonais. L'approche est strictement technique, et n'indique pas comment afficher les caractères sur votre écran (indice : il vous faut des polices japonaises). Une section indique comment préciser dans un fichier HTML l'encodage qu'il contient. Je l'ai écrite surtout pour mon usage personnel. Vous pouvez sauter le premier paragraphe si la notion d'encodage vous est familière.
Tout document est stocké sur un ordinateur comme une suite d'octets. Un octet peut prendre 256 valeurs différentes. Lorsqu'on veut stocker un texte occidental, on stockera typiquement une lettre dans chaque octet. L'encodage le plus célèbre, ASCII, définit que, pour stocker la lettre A, on doit donner à un octet la valeur 65 ; pour la lettre B, la valeur est 66, et ainsi de suite. Les signes de ponctuations ont eux aussi une valeur associée (44 pour la virgule, par exemple). Ce système permet à un logiciel de stocker un texte sur le disque dur, et à un autre de le lire.
Il existe d'autres systèmes qu'ASCII. Comme le système ASCII ne contient aucune règle pour les caractères accentués que nous utilisons en français et dans d'autres langues européennes, un autre encodage a été défini ISO-8859-1 (aussi appelé Latin-1), qui inclut toutes les règles d'ASCII plus d'autres pour les caractères accentués. La page que vous lisez utilise ISO-8859-1.
Les textes japonais posent un problème inconnu avec les systèmes alphabétiques occidentaux. En effet, on ne peut donner que 256 valeurs différentes à un octet, donc un encodage du genre de ASCII ou ISO-2256-1 ne pourra noter que 256 caractères différents. On pourrait donc imaginer un encodage de ce genre pour les hiragana et katakana, mais pas pour les milliers de kanji qui sont couramment utilisés en japonais. Il faut donc imaginer autre chose.
Les encodages japonais utilisent donc plusieurs octets. Des règles plus ou moins complexes diront que tel caractère est stocké non pas avec 1, mais avec plusieurs octets successifs prenant telle ou telle valeur. Avec deux octets, on peut coder 256 x 256 = 65536 caractères différents.
Si votre navigateur est capable d'afficher des caractères japonais, vous pouvez tenter une petite expérience : lisez cette page en choisissant l'encodage EUC-JP. Sous Netscape, par exemple, il faut choisir View->Character Set->Japanese (EUC-JP). Certains caractères japonais devraient apparaître dans le texte. En y regardant de près, vous constaterez que chaque kanji occupe la place de deux caractères européens. En effet, lorsque le navigateur rencontre un caractère accentué, donc non ASCII, il croit qu'il s'agit d'un caractère japonais sur deux octets, et il remplace ce caractère et celui qui suit par un seul kanji.
Les sections suivantes décrivent les divers systèmes qui ont été inventés pour stocker des textes japonais et qui sont encore plus ou moins utilisés. Chaque caractère est souvent stocké sous deux formes : en pleine largeur et en demi-largeur, selon la largeur à utiliser pour afficher le caractère. Tous les encodages japonais sont aussi capables de stocker des caractères européens non accentués (ceux qui sont utilisés en anglais).
Chacun des encodages ci-dessous couvre les trois jeux de caractères suivants :
EUC-JP couvre en plus le jeu de caractères supplémentaire de JIS-0212.
Noms équivalents: shift_jis, x-sjis (plus ancien).
Développé pour Windows, il est aussi supporté par Unix et d'autres systèmes d'exploitation de nos jours. Il utilise 8 bits par octet, et de 1 à 2 octets par caractère. La valeur du premier octet détermine s'il s'agit d'un caractère de un ou de deux octets.
Demi-largeur : kana et ASCII sont codés avec un seul octet, les autres sur deux octets. Pleine largeur : tous les caractères sont codés sur deux octets.
Convient pour du japonais ou de l'anglais.
Nom équivalent : x-euc-jp.
EUC-JP utilise 8 bits par octet, et de 1 à 4 octets par caractère. La valeur du premier octet détermine s'il s'agit d'un caractère mono-octet ou d'un caractère multi-octet.
Demi-largeur : les caractères ASCII sont codés sur un seul octet, les kana sur deux octets. Pleine largeur : caractères ASCII et kana sont codés sur deux octets.
Convient pour du japonais ou de l'anglais.
Utilise 7 bits par octet, et de 1 à 2 octet par caractère. Un caractère d'échappement est inséré dans le texte pour indiquer qu'on passe à 2 octets ou qu'on revient à 1 octet.
Demi-largeur : kana et ASCII sur un seul octet, autres sur deux octets. Pleine largeur : tous caractères sur deux octets.
Convient pour du japonais ou de l'anglais.
ISO-2022-JP est défini dans la RFC 1468 : Japanese Character Encoding for Internet Messages.
Utilise 8 bits par octet, et de 1 à 6 octets par caractères.
Convient pour presque tous les systèmes d'écriture, donc entre autres pour le japonais, l'anglais et les langues européennes.
Pour afficher un fichier sur un écran, c'est à dire convertir les octets qu'il contient en caractères lisibles, il faut savoir dans quel encodage il a été enregistré. Or, lorsqu'un internaute (ou son navigateur) récupère un fichier sur Internet, comme peut-il savoir quel encodage a été utilisé ? C'est important si vous mettez un fichier HTML sur un serveur Web : comment indiquer à vos visiteurs que vous avez utilisé EUC-JP ou UTF-8 ?
Première solution : l'en-tête HTTP
L'en-tête HTTP est un court message que le serveur Web envoie au navigateur juste avant de lui transmettre le document lui-même. Ce message sert par exemple à donner la taille du document ou à indiquer qu'il a disparu (code 404). Il peut aussi servir à préciser l'encodage grâce à la ligne Content-Type. Par exemple :
Content-Type: text/html; charset=shift_jis
Cette solution ne vous convient probablement pas. Si vous faites un site Web personnel hébergé par votre fournisseur d'accès à Internet, vous n'avez sans doute pas la possibilité de modifier cet en-tête, car il faudrait avoir accès à la configuration du serveur Web. Dans ce cas, passez à la deuxième solution.
Deuxième solution : l'en-tête HTML
L'en-tête HTML, ce sont les premières lignes du fichier HTML. Il s'agit de mettre l'information relative à l'encodage dans une balise META. Pour un exemple, affichez le code source de la page courante (cliquez sur le bouton droit de la souris puis sur "View Source", ou quelque chose dans ce genre) ; vous constaterez que cette page est encodée en ISO-8859-1, parce qu'elle ne contient que du texte français. Voici un autre exemple :
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <titre>Le dit du Genji</titre> <head> <body> Ici le document... <body> <html>
Cette méthode fonctionne. Pourtant elle présente un grave défaut sur le plan philosophique. En effet, l'en-tête HTML fait partie du même fichier que le corps du document. Il est donc enregistré avec le même encodage. Donc le navigateur, pour connaître l'encodage, est obligé d'ouvrir le document ; or il ne peut pas l'ouvrir, puisqu'il ne connaît pas l'encodage. Heureusement, les informaticiens sont des gens pratiques, qui pensent comme Alexandre que la meilleure manière de défaire un noeud est de le trancher. L'en-tête Content-Type décrit ci-dessus ne contient que des caractères ASCII, lesquels sont enregistrés de la même manière dans presque tous les encodages, donc le navigateur va lire le début de l'en-tête en supposant que c'est de l'ASCII. Si le Content-Type lui dit que l'encodage est en fait UTF-8 ou EUC-JP, le navigateur en tiendra compte pour la suite du document. Il y a bien des encodages exotiques comme UTF-16, dans lesquels les caractères ASCII ne sont pas si faciles à lire, mais on oubliera ces cas-là parce qu'ils sont rares ; et puis ces encodages eux-mêmes ont des caractéristiques qui les rend reconnaissables assez facilement par les navigateurs.
Conclusion : la balise META, ça ne peut pas marcher, mais ça marche quand même.
Troisième solution : les entités HTML.
Il peut arriver que vous ne puissiez pas modifier l'en-tête du document HTML. Par exemple, vous avez un site Web dont toutes les pages utilisent un en-tête généré par un programme auquel vous ne pouvez pas toucher. C'est sûrement le cas sur l'Intranet de votre entreprise ou sur votre site Web de discussion en ligne préféré.
Dans ce cas, quel que soit l'encodage du document, vous pouvez y insérer quelques caractères japonais en utilisant des codes HTML spéciaux :
&#nnn;
nnn est le code décimal (ou hexadécimal si on le précède de x) du caractère Unicode. Par exemple, bien que la page que vous lisez en ce moment soit encodée en ISO-8859-1, vous devriez pouvoir lire ci-dessous un mot japonais bien connu sans avoir à faire de manipulation dans votre navigateur :
日本語
Pour chaque caractère japonais, il faut donc connaître le code Unicode correspondant. Vous pouvez le trouver sur le serveur WWWJDIC de Jim Breen ou sur le site officiel d'Unicode. Plus simplement, un éditeur de japonais comme JFC vous donnera aussi cette information. Il va de soi que cette méthode n'est pas très pratique, mais c'est parfois la seule solution disponible.
Remarque : Yahoo! Japan contient une balise Content-Type dans l'en-tête HTTP (les plus curieux iront le vérifier sur le Web-sniffer de Mozilla) mais pas d'en-tête HTML, peut-être à cause d'un vieux bug de Netscape lié à cet en-tête. Une conséquence est que, si vous sauvegardez une page de Yahoo! Japan sur votre ordinateur et que vous ouvrez votre copie dans votre navigateur, les caractères japonais risquent de ne pas apparaître correctement. En effet, l'en-tête HTTP est transmis lorsqu'on ouvre une adresse Web, pas lorsqu'on lit un fichier local. Ce site prévoit un mécanisme particulier pour résoudre ce problème. Chaque page contient, dans un commentaire HTML qui ne s'affiche pas à l'écran, un code spécifique à EUC : \xFD\xFE. Ce code correspond à des octets qui ne peuvent apparaître que dans un document encodé avec EUC-JP. Ainsi, si l'en-tête HTTP n'est pas reconnu et que le navigateur est configuré sur "Auto-Detect Japanese", il doit tout de même être capable de déterminer l'encodage par un simple examen des caractères contenus dans le document.
Thierry Bézecourt, 19 août
2001.
Emplacement de cette page : http://www.thbz.org/japonais/encodages.html.