UTF-8
Section : Manuel de l'administrateur Linux (
7)
Mise à jour de la version anglaise : 11 mai 2001
Index
Menu principal
NOM
utf-8 - Un encodage Unicode multi-octets compatible ASCII
DESCRIPTION
Le jeu de caractères
Unicode 3.0
(voir
unicode(7))
est constitué d'un codage sur 16 bits.
L'encodage 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 des modifications majeures.
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.
Proriétés
L'encodage
UTF-8
a les propriétés suivantes :
- *
-
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.
Encodage
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 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.
Exemple
Le caractère
Unicode
0xA9 = 1010 1001 (le symbole copyright) est encodé
en UTF-8 comme :
-
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
Notes applicatives
Les utilisateurs doivent sélectionner une localisation
UTF-8,
par exemple
-
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.
Sécurité
Les standards
Unicode et
UCS
demandent que le producteur
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 encodage
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)
TRADUCTION
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 17 juillet 2008.
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.
Index
- NOM
-
- DESCRIPTION
-
- Proriétés
-
- Encodage
-
- Exemple
-
- Notes applicatives
-
- Sécurité
-
- Normes
-
- VOIR AUSSI
-
- TRADUCTION
-
Dernière mise à jour : 17 juillet 2008