utf-8

UTF-8(7)                   Manuel du programmeur Linux                  UTF-8(7)



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



GNU                                6 mars 2019                          UTF-8(7)