Provided by: manpages-fr_4.23.1-1_all 
NOM
UTF-8 - Encodage Unicode multioctet compatible ASCII
DESCRIPTION
Le jeu de caractères Unicode 3.0 est constitué d'un encodage sur 16 bits. L’encodage
Unicode le plus évident (connu sous le nom de UCS-2) consiste en une suite 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 encodage externe de l'Unicode utilisable dans les noms de fichiers, les variables
d'environnement, les fichiers textes, etc. Le jeu universel de caractères (UCS — Universal
Character Set) de la norme ISO/IEC 10646, un sur-ensemble d'Unicode, occupe même un espace
d’encodage plus important (31 bits) et l'encodage évident UCS-4 (une suite 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.
Proprié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). 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 encodage en ASCII et en UTF-8.
- Tous les caractères UCS supérieurs à 0x7F sont encodés en une suite de multioctets
constituée uniquement d’octets dans l'intervalle 0x80 à 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 l’encodage UTF-8.
- Le premier octet d'une suite multioctet représentant un caractère UCS non ASCII est
toujours dans l'intervalle 0xc2 à 0xfd et indique la longueur de la suite multioctet.
Tous les octets suivants de cette suite sont dans l'intervalle 0x80 à 0xbf. Cela permet
une resynchronisation aisée et rend l’encodage robuste face aux octets manquants.
- Les caractères UCS encodé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 jusque 4 octets en UTF-8.
Encodage
Les suites d'octets suivantes sont utilisées pour représenter un caractère. Les suites
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 des bits xxx sont remplies avec les bits du numéro de code du caractère en
représentation binaire, bit de poids fort en premier (gros-boutiste). Seule la plus petite
suite 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. Aucun point
au delà de U+10FFFF ne doit être utilisé selon la norme RFC 3629, ce qui limite les
caractères à 4 octets.
Exemple
Le caractère Unicode 0xA9 = 1010 1001 (le symbole copyright) est encodé 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 encodé
ainsi :
11100010 10001001 10100000 = 0xe2 0x89 0xa0
Notes applicatives
Les utilisateurs doivent sélectionner des paramètres régionaux 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 l’encodage 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 des paramètres régionaux UTF-8 ont été sélectionnés, et si les entrées et
sorties texte, les communications avec les terminaux, le contenu des fichiers textes, 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/IEC 8859
doivent savoir que deux hypothèses valables jusque là ne le sont plus dans les paramètres
régionaux 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, l’affichage 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èques comme mbsrtowcs(3) et wcswidth(3) doivent être désormais utilisées pour
compter les caractères et les positions de curseur.
La suite ESC officielle pour basculer d'un encodage ISO/IEC 2022 (comme utilisé par
exemple par les terminaux VT100) en UTF-8 est ESC % G (« \x1b%G »). La suite de retour
depuis UTF-8 est ISO/IEC 2022 est ESC % @ (« \x1b%@ »). D'autres suites ISO/IEC 2022
(comme celle pour basculer entre les jeux G0 et G1) ne sont pas applicables en mode UTF-8.
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 suite 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. De nombreuses manières non ASCII
existent pour représenter ces choses dans un encodage UTF-8 non minimal.
Normes
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.
VOIR AUSSI
locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry
Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>,
Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-
luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
Barbier <barbier@debian.org>, David Prévot <david@tilapin.org> et Grégoire Scano
<gregoire.scano@malloc.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General
Public License version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les
conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
message à ⟨debian-l10n-french@lists.debian.org⟩.