Provided by: manpages-fr_1.67.0-1_all bug

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.

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) 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.

EXEMPLES

       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 localisation 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.

SECURITÉ

       Les standards Unicode et UCS demande 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.

CONFORMITÉ

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

AUTEUR

       Markus Kuhn <mgk25@cl.cam.ac.uk>

VOIR AUSSI

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

TRADUCTION

       Christophe Blaess, 1996-2003.