Provided by: manpages-fr_3.23.1-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 » 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   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  texte,  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.23  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

       Cette  page  de  manuel  a  été  traduite et mise à jour par Christophe
       Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis  par
       Alain  Portal  <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

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