UTF-8(7) Miscellaneous Information Manual UTF-8(7) NOM UTF-8 - Encodage Unicode multioctet compatible ASCII DESCRIPTION Le jeu de caracteres Unicode 3.0 est constitue d'un encodage sur 16 bits. L'encodage Unicode le plus evident (connu sous le nom de UCS-2) consiste en une suite de mots de 16 bits. De telles chaines peuvent contenir, comme fragments de caractere 16 bits, des octets comme << \0 >> ou << / >> qui ont une signification particuliere dans les noms de fichiers et les parametres de fonctions de bibliotheque C. De plus, la majorite des outils UNIX attendent des fichiers ASCII et ne peuvent pas lire des caracteres representes 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 caracteres (UCS -- Universal Character Set) de la norme ISO/IEC 10646, un sur-ensemble d'Unicode, occupe meme un espace d'encodage plus important (31 bits) et l'encodage evident UCS-4 (une suite de mots sur 32 bits) a les memes inconvenients. L'encodage UTF-8 de l'Unicode et de l'UCS n'a pas ces inconvenients et est un moyen d'utiliser le jeu de caracteres Unicode sous les systemes d'exploitation compatibles UNIX. Proprietes L'encodage UTF-8 a les proprietes suivantes. - Les caracteres UCS 0x00000000 a 0x0000007f (le jeu US-ASCII classique) sont encodes simplement par les octets 0x00 a 0x7f (compatibilite ASCII). Cela signifie que les fichiers et les chaines qui contiennent uniquement des caracteres du jeu ASCII 7 bits ont exactement le meme encodage en ASCII et en UTF-8. - Tous les caracteres UCS superieurs a 0x7F sont encodes en une suite de multioctets constituee uniquement d'octets dans l'intervalle 0x80 a 0xfd. Ainsi aucun octet ASCII n'apparait en tant que partie d'un autre caractere, et il n'y a donc pas de probleme avec << \0 >> ou << / >>. - L'ordre de tri lexicographique des chaines UCS-4 est preserve. - Tous les 2^31 caracteres de l'UCS peuvent etre encodes en utilisant UTF-8. - Les octets 0xc0, 0xc1, 0xfe et 0xff ne sont jamais utilises dans l'encodage UTF-8. - Le premier octet d'une suite multioctet representant un caractere UCS non ASCII est toujours dans l'intervalle 0xc2 a 0xfd et indique la longueur de la suite multioctet. Tous les octets suivants de cette suite sont dans l'intervalle 0x80 a 0xbf. Cela permet une resynchronisation aisee et rend l'encodage robuste face aux octets manquants. - Les caracteres UCS encodes en UTF-8 peuvent avoir jusqu'a 6 octets. Neanmoins la norme Unicode ne precise aucun caractere au-dela de 0x10ffff, ainsi les caracteres Unicode ne peuvent avoir que jusque 4 octets en UTF-8. Encodage Les suites d'octets suivantes sont utilisees pour representer un caractere. Les suites utilisees dependent du numero de code UCS du caractere : 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 numero de code du caractere en representation binaire, bit de poids fort en premier (gros-boutiste). Seule la plus petite suite multioctet permettant de representer un numero de code doit etre utilisee. Les codes UCS de valeur 0xd800-0xdfff (remplacements en UTF-16) ainsi que 0xfffe et 0xffff (non caracteres UCS) ne doivent pas apparaitre dans un flux de donnees UTF-8. Aucun point au dela de U+10FFFF ne doit etre utilise selon la norme RFC 3629, ce qui limite les caracteres a 4 octets. Exemple Le caractere Unicode 0xA9 = 1010 1001 (le symbole copyright) est encode en UTF-8 de la maniere suivante : 11000010 10101001 = 0xc2 0xa9 et le caractere 0x2260 = 0010 0010 0110 0000 (le symbole << different de >>) est encode ainsi : 11100010 10001001 10100000 = 0xe2 0x89 0xa0 Notes applicatives Les utilisateurs doivent selectionner des parametres regionaux 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 connaitre l'encodage de caracteres utilise doivent toujours definir 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 parametres regionaux UTF-8 ont ete selectionnes, et si les entrees et sorties texte, les communications avec les terminaux, le contenu des fichiers textes, les noms de fichiers et les variables d'environnement sont encodes en UTF-8. Les programmeurs habitues aux jeux de caracteres mono-octet comme US-ASCII ou ISO/IEC 8859 doivent savoir que deux hypotheses valables jusque la ne le sont plus dans les parametres regionaux UTF-8. D'abord, un octet seul ne correspond pas necessairement a un unique caractere. Ensuite, comme les emulateurs de terminaux modernes en mode UTF-8 gerent egalement les caracteres double largeur du chinois, du japonais ou du coreen et les caracteres combines sans espacement, l'affichage d'un unique caractere ne fait pas avancer obligatoirement le curseur d'une position comme c'etait le cas en ASCII. Les fonctions de bibliotheques comme mbsrtowcs(3) et wcswidth(3) doivent etre desormais utilisees pour compter les caracteres et les positions de curseur. La suite ESC officielle pour basculer d'un encodage ISO/IEC 2022 (comme utilise par exemple par les terminaux VT100) en UTF-8 est ESC % G (<< \x1b%G >>). La suite de retour depuis UTF-8 est ISO/IEC 2022 est ESC % @ (<< \x1b%@ >>). D'autres suites ISO/IEC 2022 (comme celle pour basculer entre les jeux G0 et G1) ne sont pas applicables en mode UTF-8. Securite 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 ajoute la necessite pour les programmes conformes de ne pas accepter les formes non minimales en entree. Il s'agit de raisons de securite : si une saisie est examinee pour des problemes de securite, un programme doit rechercher seulement la version ASCII de << /../ >> ou << ; >> ou NUL. De nombreuses manieres non ASCII existent pour representer 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 francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot et Gregoire Scano Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.8 2 mai 2024 UTF-8(7)