UTF-8
Unicode |
---|
Jeux de caractères | Équivalences normalisées- NFC (précomposée)
- NFD (décomposée)
- NFKC (compatibilité)
- NFKD (compatibilité)
| Propriétés et algorithmes | Codage | Autres transformations | Applications d'échanges de données | UTF-8 ( UCS transformation format 8 bits) est un format de codage de caractères défini pour les caractères Unicode (UCS). Chaque caractère est codé sur une suite d'un à quatre octets. UTF-8 a été conçu pour être compatible avec certains logiciels originellement prévus pour traiter des caractères d'un seul octet. UTF-8 est standardisé dans la RFC 3629 (UTF-8, a transformation format of ISO 10646). Le codage était aussi défini dans le rapport technique 17 de la Norme Unicode. Il fait maintenant partie intégrante de la norme dans son chapitre 3 Conformance et est également approuvé par l’Organisation internationale de normalisation (ISO), l’Internet Engineering Task Force (IETF) et la plupart des organismes de normalisation nationaux. L’IETF requiert qu’UTF-8 soit pris en charge par les protocoles de communication d’Internet échangeant du texte. DescriptionLe numéro de chaque caractère est donné par le standard Unicode. Les caractères de numéro 0 à 127 sont codés sur un Octet dont le bit de poids fort est toujours nul. Les caractères de numéro supérieur à 127 sont codés sur plusieurs octets. Dans ce cas, les bits de poids fort du premier octet forment une suite de 1 de longueur égale au nombre d'octets utilisés pour coder le caractère, les octets suivants ayant 10 comme bits de poids fort. Définition du nombre d'octets utilisés | Représentation binaire UTF-8 | Signification |
---|
0xxxxxxx | 1 octet codant 1 à 7 bits | 110xxxxx 10xxxxxx | 2 octets codant 8 à 11 bits | 1110xxxx 10xxxxxx 10xxxxxx | 3 octets codant 12 à 16 bits | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx | 4 octets codant 17 à 21 bits |
Ce principe pourrait être étendu jusqu'à six octets pour un caractère, mais UTF-8 pose la limite à quatre. Ce principe permet également d'utiliser plus d'octets que nécessaire pour coder un caractère, mais UTF-8 l'interdit. Exemples de codage UTF-8 | Caractère | Numéro du caractère | Codage binaire UTF-8 |
---|
A | 65 | 01000001 | é | 233 | 11000011 10101001 | € | 8364 | 11100010 10000010 10101100 | 𝄞 | 119070 | 11110000 10011101 10000100 10011110 |
Dans toute chaîne de caractères UTF-8, on remarque que : - tout octet de bit de poids fort nul code un caractère US-ASCII sur un octet ;
- tout octet de bits de poids fort valant 11 est le premier octet d'un caractère codé sur plusieurs octets ;
- tout octet de bits de poids fort valant 10 est à l'intérieur d'un caractère codé sur plusieurs octets.
Avantages- Universalité
- Ce codage permet de représenter les milliers de caractères d'Unicode.
- Compatibilité avec US-ASCII
- Un texte en US-ASCII est codé identiquement en UTF-8.
- Interopérabilité
- Du fait qu'un caractère est découpé en une suite d'octets (et non en mots de plusieurs octets), il n'y a pas de problème d'Endianness. Problème qui apparaît avec les codages UTF-16 et UTF-32 par exemple.
- Efficacité
- Pour les langues utilisant beaucoup les caractères US-ASCII, UTF-8 nécessite moins d'octets que l'UTF-16 ou l'UTF-32.
- Réutilisabilité
- De nombreuses techniques de programmation informatique valables avec les caractères uniformément codés sur un octet le restent avec UTF-8, notamment :
- la manière de repérer la fin d'une chaîne de caractères C, car l'octet 00000000 dans une chaîne de caractères codés en UTF-8 est toujours le caractère nul.
- la manière de trouver une sous-chaîne est identique.
- Fiabilité
- Il s'agit d'un codage auto-synchronisant (en lisant un seul octet on sait si c'est le premier d'un caractère ou non).
- Une séquence décrivant un caractère n'apparaît jamais dans une séquence plus longue décrivant un autre caractère (cas de Shift-JIS).
- Il n'existe pas de code « d'échappement » changeant l'interprétation de la suite d'une séquence d'octets.
Inconvénients - Taille variable
- Les caractères sont représentés en UTF-8 par des séquences d'octets de taille variable, ce qui rend certaines opérations sur les chaînes de caractères plus compliquées : le calcul du nombre de caractères ; le positionnement à une distance donnée dans un fichier texte et en règle générale toute opération nécessitant l'accès au caractère de position N dans une chaîne.
- Efficacité
- Pour les langues utilisant beaucoup de caractères extérieurs à US-ASCII, UTF-8 occupe sensiblement plus d'espace. Par exemple, les idéogrammes courants employés dans les textes de langues asiatiques comme le chinois, le Coréen ou le Japonais (Kanji, par exemple) utilisent 3 octets en UTF-8 contre 2 octets en UTF-16. De manière générale, les scripts employant beaucoup de caractères de valeur supérieure à U+0800 occupent plus de mémoire que s'ils étaient codés avec UTF-16.
- Séquences invalides
- De par son système de codage, il est possible de représenter un point de code de différentes manières en UTF-8, ce qui peut poser un problème de sécurité : un programme mal écrit peut accepter un certain nombre de représentations UTF-8, normalement invalides selon la RFC 3629 mais pas selon la spécification originale, et les convertir comme un seul et même caractère. De fait, un Logiciel détectant certaines chaînes de caractères (pour prévenir les injections SQL, par exemple) peut échouer dans sa tâche.
- Prenons un exemple tiré d'un cas réel de virus attaquant des serveurs HTTP du Web en 2001 ((en)[#] [#] [#]). Une séquence à détecter pourrait être « /../ » représentée en ASCII (a fortiori en UTF-8) par les octets «
2F 2E 2E 2F » en notation hexadécimale. - Cependant, une manière malformée de coder cette chaîne en UTF-8 serait «
2F C0 AE 2E 2F », appelée aussi en anglais overlong form (forme superlongue). Si le logiciel n'est pas soigneusement écrit pour rejeter cette chaîne, en la mettant par exemple sous forme canonique, une brèche potentielle de sécurité est ouverte. Cette attaque est appelée directory traversal. HistoireUTF-8 a été inventé par Kenneth Thompson lors d'un dîner avec Rob Pike aux alentours de septembre 1992. Il a été immédiatement utilisé dans le système d'exploitation Plan 9 sur lequel ils travaillaient. Une contrainte à résoudre était de coder les caractères nul et '/' comme en ASCII et qu'aucun octet codant un autre caractère n'ait le même code. Ainsi les systèmes d'exploitation UNIX pouvaient continuer à rechercher ces deux caractères dans une chaîne sans adaptation logicielle. Prise en charge - Navigateurs web : la prise en charge d'UTF-8 commença à être répandue à partir de 1998.
- Fichiers et noms de fichiers : de plus en plus courant sous les systèmes GNU/Linux, pas très bien supporté sous Windows.
- Client de messagerie
- Thunderbird supporte UTF-8
- Si.Mail supporte UTF-8
- certains webmails, comme Horde/IMP ne sont pas compatibles avec ce standard.
Voir aussiLiens externes - (fr) Formulaire de conversion UTF-8, UTF-16, UTF-32
- (fr) Confirmité - Traduction du Standard Unicode en français [pdf]
- (en) Conformance - The Unicode Standard 4.0, chapitre 3.2 pp. 60-61 et chapitre 3.4 pp. 64-65 et chapitre 3.9 pp. 73-81, août 2003, ISBN 0-321-18578-1 [pdf]
- (en) RFC 3629 - UTF-8, a transformation format of ISO 10646, Novembre 2003 (standard, totalement compatible avec Unicode) ;
- (en) RFC 2279 - UTF-8, a transformation format of ISO 10646, janvier 1998 (ancienne révision, obsolète) ;
- (en) RFC 2044 - UTF-8, a transformation format of Unicode and ISO 10646, octobre 1996 (version initiale approuvée par l’ISO, obsolète) ;
- (en) Papier original sur UTF-8 - de Rob Pike et Ken Thompson (informatif, obsolète) [pdf].
- (en) RFC 2277 - IETF policy on character sets and languages, janvier 1998
- (en) Histoire de la création d'UTF-8 - par Rob Pike
|