Provided by: manpages-fr_3.65d1p1-1_all bug

NOM

       UTF-8 - Codage Unicode multioctet compatible ASCII

DESCRIPTION

       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 » 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
       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  plus  important  — 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). 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 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 0xc0, 0xc1, 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 0xc2 à 0xfd et indique la longueur de la séquence multioctet.
         Tous  les  octets  suivants  de  cette séquence sont dans l'intervalle 0x80 à 0xbf. Cela
         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  la  norme
         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 textes, 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 normes 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 3629, Plan 9.

VOIR AUSSI

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

COLOPHON

       Cette page fait partie de la publication 3.65 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

       Depuis   2010,   cette   traduction   est   maintenue   à   l'aide   de    l'outil    po4a
       <http://po4a.alioth.debian.org/>  par l'équipe de traduction francophone au sein du projet
       perkamon <http://perkamon.alioth.debian.org/>.

       Christophe   Blaess   <http://www.blaess.fr/christophe/>   (1996-2003),    Alain    Portal
       <http://manpagesfr.free.fr/>  (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de
       traduction de Debian (2006-2009).

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