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 KostiHosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:25