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 :

et le caractère 0x2260 = 0010 0010 0110 0000 (le symbole « différent de ») est encodé ainsi :

Notes applicatives¶

Les utilisateurs doivent sélectionner des paramètres régionaux UTF-8, par exemple en faisant

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

et les programmeurs peuvent tester l'expression

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.

Programmers accustomed to single-byte encodings such as US-ASCII or ISO/IEC 8859 have to be aware that two assumptions made so far are no longer valid in UTF-8 locales. Firstly, a single byte does not necessarily correspond any more to a single character. Secondly, since modern terminal emulators in UTF-8 mode also support Chinese, Japanese, and Korean double-width characters as well as nonspacing combining characters, outputting a single character does not necessarily advance the cursor by one position as it did in ASCII. Library functions such as mbsrtowcs(3) and wcswidth(3) should be used today to count characters and cursor positions.

The official ESC sequence to switch from an ISO/IEC 2022 encoding scheme (as used for instance by VT100 terminals) to UTF-8 is ESC % G ("\x1b%G"). The corresponding return sequence from UTF-8 to ISO/IEC 2022 is ESC % @ ("\x1b%@"). Other ISO/IEC 2022 sequences (such as for switching the G0 and G1 sets) are not applicable in UTF-8 mode.

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.