Provided by: manpages-fr_3.32d0.2p4-1_all bug

NOM

       UTF-8 - Codage Unicode multioctet compatible ASCII

DESCRIPTION

       Le jeu de caracteres Unicode 3.0 est constitue d'un codage sur 16 bits.
       Le codage Unicode le plus evident (connu sous le nom de UCS-2) consiste
       en une sequence de mots de 16 bits. De telles chaines peuvent contenir,
       comme fragments de caractere 16 bits,  des  octets  comme  << \0 >>  ou
       << / >>  qui  ont  une  signification  particuliere  dans  les  noms de
       fichiers, et les parametres de fonctions de bibliotheque C. De plus  la
       majorite des outils UNIX attendent des fichiers ASCII et ne peuvent pas
       lire des caracteres representes 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 meme un espace
       de  codage  sur  31 bits,  et l'encodage evident UCS-4 (une sequence de
       mots sur 32 bits) a les memes inconvenients.

       Le codage UTF-8 de l'Unicode et de l'UCS n'a pas ces  inconvenients  et
       est  un moyen d'utiliser le jeu de caracteres Unicode sous les systemes
       d'exploitation compatibles UNIX.

   Propri'et'es
       Le codage UTF-8 a les proprietes suivantes :

       * Les  caracteres  UCS  0x00000000  a  0x0000007f  (le   jeu   US-ASCII
         classique)   sont  codes  simplement  par  les  octets  0x00  a  0x7f
         (compatibilite ASCII). Ceci signifie que les fichiers et les  chaines
         qui  contiennent  uniquement  des  caracteres du jeu ASCII 7 bits ont
         exactement le meme codage en ASCII et en UTF-8.

       * Tous les caracteres UCS superieurs a 0x7F  sont  codes  en  sequences
         consistant  uniquement en octets dans l'intervalle 0x80 a 0xfd, ainsi
         aucun octet ASCII n'apparait en tant que partie d'un autre caractere,
         et il n'y a donc pas de probleme avec << \0 >> ou << / >>).

       * L'ordre de tri lexicographique des chaines UCS-4 est preserve.

       * Tous  les  2^31 caracteres de l'UCS peuvent etre encodes en utilisant
         UTF-8.

       * Les octets 0xfe et 0xff ne sont jamais utilises dans le codage UTF-8.

       * Le premier octet d'une sequence multioctet representant un  caractere
         UCS  non  ASCII est toujours dans l'intervalle 0xc0 a 0xfd et indique
         la longueur de la sequence multioctet. Tous les  octets  suivants  de
         cette  sequence  sont  dans l'intervalle 0x80 a 0xbf. Ceci permet une
         resynchronisation aisee et rend le codage  robuste  face  aux  octets
         manquants.

       * Les  caracteres  UCS  codes  en UTF-8 peuvent avoir jusqu'a 6 octets.
         Neanmoins le standard Unicode ne precise aucun caractere  au-dela  de
         0x10ffff,  ainsi les caracteres Unicode ne peuvent avoir que 4 octets
         en UTF-8.

   Codage
       Les sequences d'octets suivantes sont  utilisees  pour  representer  un
       caractere.  Les  sequences utilisees dependent du numero de code UCS du
       caractere :

       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 numero de code
       du  caractere  en representation binaire. Seule la plus petite sequence
       multioctet permettant de  representer  un  numero  de  code  doit  etre
       utilisee.

       Les  codes  UCS de valeur 0xd800-0xdfff (remplacements en UTF-16) ainsi
       que 0xfffe et 0xffff (non-caracteres UCS)  ne  doivent  pas  apparaitre
       dans un flux de donnees UTF-8.

   Exemple
       Le  caractere  Unicode 0xA9 = 1010 1001 (le symbole copyright) est code
       en UTF-8 de la maniere suivante :

              11000010 10101001 = 0xc2 0xa9

       et le caractere 0x2260 = 0010 0010 0110 0000 (le  symbole  << different
       de >>) est code ainsi :

              11100010 10001001 10100000 = 0xe2 0x89 0xa0

   Notes applicatives
       Les  utilisateurs doivent selectionner 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 connaitre le codage de caracteres  utilise
       doivent toujours definir 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  ete  selectionnee,  et  si les
       entree-sortie texte, les communications avec les terminaux, le  contenu
       des   fichiers   textes,   les   noms  de  fichiers  et  les  variables
       d'environnement sont codes en UTF-8.

       Les programmeurs habitues  aux  jeux  de  caracteres  mono-octet  comme
       US-ASCII ou ISO 8859 doivent savoir que deux hypotheses valables jusque
       la ne le sont plus dans les locales UTF-8. D'abord, un  octet  seul  ne
       correspond pas necessairement a un unique caractere. Ensuite, comme les
       emulateurs de terminaux modernes en mode  UTF-8  gerent  egalement  les
       caracteres  double  largeur du chinois, du japonais ou du coreen et les
       caract`eres combin'es sans espacement, la sortie d'un unique caractere ne
       fait  pas  avancer  obligatoirement  le  curseur  d'une  position comme
       c'etait  le  cas  en  ASCII.  Les  fonctions  de   bibliotheque   comme
       mbsrtowcs(3)  et  wcswidth(3)  doivent  etre  desormais  utilisees pour
       compter les caracteres et les positions de curseur.

       La sequence ESC officielle pour basculer d'un  codage  ISO 2022  (comme
       utilise  par  exemple  par  les  terminaux  VT100) en UTF-8 est ESC % G
       (<< \x1b%G >>). La sequence de retour depuis UTF-8 est ISO 2022 est ESC
       %  @  (<< \x1b%@ >>).  D'autres  sequences  ISO 2022  (comme celle pour
       basculer entre les jeux G0 et G1)  ne  sont  pas  applicables  en  mode
       UTF-8.

       On  peut  esperer  que  dans un futur proche, UTF-8 remplacera ASCII et
       ISO 8859 a tous  les  niveaux  comme  codage  des  caracteres  sur  les
       systemes  POSIX,  ce  qui conduira a un environnement sensiblement plus
       riche pour traiter des textes.

   S'ecurit'e
       Les standards Unicode et UCS demandent que le fabricant utilisant UTF-8
       utilise  la  forme  la  plus courte possible, par exemple, produire une
       sequence de deux octets avec un premier octet 0xc0 n'est pas  conforme.
       Unicode 3.1  a  ajoute la necessite pour les programmes conformes de ne
       pas accepter les formes non minimales en entree. Il s'agit  de  raisons
       de  securite :  si  une  saisie  est  examinee  pour  des  problemes de
       securite, un programme doit rechercher seulement la  version  ASCII  de
       << /../ >>  ou  << ; >> ou NUL. Il y a de nombreuses manieres non-ASCII
       de representer 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      etre       trouvees       a       l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis  2010,  cette  traduction est maintenue a l'aide de l'outil po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   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'equipe francophone de traduction de Debian (2006-2009).

       Veuillez  signaler  toute  erreur   de   traduction   en   ecrivant   a
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous pouvez toujours avoir acces a la version anglaise de  ce  document
       en utilisant la commande << man -L C <section> <page_de_man> >>.