NOM
UTF-8 - Codage Unicode multioctet compatible ASCII
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 » or « / »
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 sur 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). 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 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 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 0xc0 à 0xfd et indique
la longueur de la séquence multioctet. Tous les octets suivants de
cette séquence sont dans l’intervalle 0x80 à 0xbf. Ceci 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 le standard 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 texte, 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 standards 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 2279, Plan 9.
VOIR AUSSI
nl_langinfo(3), setlocale(3), charsets(7), unicode(7)
COLOPHON
Cette page fait partie de la publication 3.23 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
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
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> ».