Pour ces raisons, l'UCS-2 n'est pas un encodage externe de l'Unicode utilisable dans les noms de fichiers, les variables d'environnement, les fichiers textes, etc... Le sur-ensemble d'Unicode ISO 10646 Universal Character Set (UCS), occupe même un espace de codage sur 31 bits, et l'encodage évident UCS-4 (une séquence de mots sur 32 bits) a les mêmes inconvénients.

L'encodage UTF-8 de l'Unicode et de l'UCS n'a pas ces inconvénients et est un moyen d'utiliser le jeu de caractères Unicode sous les systèmes d'exploitation compatibles UNIX.  

*

Les caractères UCS 0x00000000 à 0x0000007f (le jeu US-ASCII classique) sont encodés simplement par les octets 0x00 à 0x7f (compatibilité ASCII). Ceci signifie que les fichiers et les chaînes qui contiennent uniquement des caractères du jeu ASCII 7 bits ont exactement le même codage en ASCII et en UTF-8.

*

Tous les caractères UCS supérieurs à 0x7F sont encodés en séquences consistant uniquement en octets dans l'intervalle 0x80 a 0xFD, ainsi aucun octet ASCII n'apparaît en tant que partie d'un autre caractère (plus de problèmes avec « \0 » ou « / »).

*

L'ordre de tri lexicographique des chaînes UCS-4 est préservé.

*

Tous les 2^31 caractères de l'UCS peuvent être encodés en utilisant UTF-8.

*

Les octets 0xFE et 0xFF ne sont jamais utilisés dans le codage UTF-8.

*

Le premier octet d'une séquence multi-octets représentant un caractère UCS non-ASCII est toujours dans l'intervalle 0xC0 à 0xFD et indique la longueur de la séquence multi-octets. Tous les octets suivants de cette séquence sont dans l'intervalle 0x80 à 0xBF. Ceci permet une re-synchronisation aisée et rend l'encodage robuste face aux octets manquants.

*

Les caractères UTF-8 codés en UCS peuvent avoir jusqu'à 6 octets de long, néanmoins le standard Unicode ne précise aucun caractère au-delà de 0x10ffff, ainsi les caractères Unicode ne peuvent avoir que 4 octets de long avec UTF-8.

0x00000000 - 0x0000007F:

0xxxxxxx

0x00000080 - 0x000007FF:

110xxxxx 10xxxxxx

0x00000800 - 0x0000FFFF:

1110xxxx 10xxxxxx 10xxxxxx

0x00010000 - 0x001FFFFF:

11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0x00200000 - 0x03FFFFFF:

111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0x04000000 - 0x7FFFFFFF:

1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Les positions de bits xxx sont remplies avec les bits du numéro de code du caractère en représentation binaire. Seule la plus petite séquence multi-octets permettant de représenter un numéro de code doit être utilisée.

Les codes UCS de valeur 0xd800-0xdfff (UTF-16) comme 0xfffe et 0xffff ne doivent pas apparaître dans un flux de données UTF-8.  

11000010 10101001 = 0xC2 0xA9

et le caractère 0x2260 = 0010 0010 0110 0000 (Le symbole « non égal ») est encodé ainsi :

11100010 10001001 10100000 = 0xE2 0x89 0xA0

export LANG=fr_FR.UTF-8

afin d'active le support UTF-8 dans les applications.

Les logiciels applicatifs qui doivent connaître l'encodage utilisé devrait toujours fixer la localisation, par exemple

setlocale(LC_CTYPE, "")

et les programmeurs peuvent tester l'expression

strcmp(nl_langinfo(CODESET), "UTF-8") == 0

pour savoir si une localisation UTF-8 a été sélectionnée, et si les entrées-sorties de texte, les communications avec les terminaux, le contenu des fichiers de texte, les noms de fichiers et les variables d'environnement sont encodés en UTF-8.

Les programmeurs habitués aux jeux de caractères mono-octet comme US-ASCII ou ISO 8859 doivent savoir que deux suppositions valides jusque là ne le sont plus dans les localisations UTF-8. D'abord un octet seul ne correspond par nécessairement à un unique caractère. Ensuite, comme les émulateurs de terminaux modernes, en mode UTF-8 supportent également les caractères en double-largeur du Chinois, du Japonais ou du Coréen, comme les caractères combinés sans largeur, la sortie d'un unique caractère ne fait pas avancer obligatoirement le curseur d'une position comme c'était le cas en ASCII. Les fonctions de bibliothèque comme mbsrtowcs(3) et wcswidth(3) doivent servir à présent pour compter les caractères et les positions de curseur.

La séquence ESC officielle pour basculer d'un encodage ISO 2022 (comme utilisé par exemple par les terminaux VT100) en UTF-8 est ESC % G ("\x1b%G"). La séquence de retour depuis UTF-8 est ISO 2022 est ESC % @ ("\x1b%@"). D'autres séquences ISO 2022 (comme celle pour basculer entre les jeux G0 et G1) ne sont pas applicables en mode UTF-8.

On peut espérer que dans un futur proche, UTF-8 remplacera ASCII et ISO 8859 à tous les niveaux comme encodage des caractères sur les systèmes POSIX, ce qui conduira à un environnement sensiblement plus riche pour traiter des textes.  

Ce document est une traduction réalisée par Christophe Blaess <http://www.blaess.fr/christophe/> le 20 octobre 1996 et révisée le 10 décembre 2007.

L'équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 7 utf-8 ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.

NOM

DESCRIPTION

Proriétés

Encodage

Exemple

Notes applicatives

Sécurité

Normes

VOIR AUSSI

TRADUCTION