UTF-8(7) Manuel de l'administrateur Linux UTF-8(7) NOM UTF-8 - Un encodage Unicode multi-octets compatible ASCII. DESCRIPTION Le jeu de caractres Unicode 3.0 (voir unicode(7)) est constitu d'un codage sur 16 bits. L'encodage Unicode le plus vident (connu sous le nom de UCS-2) consiste en une squence de mots de 16 bits. De telles chanes peuvent contenir, comme fragments de caractre 16 bits, des octets comme '\0' or '/' qui ont une signification particulire dans les noms de fichiers, et les paramtres de fonctions de bibliothque C. De plus la majorit des outils UNIX attendent des fichiers ASCII et ne peuvent pas lire des caractres reprsents par des mots de 16 bits sans subir des 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 sur-ensemble d'Unicode ISO 10646 Uni- versal Character Set (UCS), occupe mme un espace de codage sur 31 bits, et l'encodage vident UCS-4 (une squence de mots sur 32 bits) a les mmes inconvnients. L'encodage UTF-8 de l'Unicode et de l'UCS n'a pas ces inconvnients et est un moyen d'utiliser le jeu de caractres Unicode sous les systmes d'exploitation compatibles UNIX. PROPRITS. L'encodage UTF-8 a les proprits suivantes : * Les caractres UCS 0x00000000 0x0000007f (le jeu US-ASCII clas- sique) sont encods simplement par les octets 0x00 0x7f (compati- bilit ASCII) Ceci signifie que les fichiers et les chanes qui contiennent uniquement des caractres du jeu ASCII 7 bits ont exactement le mme codage en ASCII et en UTF-8. * Tous les caractres UCS suprieurs 0x7F sont encods en squences consistant uniquement en octets dans l'intervalle 0x80 a 0xFD, ainsi aucun octet ASCII n'apparat en tant que partie d'un autre caractre (plus de problmes avec '\0' ou '/'). * L'ordre de tri lexicographique des chanes UCS-4 est prserv. * Tous les 2^31 caractres de l'UCS peuvent tre encods en util- isant UTF-8. * Les octets 0xFE et 0xFF ne sont jamais utiliss dans le codage UTF-8. * Le premier octet d'une squence multi-octets reprsentant un car- actre UCS non-ASCII est toujours dans l'intervalle 0xC0 0xFD et indique la longueur de la squence multi-octets. Tous les octets suivants de cette squence sont dans l'intervalle 0x80 0xBF. Ceci permet une re-synchronisation aise et rend l'encodage robuste face aux octets manquants. * Les caractres UTF-8 cods en UCS peuvent avoir jusqu' 6 octets de long, nanmoins le standard Unicode ne prcise aucun caractre au-del de 0x10ffff, ainsi les caractres Unicode ne peuvent avoir que 4 octets de long avec UTF-8. ENCODAGE Les squences d'octets suivantes sont utilises pour reprsenter un caractre. Les squences utilises dpendent du numro de code UCS du caractre : 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 de bits xxx sont remplies avec les bits du numro de code du caractre en reprsentation binaire. Seule la plus petite squence multi-octets permettant de reprsenter un numro de code doit tre utilise. Les codes UCS de valeur 0xd800-0xdfff (UTF-16) comme 0xfffe et 0xffff ne doivent pas apparatre dans un flux de donnes UTF-8. EXEMPLES Le caractre Unicode 0xA9 = 1010 1001 (le symbole copyright) est encod en UTF-8 comme : 11000010 10101001 = 0xC2 0xA9 et le caractre 0x2260 = 0010 0010 0110 0000 (Le symbole "non gal") est encod ainsi : 11100010 10001001 10100000 = 0xE2 0x89 0xA0 NOTES APPLICATIVES Les utilisateurs doivent slectionner une localisation UTF-8, par exemple export LANG=fr_FR.UTF-8 afin d'active le support UTF-8 dans les applications. Les logiciels applicatifs qui doivent connatre l'encodage utilis devrait toujours fixer la localisation, par exemple setlocale(LC_CTYPE, "") et les programmeurs peuvent tester l'expression strcmp(nl_langinfo(CODESET), "UTF-8") == 0 pour savoir si une localisation UTF-8 a t slectionne, et si les entres-sorties de texte, les communications avec les terminaux, le contenu des fichiers de texte, les noms de fichiers et les variables d'environnement sont encods en UTF-8. Les programmeurs habitus aux jeux de caractres mono-octet comme US- ASCII ou ISO 8859 doivent savoir que deux suppositions valides jusque l ne le sont plus dans les localisation UTF-8. D'abord un octet seul ne correspond par ncessairement un unique caractre. Ensuite, comme les mulateurs de terminaux modernes, en mode UTF-8 supportent galement les caractres en double-largeur du Chinois, du Japonais ou du Coren, comme les caractres combins sans largeur, la sortie d'un unique caractre ne fait pas avancer obligatoirement le curseur d'une position comme c'tait le cas en ASCII. Les fonctions de bib- liothque comme mbsrtowcs(3) et wcswidth(3) doivent servir prsent pour compter les caractres et les positions de curseur. La squence 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 squence de retour depuis UTF-8 est ISO 2022 est ESC % @ ("\x1b%@"). D'autres squences ISO 2022 (comme celle pour basculer entre les jeux G0 et G1) ne sont pas applicables en mode UTF-8. On peut esprer que dans un futur proche, UTF-8 remplacera ASCII et ISO 8859 tous les niveaux comme encodage des caractres sur les systmes POSIX, ce qui conduira un environnement sensiblement plus riche pour traiter des textes. SECURIT Les standards Unicode et UCS demande que le producteur UTF-8 utilise la forme la plus courte possible, par exemple, produire une squence de deux octets avec un premier octet 0xc0 n'est pas conforme. Unicode 3.1 a ajout la ncessit pour les programmes conformes de ne pas accepter les formes non minimales en entre. Il s'agit de raisons de scurit : si une saisie est examine pour des problmes de scurit, un programme doit rechercher seulement la version(1,3,5) ASCII de "/../" ou ";" ou NUL. Il y a de nombreuses manires non-ASCII de reprsenter ces choses dans un encodage UTF-8 non minimal. CONFORMIT ISO/IEC 10646-1:2000, Unicode 3.1, RFC 2279, Plan 9. AUTEUR Markus Kuhn <mgk25@cl.cam.ac.uk> VOIR AUSSI nl_langinfo(3), setlocale(3), charsets(7), unicode(7) TRADUCTION Christophe Blaess, 1996-2003. LDP 25 juillet 2003 UTF-8(7)