Page suivante Page précédente Table des matières

1. Introduction

1.1 Pourquoi Unicode ?

Les gens de différents pays utilisent différents caractères pour représenter les mots de leur langue natale. De nos jours la plupart des applications, y compris les logiciels de courrier électronique et les navigateurs, traitent correctement les caractères 8-bits. Ils peuvent donc traiter et afficher du texte correctement à condition qu'il soit représenté dans un jeu de caractères 8-bits, comme ISO-8859-1.

Il y a bien plus de 256 caractères dans le monde - pensez au cyrillique, à l'hébreu, à l'arabe, au chinois, au japonais au coréen et au thaï -, et de temps à autres, de nouveaux caractères sont inventés. Les problèmes que cela induit pour les utilisateurs sont les suivants  :

  • Il est impossible de stocker du texte avec des jeux de caractères différents dans le même document. Par exemple, je peux citer des journaux russes dans une publication allemande ou française si j'utilise TeX, xdvi et Postscript, mais je ne peux pas le faire avec du texte pur.
  • Tant que chaque document a son propre jeu de caractères, et que la reconnaissance des jeux de caractères n'est pas automatique, l'intervention manuelle de l'utilisateur est inévitable. Par exemple, pour voir la page d'accueil de la distribution Linux XTeamLinux http://www.xteamlinux.com.cn/, je dois dire à Netscape que la page web est codée en GB2312.
  • De nouveaux symboles comme l'Euro sont inventés. ISO a publié un nouveau standard ISO-8859-15 qui est en gros identique à ISO-8859-1, excepté qu'il supprime des caractères rarement utilisés, comme le vieux symbole monétaire, remplacé par le signe Euro. Si les utilisateurs acceptent ce standard, ils auront des documents dans différents jeux de caractères sur leur disque, et cela deviendra une préoccupation quotidienne. Mais les ordinateurs devraient simplifier le choses, pas les compliquer.

La solution à ce problème est l'adoption d'un jeu de caractères universel. Ce jeu de caractères est Unicode http://www.unicode.org/. Pour plus d'informations sur Unicode, faites man 7 unicode (page de man contenue dans le package lpdman-1.20).

1.2 Les encodages d'Unicode

Cela réduit le problème de l'utilisateur (devoir jongler entre différents jeux de caractères) à un problème technique : comment transporter les caractères Unicode en utilisant des octets de 8 bits ? L'unité de 8 bits est la plus petite unité adressable de la plupart des ordinateurs et c'est aussi l'unité utilisée par les connexions réseau TCP/IP. Cependant, l'utilisation d'un octet pour la représentation d'un caractère est un accident de l'histoire dû au fait que le développement de l'ordinateur commença en Europe et aux États-Unis, où l'on pensait que 96 caractères seraient suffisants pour longtemps.

Il y a fondamentalement quatre façons d'encoder des caractères Unicode dans des octets :

UTF-8

128 caractères sont encodés en utilisant 1 octet : les caractères ASCII.
1920 caractères sont encodé en utilisant deux octets : le latin, le grec, le cyrillique, le copte, l'arménien, l'hébreu, les caractères arabes.
63488 caractères sont encodés en utilisant 3 octets, le chinois et le japonais entre autres.
Les 2147418112 caractères restant (non encore assignés) peuvent être encodés en utilisant 4, 5 ou 6 caractères. Pour plus d'informations sur UTF-8, faites man 7 utf-8 (cette page est contenue dans le package ldpman-1.20).

UCS-2

Chaque caractère est représenté par deux octets. Cet encodage peut représenter seulement les 65536 premiers caractères d'Unicode.

UTF-16

C'est une extension d'UTF-2 qui peut représenter 11144112 caractères Unicode. Les 65536 premiers caractères sont représentés par deux octets, les autres par quatre.

UCS-4

Chaque caractère est représenté par 4 octets.

L'espace nécessaire pour encoder un texte, comparativement aux encodages actuellement en usage (8 bits par caractères pour les langues européennes, plus pour le chinois/japonais/coréen), est le suivant : (Cela a une influence sur l'espace disque, et la vitesse des communications réseau.

UTF-8

Pas de changement pour l'ASCII américain, juste quelques pourcents supplémentaires pour ISO-8859-1, 50 % de plus pour le chinois/japonais/coréen, 100 % de plus pour le grec et le cyrillique.

UCS-2 et UTF-16

Pas de changement pour le chinois/japonais/coréen, augmentation de 100 % pour l'US ASCII et ISO-8859-1, le grec et le cyrillique.

UCS-4

Augmentation de 100% pour le chinois/japonais/coréen. De 300% pour l'US ASCII et ISO-8859-1, le grec et le cyrillique.

Étant donné la pénalité pour les documents américains et européens, causée par UCS-2, UTF-8 et UCS-4, il semble peu probable que ces encodages aient un potentiel pour une utilisation à grande échelle. L'API Win32 Microsoft supporte l'encodage UCS-2 depuis 1995 (au moins), cependant cet encodage n'a pas été largement adopté pour les documents -SJIS demeure prédominant au Japon.

D'un autre côté UTF-8 a le potentiel pour une utilisation à large échelle, puisqu'il ne pénalise pas les utilisateurs américains et européens, et que beaucoup de logiciels de "traitement de texte" (NDT : au sens large) n'ont pas besoin d'être changés pour supporter UTF-8.
Nous allons maintenant expliquer comment configurer votre système Linux pour qu'il utilise UTF-8 comme encodage de texte.

Notes pour les développeurs C/C++

L'approche de Microsoft Win32 rend facile pour les développeurs la production de versions Unicode de leurs programmes : Vous définissez Unicode ("#define UNICODE") au début de votre programme, et changez alors un grand nombre d'occurrences de char en TCHAR jusqu'à ce que votre programme compile sans Warnings. Le problèmes est que vous avez au final deux versions de votre programme : une qui comprend le texte UCS-2 mais pas les encodages 8-bit, et une autre qui ne comprend que les vieux encodages 8-bit.

En plus, il y a une complication qui affecte UCS-2 et UCS-4 : l'ordre de la représentation interne des nombre (``the endianness''). Le registre de systèmes de codage de caractères de la IANA dit à l'égard de ISO-10646-UCS-2 : "il faut spécifier l'ordre de la représentation interne des nombres à l'intérieur du réseau, le standard ne le spécifie pas". Cette représentation est "big endian" en contexte réseau, alors que Microsoft recommande dans ses outils de développement C/C++ d'utiliser une représention dépendante de la machine (c.a.d. "little endian" sur les processeurs ix86), et d'ajouter une marque de polarité (BOM) au début du document, ou d'utiliser des heuristiques basées sur la statistique.

D'un autre côté l'approche de UTF-8 garde char* comme type standard pour le stockage des chaînes en C. Il en résulte que votre programme supportera l'US ASCII, indépendamment de toute variable d'environnement, et supportera les textes encodés en ISO-8859-1 et UTF-8 à condition que la variable d'environnement LANG soit positionnée en conséquence.

1.3 Liens

La liste de ressources de Markus Kuhn (mise à jour très régulièrement) :

Un survol d'Unicode, UTF-8 et des programmes fonctionnant avec UTF-8 de Roman Czyborra :
http://czyborra.com/utf/#UTF-8

Des exemples de fichiers UTF-8 :

Page suivante Page précédente Table des matières