noble (7) utf-8.7.gz

Provided by: manpages-fr_4.21.0-2_all bug

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