NOM

       UTF-8 - Encodage Unicode multioctet compatible ASCII

DESCRIPTION

       The  Unicode  3.0  character  set  occupies  a 16-bit code space. The most obvious Unicode
       encoding (known as UCS-2)  consists of a  sequence  of  16-bit  words.  Such  strings  can
       contain—as  part of many 16-bit characters—bytes such as '\0' or '/', which have a special
       meaning in filenames and other C library function arguments. In addition, the majority  of
       UNIX  tools  expect  ASCII  files  and can't read 16-bit words as characters without major
       modifications. For these reasons, UCS-2 is not a suitable external encoding of Unicode  in
       filenames, text files, environment variables, and so on. The ISO 10646 Universal Character
       Set (UCS), a superset of Unicode, occupies  an  even  larger  code  space—31 bits—and  the
       obvious UCS-4 encoding for it (a sequence of 32-bit words) has the same problems.

       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). 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 encodage en ASCII et en UTF-8.

       * All UCS characters greater than 0x7f are encoded as a multibyte sequence consisting only
         of bytes in the range 0x80 to 0xfd, so no ASCII byte  can  appear  as  part  of  another
         character and there are no problems with, for example, '\0' or '/'.

       * L'ordre de tri lexicographique des chaînes UCS-4 est préservé.

       * All possible 2^31 UCS codes can be encoded using UTF-8.

       * Les octets 0xc0, 0xc1, 0xfe et 0xff ne sont jamais utilisés dans l’encodage UTF-8.

       * Le  premier  octet  d'une  suite  multioctet représentant un caractère UCS non ASCII est
         toujours dans l'intervalle 0xc2 à 0xfd et indique la longueur de  la  suite  multioctet.
         Tous  les octets suivants de cette suite sont dans l'intervalle 0x80 à 0xbf. Cela permet
         une resynchronisation aisée et rend l’encodage robuste face aux octets manquants.

       * Les caractères UCS encodé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 jusque 4 octets en UTF-8.

   Encodage
       Les suites d'octets suivantes sont utilisées pour représenter  un  caractère.  Les  suites
       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  des bits xxx sont remplies avec les bits du numéro de code du caractère en
       représentation binaire, bit de poids fort en premier (gros-boutiste). Seule la plus petite
       suite multioctet permettant de représenter un numéro de code doit être utilisée.

       The  UCS  code  values 0xd800–0xdfff (UTF-16 surrogates) as well as 0xfffe and 0xffff (UCS
       noncharacters) should not appear in conforming UTF-8 streams. According  to  RFC  3629  no
       point above U+10FFFF should be used, which limits characters to four bytes.

   Exemple
       Le  caractère  Unicode  0xA9  = 1010 1001 (le symbole copyright) est encodé 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  encodé
       ainsi :

              11100010 10001001 10100000 = 0xe2 0x89 0xa0

   Notes applicatives
       Les  utilisateurs  doivent  sélectionner  des  paramètres  régionaux 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 l’encodage 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 des paramètres régionaux UTF-8 ont été sélectionnés, et si les entrées et
       sorties texte, les communications avec les terminaux, le contenu des fichiers textes,  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 hypothèses valables jusque là ne le sont plus dans les  paramètres
       régionaux  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, l’affichage 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èques comme mbsrtowcs(3) et wcswidth(3)  doivent  être  désormais  utilisées  pour
       compter les caractères et les positions de curseur.

       La  suite  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  suite  de  retour  depuis
       UTF-8  est  ISO 2022  est ESC % @ (« \x1b%@ »). D'autres suites ISO 2022 (comme celle pour
       basculer entre les jeux G0 et G1) ne sont pas applicables en mode UTF-8.

   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 suite 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. De nombreuses manières non ASCII
       existent pour représenter ces choses dans un encodage UTF-8 non minimal.

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

VOIR AUSSI

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

TRADUCTION

       La traduction française de cette  page  de  manuel  a  été  créée  par  Christophe  Blaess
       <https://www.blaess.fr/christophe/>,  Stéphan  Rafin  <stephan.rafin@laposte.net>, Thierry
       Vignaud <tvignaud@mandriva.com>, François Micaux, Alain  Portal  <aportal@univ-montp2.fr>,
       Jean-Philippe    Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)   <jean-
       luc.coulon@wanadoo.fr>,   Julien    Cristau    <jcristau@debian.org>,    Thomas    Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>,  Denis
       Barbier   <barbier@debian.org>,   David   Prévot  <david@tilapin.org>  et  Grégoire  Scano
       <gregoire.scano@malloc.fr>

       Cette traduction est une documentation libre ; veuillez vous reporter  à  la  GNU  General
       Public   License   version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  concernant  les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à ⟨debian-l10n-french@lists.debian.org⟩.