Ubuntu Manpage: UTF-8 - Codage Unicode multioctet compatible ASCII

NOM

       UTF-8 - Codage Unicode multioctet compatible ASCII

DESCRIPTION

Le jeu de caractères Unicode 3.0 est constitué d'un codage sur 16 bits. Le codage Unicode le plus évident
(connu sous le nom de UCS-2) consiste en une séquence de mots de 16 bits. De telles chaînes peuvent
contenir, comme fragments de caractère 16 bits, des octets comme « \0 » ou « / » qui ont une
signification particulière dans les noms de fichiers, et les paramètres de fonctions de bibliothèque C.
De plus la majorité des outils UNIX attendent des fichiers ASCII et ne peuvent pas lire des caractères
représentés par des mots de 16 bits sans subir de modifications majeures. Pour ces raisons, l'UCS-2 n'est
pas un codage externe de l'Unicode utilisable dans les noms de fichiers, les variables d'environnement,
les fichiers textes, etc. Le surensemble d'Unicode ISO 10646 Universal Character Set (UCS) occupe même un
espace de codage plus important — 31 bits — et l'encodage évident UCS-4 (une séquence de mots sur
32 bits) a les mêmes inconvénients.

Le codage 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.

Propriétés
Le codage UTF-8 a les propriétés suivantes :

* Les caractères UCS 0x00000000 à 0x0000007f (le jeu US-ASCII classique) sont codés simplement par les
octets 0x00 à 0x7f (compatibilité ASCII). Cela 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 codé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,
et il n'y a donc pas de problème 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 0xc0, 0xc1, 0xfe et 0xff ne sont jamais utilisés dans le codage UTF-8.

* Le premier octet d'une séquence multioctet représentant un caractère UCS non ASCII est toujours dans
l'intervalle 0xc2 à 0xfd et indique la longueur de la séquence multioctet. Tous les octets suivants de
cette séquence sont dans l'intervalle 0x80 à 0xbf. Cela permet une resynchronisation aisée et rend le
codage robuste face aux octets manquants.

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

Codage
Les séquences d'octets suivantes sont utilisées pour représenter un caractère. Les séquences utilisées
dépendent du numéro de code UCS du caractère :

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 multioctet permettant de représenter un numéro de code doit être
utilisée.

Les codes UCS de valeur 0xd800–0xdfff (remplacements en UTF-16) ainsi que 0xfffe et 0xffff (non
caractères UCS) ne doivent pas apparaître dans un flux de données UTF-8.

Exemple
Le caractère Unicode 0xA9 = 1010 1001 (le symbole copyright) est codé en UTF-8 de la manière suivante :

11000010 10101001 = 0xc2 0xa9

et le caractère 0x2260 = 0010 0010 0110 0000 (le symbole « différent de ») est codé ainsi :

11100010 10001001 10100000 = 0xe2 0x89 0xa0

Notes applicatives
Les utilisateurs doivent sélectionner une locale UTF-8, par exemple en faisant

export LANG=fr_FR.UTF-8

afin d'activer la gestion de l'UTF-8 dans les applications.

Les applications qui doivent connaître le codage de caractères utilisé doivent toujours définir la
locale, en faisant par exemple

setlocale(LC_CTYPE, "")

et les programmeurs peuvent tester l'expression

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

pour savoir si une locale UTF-8 a été sélectionnée, et si les entrée-sortie texte, les communications
avec les terminaux, le contenu des fichiers textes, les noms de fichiers et les variables d'environnement
sont codé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 hypothèses valables jusque là ne le sont plus dans les locales UTF-8. D'abord, un octet seul ne
correspond pas nécessairement à un unique caractère. Ensuite, comme les émulateurs de terminaux modernes
en mode UTF-8 gèrent également les caractères double largeur du chinois, du japonais ou du coréen et les
caractères combinés sans espacement, 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 être désormais utilisées pour compter les caractères et les positions de curseur.

La séquence ESC officielle pour basculer d'un codage 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
codage des caractères sur les systèmes POSIX, ce qui conduira à un environnement sensiblement plus riche
pour traiter des textes.

Sécurité
Les normes Unicode et UCS demandent que le fabricant utilisant UTF-8 utilise la forme la plus courte
possible, par exemple, produire une séquence de deux octets avec un premier octet 0xc0 n'est pas
conforme. Unicode 3.1 a ajouté la nécessité pour les programmes conformes de ne pas accepter les formes
non minimales en entrée. Il s'agit de raisons de sécurité : si une saisie est examinée pour des problèmes
de sécurité, un programme doit rechercher seulement la version ASCII de « /../ » ou « ; » ou NUL. Il y a
de nombreuses manières non ASCII de représenter ces choses dans un codage UTF-8 non minimal.

Normes
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.

VOIR AUSSI

       nl_langinfo(3), setlocale(3), charsets(7), unicode(7)

COLOPHON

       Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description du projet et des
       instructions    pour    signaler    des    anomalies    peuvent     être     trouvées     à     l'adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par
       l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>.

       Christophe       Blaess       <http://www.blaess.fr/christophe/>      (1996-2003),      Alain      Portal
       <http://manpagesfr.free.fr/> (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de  traduction  de
       Debian (2006-2009).

       Veuillez  signaler  toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par
       un rapport de bogue sur le paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C
       <section> <page_de_man> ».

GNU                                              26 février 2014                                        UTF-8(7)