Provided by:
manpages-fr_3.32d0.2p4-1_all 
NOM
UTF-8 - Codage Unicode multioctet compatible ASCII
DESCRIPTION
Le jeu de caracteres Unicode 3.0 est constitue d'un codage sur 16 bits.
Le codage Unicode le plus evident (connu sous le nom de UCS-2) consiste
en une sequence de mots de 16 bits. De telles chaines peuvent contenir,
comme fragments de caractere 16 bits, des octets comme << \0 >> ou
<< / >> qui ont une signification particuliere dans les noms de
fichiers, et les parametres de fonctions de bibliotheque C. De plus la
majorite des outils UNIX attendent des fichiers ASCII et ne peuvent pas
lire des caracteres representes 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 meme un espace
de codage sur 31 bits, et l'encodage evident UCS-4 (une sequence de
mots sur 32 bits) a les memes inconvenients.
Le codage UTF-8 de l'Unicode et de l'UCS n'a pas ces inconvenients et
est un moyen d'utiliser le jeu de caracteres Unicode sous les systemes
d'exploitation compatibles UNIX.
Propri'et'es
Le codage UTF-8 a les proprietes suivantes :
* Les caracteres UCS 0x00000000 a 0x0000007f (le jeu US-ASCII
classique) sont codes simplement par les octets 0x00 a 0x7f
(compatibilite ASCII). Ceci signifie que les fichiers et les chaines
qui contiennent uniquement des caracteres du jeu ASCII 7 bits ont
exactement le meme codage en ASCII et en UTF-8.
* Tous les caracteres UCS superieurs a 0x7F sont codes en sequences
consistant uniquement en octets dans l'intervalle 0x80 a 0xfd, ainsi
aucun octet ASCII n'apparait en tant que partie d'un autre caractere,
et il n'y a donc pas de probleme avec << \0 >> ou << / >>).
* L'ordre de tri lexicographique des chaines UCS-4 est preserve.
* Tous les 2^31 caracteres de l'UCS peuvent etre encodes en utilisant
UTF-8.
* Les octets 0xfe et 0xff ne sont jamais utilises dans le codage UTF-8.
* Le premier octet d'une sequence multioctet representant un caractere
UCS non ASCII est toujours dans l'intervalle 0xc0 a 0xfd et indique
la longueur de la sequence multioctet. Tous les octets suivants de
cette sequence sont dans l'intervalle 0x80 a 0xbf. Ceci permet une
resynchronisation aisee et rend le codage robuste face aux octets
manquants.
* Les caracteres UCS codes en UTF-8 peuvent avoir jusqu'a 6 octets.
Neanmoins le standard Unicode ne precise aucun caractere au-dela de
0x10ffff, ainsi les caracteres Unicode ne peuvent avoir que 4 octets
en UTF-8.
Codage
Les sequences d'octets suivantes sont utilisees pour representer un
caractere. Les sequences utilisees dependent du numero de code UCS du
caractere :
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 numero de code
du caractere en representation binaire. Seule la plus petite sequence
multioctet permettant de representer un numero de code doit etre
utilisee.
Les codes UCS de valeur 0xd800-0xdfff (remplacements en UTF-16) ainsi
que 0xfffe et 0xffff (non-caracteres UCS) ne doivent pas apparaitre
dans un flux de donnees UTF-8.
Exemple
Le caractere Unicode 0xA9 = 1010 1001 (le symbole copyright) est code
en UTF-8 de la maniere suivante :
11000010 10101001 = 0xc2 0xa9
et le caractere 0x2260 = 0010 0010 0110 0000 (le symbole << different
de >>) est code ainsi :
11100010 10001001 10100000 = 0xe2 0x89 0xa0
Notes applicatives
Les utilisateurs doivent selectionner 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 connaitre le codage de caracteres utilise
doivent toujours definir 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 ete selectionnee, et si les
entree-sortie texte, les communications avec les terminaux, le contenu
des fichiers textes, les noms de fichiers et les variables
d'environnement sont codes en UTF-8.
Les programmeurs habitues aux jeux de caracteres mono-octet comme
US-ASCII ou ISO 8859 doivent savoir que deux hypotheses valables jusque
la ne le sont plus dans les locales UTF-8. D'abord, un octet seul ne
correspond pas necessairement a un unique caractere. Ensuite, comme les
emulateurs de terminaux modernes en mode UTF-8 gerent egalement les
caracteres double largeur du chinois, du japonais ou du coreen et les
caract`eres combin'es sans espacement, la sortie d'un unique caractere ne
fait pas avancer obligatoirement le curseur d'une position comme
c'etait le cas en ASCII. Les fonctions de bibliotheque comme
mbsrtowcs(3) et wcswidth(3) doivent etre desormais utilisees pour
compter les caracteres et les positions de curseur.
La sequence ESC officielle pour basculer d'un codage ISO 2022 (comme
utilise par exemple par les terminaux VT100) en UTF-8 est ESC % G
(<< \x1b%G >>). La sequence de retour depuis UTF-8 est ISO 2022 est ESC
% @ (<< \x1b%@ >>). D'autres sequences ISO 2022 (comme celle pour
basculer entre les jeux G0 et G1) ne sont pas applicables en mode
UTF-8.
On peut esperer que dans un futur proche, UTF-8 remplacera ASCII et
ISO 8859 a tous les niveaux comme codage des caracteres sur les
systemes POSIX, ce qui conduira a un environnement sensiblement plus
riche pour traiter des textes.
S'ecurit'e
Les standards Unicode et UCS demandent que le fabricant utilisant UTF-8
utilise la forme la plus courte possible, par exemple, produire une
sequence de deux octets avec un premier octet 0xc0 n'est pas conforme.
Unicode 3.1 a ajoute la necessite pour les programmes conformes de ne
pas accepter les formes non minimales en entree. Il s'agit de raisons
de securite : si une saisie est examinee pour des problemes de
securite, un programme doit rechercher seulement la version ASCII de
<< /../ >> ou << ; >> ou NUL. Il y a de nombreuses manieres non-ASCII
de representer 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.32 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.