| Unicode |
|---|
Jeux de caractères
|
Équivalences normalisées
|
Propriétés et algorithmes |
|
Autres transformations
|
Applications d'échanges de données
|
La norme ISO/CEI 10646, intitulée Technologies de l'information — Jeu universel de caractères codés sur plusieurs octets, tente de définir un système de codage universel pour tous les systèmes d'écriture. Ce standard est le fondement d'Unicode.
La norme internationale ISO/CEI 10646 définit l'Universal Character Set (UCS) comme un jeu de caractères abstrait. Chaque caractère abstrait est identifié par un nom unique (un en anglais et un en français) et associé à un nombre entier positif appelé son point de code (ou position de code).
Environ 10.000 caractères (symboles, lettres, nombres, idéogrammes, logogrammes) issus langues, systèmes d'écritures, traditions du monde entier sont recensés dans l'UCS. De nouveaux caractères provenant d'écritures plus rares ou anciens, ou encore de systèmes nouveaux, sont fréquemment ajoutés ou mis à jour dans l'UCS.
Depuis 1991, le consortium Unicode collabore avec l'ISO pour développer The Unicode Standard ("Unicode") et la norme ISO/CEI 10646. Les répertoires, noms de caractères, et points de code de la Version 2.0 d'Unicode correspondent exactement à ceux de la norme ISO/CEI 10646-1:1993 avec ses sept premiers amendements publiés. Chaque publication d'une nouvelle version d'Unicode donne ensuite lieu à une mise à jour de la norme, c'est-à-dire l'adjonction de nouveaux caractères et la mise à jour de ceux déjà présents. Par exemple, la publication Unicode 3.0 en Février 2000 correspond à la norme ISO/CEI 10646-1:2000. Voir la section Relation avec Unicode pour plus de détails.
L'UCS comprend plus d'1,1 million de points de code, mais seuls les 65.536 premiers (le Plan Multilingue de Base, ou PMB) ont été vulgarisés avant 2000. Cette situation commença à changer quand la Chine populaire (RPC) légiféra en 2000 que les systèmes informatiques vendus sur son territoire devaient supporter le GB 18030, ce qui nécessitait que les systèmes informatiques mis à la vente dans la RPC devaient utiliser les caractères au-delà du PMB.
Le système laisse delibérément beaucoup de code points non assignés, même dans le PMB. Cela permet de ménager des extensions futures ou de minimiser les conflits avec d'autres codages.
ISO/CEI 10646 définit plusieurs formes de codage de caractères pour l'Universal Character Set. La plus simple, UCS-2, assigne une valeur de code unique, c'est-à-dire une séquence d'un ou plusieurs nombres unique, entre 0 et 65.535 pour chaque caractère. Ainsi, exactement deux octets, soit un mot de 16 bits, permettent de représenter la valeur de tout point de code. En conséquence, UCS-2 permet une représentation binaire de chaque point de code du Plan Multilingue de Base, le PMB, à la condition que le point de code soit assigné, c'est-à-dire qu'il représente effectivement un caractère. Il en découle également qu'UCS-2 ne permet pas de représenter les points de code extérieurs au PMB.
Le premier amendement de l'édition originale de l'UCS définit UTF-16, une extension d'UCS-2, pour représenter les points de code extérieurs au PMB. Il existe dans le PMB une plage située dans la zone spéciale (S Zone) dont les points de code ne sont pas assignés. UCS-2 interdit l'utilisation de valeurs de code pour ces points de code, mais UTF-16 permet leur utilisation par paires afin de désigner les caractères extérieurs au PMB.
Cette plage est subdivisée en une partie haute et une partie basse, où chaque paire est constituée d'un "élément RC" de chacune de ces zones. Un élément RC est une séquence de deux octets faite d'un octet R et d'un octet C obtenus depuis la séquence de 4 octets qui correspond à une cellule dans l'espace de codage d'un jeu de codage de caractères.
Unicode a aussi adopté UTF-16, mais en terminologie Unicode, les éléments de zone moitié-haute sont appelées "demi-codets hauts d'indirection" et ceux de la moitié basse "demi-codets bas d'indirection". On rencontre aussi le terme de seizet d'indirection.
Un autre codage, UCS-4, utilise une seule valeur entre 0x00 et (théoriquement) 0x7FFFFFFF pour chaque caractère (bien que l'UCS s'arrête à 0x10FFFF et ISO/CEI 10646 a établi que tous les assignements futurs de caractères prendront place dans cette zone). UCS-4 permet la représentation de chaque valeur par exactement quatre octets (mots de 32-bits). UCS-4 permet donc une représentation binaire de chaque code point de l'UCS, y compris ceux en dehors du PMB. Comme en UCS-2, chaque caractère codé a une taille fixe en octets, qui fait qu'il est simple à manipuler, mais bien sûr, il nécessite deux fois plus de mémoire que l'UCS-2.
Occasionnellement, les articles sur Unicode mélangent les concepts UCS-2 et "UCS-16". UCS-16 n'existe pas ; les auteurs qui font cette erreur essayent de parler d'UCS-2 ou d'UTF-16.
L'Organisation internationale de normalisation (ISO) a commencé à composer l'Universal Character Set en 1989 et a publié un brouillon de l'ISO 10646 en 1990. Hugh McGregor Ross en était un de ces principaux architectes. Ce standard différait nettement du standard courant. Il définissait 128 groupes de 256 plans de 256 rangées de 256 cellules, pour un total apparent de 2.147.483.648 caractères, mais actuellement le standard ne permet de coder que 679.477.248 caractères, car la police a interdit les valeurs d'octets des caractères de contrôle (0x00 à 0x1F et 0x80 à 0x9F, en notation hexadécimale) partout. La lettre latine capitale A, par exemple, se situe dans le groupe 0x20, plan 0x20, rangée 0x20, cellule 0x41.
Les caractères de ce premier ISO 10646 standard peuvent être codés de trois manières :
En 1990, deux initiatives pour un universal character set existaient : Unicode, avec 16 bits pour chaque caractère (65.536 caractères possible), et ISO 10646. Les entreprises du logiciel refusèrent d'accepter la complexité et les exigences de taille de l'ISO standard et surent convaincre un nombre de l'ISO National Bodies de voter contre. Les standardisers de l'ISO réalisèrent qu'ils ne pouvaient continuer à supporter le standard en l'état et négocièrent l'unification de leur standard avec Unicode. Deux changements eurent lieu : la levée des limitations sur les caractères (prohibition des valeurs de caractères de contrôle), permettant des caractères tels que 0x0000101F, et la synchronisation du répertoire du Basic Multilingual Plane avec celui d'Unicode.
Cependant, le temps passant, la situation changea dans le standard Unicode lui-même : 65.536 caractères devinrent vite insuffisants et, depuis la version 2.0 et suivantes, le standard supporte l'encodage de 1.112.064 caractères par les mécanismes de surrogate d'UTF-16. Pour cette raison, ISO 10646 fut limité à contenir autant de caractères que pouvait en contenir l'UTF-16, c.-à-d. à peine plus d'un million de caractères au lieu de plus de 2.000 millions. Le codage UCS-4 de l'ISO 10646 a été incorporé dans le standard Unicode avec la limitation de l'UTF-16 sous le nom d'UTF-32. Comme pour UTF-1, personne ne l'utilisa, en raison de son mauvais design (aucune manière de distinguer les octets solitaires, les octets de début de séquences et les autres octets, un problème similaire à celui du codage Shift-JIS pour le japonais) et de faibles performances (beaucoup d'opérations de division). Rob Pike et Ken Thompson, les développeurs du système d'exploitation Plan 9, conçurent un nouveau codage de taille variable, rapide et bien-fini, qui finit par être appelé UTF-8.
ISO 10646 et Unicode ont un répertoire identique et numérotent les mêmes caractères avec les mêmes nombres. La différence entre les deux est qu'Unicode ajoute des règles et spécifications au standard ISO 10646. ISO 10646 est une simple table de caractères, une extension des standards précédents comme ISO 8859. En contraste, Unicode ajoute des règles de collation, normalisation de formes, et d'algorithme bidirectional pour les scripts comme l'hébreu et l'arabe. Pour l'interopérabilité entre les plates-formes, spécialement quand les scripts bidirectional sont utilisés, il ne suffit pas de supporter l'ISO 10646 ; Unicode doit être implémenté.
Certaines applications supportent les caractères ISO 10646 mais ne supportent pas complètement Unicode. Une de celles-là est xterm, qui peut correctement afficher tous les caractères ISO 10646 qui ont une carte de bijection character-to-glyph et un seul sens d'écriture. Il peut gérer certaines marques de combinaison par méthodes de simple overstriking, mais ne peut afficher l'hébreu (bidirectionnel), le devanagari (un caractère pour plusieurs glyphes) ou l'arabe (deux fonctionnalités). La plupart des applications GUI utilisent des fonctionnalités de tracer de bibliothèques standard qui gèrent de tels scripts, bien que les applications elles-mêmes ne les traitent toujours pas exactement correctement. Par exemple, sélectionner du texte dans certains scripts sous Mozilla Firefox fait que le texte saute autour.
ISO 10646, une référence générale, informelle pour la famille de standards ISO/CEI 10646, est acceptable dans la plupart des cas. Et même s'il s'agit d'un standard séparé, le terme Unicode est utilisé aussi fréquemment, informellement, à propos de l'UCS. Cependant, une référence normative à l'UCS tout comme une publication devrait se référer à une partie et une version particulière de l'une de ces deux normes sous la forme ISO/CEI 10646-{partie}:{année} ; par exemple : ISO/CEI 10646-1:1993.
Voir The Unicode Standard pour plus de détails.