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 :
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).
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 :
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).
Chaque caractère est représenté par deux octets. Cet encodage peut représenter seulement les 65536 premiers caractères d'Unicode.
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.
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.
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.
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.
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.
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.
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 :
quickbrown.txt, utf-8-test.txt,
utf-8-demo.txt dans le répertoire examples dans le
package ucs-fonts de Markus Kuhniso10646 dans le package trans-1.1.1 de Kosta Kosti