Provided by: manpages-fr_4.13-4_all bug

NOM

       UTF-8 - Encodage Unicode multioctet compatible ASCII

DESCRIPTION

       Le  jeu  de  caractères  Unicode 3.0  est  constitué d'un encodage sur 16 bits. L’encodage
       Unicode le plus évident (connu sous le nom de UCS-2) consiste en  une  suite  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 encodage externe de l'Unicode utilisable dans les noms de fichiers,  les  variables
       d'environnement, les fichiers textes, etc. Le jeu universel de caractères (UCS — Universal
       Character Set) de la norme ISO 10646, un sur-ensemble d'Unicode,  occupe  même  un  espace
       d’encodage  plus  important  (31 bits)  et l'encodage évident UCS-4 (une suite de mots sur
       32 bits) a les mêmes inconvénients.

       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.

       – Tous les caractères UCS supérieurs à 0x7F sont  encodés  en  une  suite  de  multioctets
         constituée  uniquement  d’octets  dans l'intervalle 0x80 à 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 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.

       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. Aucun  point
       au  delà  de  U+10FFFF  ne  doit  être  utilisé selon la norme RFC 3629, ce qui limite les
       caractères à 4 octets.

   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)

COLOPHON

       Cette  page  fait partie de la publication 5.10 du projet man-pages Linux. Une description
       du projet et des instructions pour signaler des anomalies et la dernière version de  cette
       page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.

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 ⟨⟩.