Provided by: manpages-fr_3.32d0.2p4-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  sur  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). 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  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 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 0xc0 à 0xfd et indique
         la longueur de la séquence multioctet. Tous les  octets  suivants  de
         cette  séquence  sont  dans l'intervalle 0x80 à 0xbf. Ceci 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 le standard 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 standards 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 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       être       trouvées      à      l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis 2010, cette traduction est maintenue à l'aide  de  l'outil  po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'équipe   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'é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> ».