ISO/CEI 10646

La norme internationale ISO/CEI 10646 définit le jeu universel de caractères (JUC), en anglais 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 110 000 caractères (symboles, lettres, nombres, idéogrammes, logogrammes) issus de langues, systèmes d’écriture, traditions du monde entier sont recensés dans le JUC. De nouveaux caractères provenant d’écritures plus rares ou plus anciennes, ou encore de systèmes nouveaux, sont fréquemment ajoutés ou mis à jour dans le JUC.

Depuis 1991, le Consortium Unicode collabore avec l’ISO pour développer le Standard Unicode (« 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[2] 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 d’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.

Le JUC 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 reconnaitre le GB 18030, ce qui nécessitait que les systèmes informatiques mis à la vente dans la RPC utilisent des caractères au-delà du PMB.

Le système laisse délibérément beaucoup de points de code non assignés à des caractères, 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 le jeu universel de caractères codés. La plus simple, UCS-2, qui a été supprimée dans la version 2011, assigne une valeur de code unique, c’est-à-dire un nombre 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 du plan multilingue de base (PMB), à la condition que le point de code soit assigné, c’est-à-dire qu’il représente effectivement un caractère. Cette forme de codage est obsolète car elle ne permet pas de représenter les points de code extérieurs au PMB.

Le premier amendement de l’édition originale d’ISO/CEI 10646 définit UTF-16, une extension d’UCS-2, pour représenter les points de code extérieurs au PMB, reprise ensuite par Unicode. Il existe dans le PMB une plage appelée zone d’indirection dont les points de code ne sont pas assignés à des caractères. 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 deux parties égales, une partie haute et une partie basse, et chaque paire est constituée d’une « unité de code » de chacune de ces zones. Les éléments de la première moitié (haute) sont appelés « demi-codets hauts d’indirection » et ceux de la seconde moitié (basse) « demi-codets bas d’indirection ». On rencontre aussi le terme de seizet d’indirection.

Un autre codage, UTF-32 (ou UCS-4), utilise une seule valeur entre 0x00 et (théoriquement) 0x7FFFFFFF pour chaque caractère (bien que maintenant le JUC 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 (soit un mot de 32 bits). UTF-32 permet donc une représentation binaire de chaque point de code du JUC, 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 le jeu universel de caractères en 1989 et a publié un brouillon de l’ISO 10646 en 1990. Hugh McGregor Ross en était un de ses principaux architectes. Ce standard différait nettement du standard actuel. 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 en fait le standard ne permettait de coder que 679 477 248 caractères, car il interdisait d’utiliser où que ce soit les valeurs d’octets des caractères de contrôle (0x00 à 0x1F et 0x80 à 0x9F, en notation hexadécimale). La lettre latine capitale A, par exemple, se situait dans le groupe 0x20, plan 0x20, rangée 0x20, cellule 0x41.

Les caractères de ce premier standard ISO 10646 pouvaient être codés de trois manières :

1. UCS-4, quatre octets pour chaque caractère, permettant le codage facile de tous les caractères ;
2. UCS-2, deux octets pour chaque caractère, permettant le codage immédiat du premier plan (0x20, le plan multilingue de base contenant les 36 864 premiers points de code), les autres plans et groupes étant codés en commutant entre eux par des séquences d'échappement ISO/CEI 2022 ;
3. UTF-1, qui codait tous les caractères en séquences d’octets de longueur variable (1 à 5 octets, chacun d’eux ne contenant aucun caractère de contrôle).

En 1990, deux initiatives pour un jeu de caractères universel (UCS) existaient : Unicode, avec 16 bits pour chaque caractère (65 536 caractères possibles), et ISO 10646. Les entreprises du logiciel refusèrent la complexité et les exigences de taille de la norme ISO et surent convaincre plusieurs organismes nationaux membres de l’ISO de voter contre. Les normalisateurs de l’ISO réalisèrent qu’ils ne pouvaient continuer à supporter la norme 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 ainsi des caractères tels que 0x0000101F, et la synchronisation du répertoire du plan multilingue de base avec celui d’Unicode.

Cependant, le temps passant, la situation changea dans le standard Unicode lui-même : 65 536 caractères devinrent insuffisants et, depuis la version 2.0 et suivantes, le standard supporte le codage de 1 112 064 caractères par les mécanismes d’indirection d’UTF-16. Pour cette raison, ISO 10646 fut limité à contenir autant de caractères que pouvait en coder l’UTF-16, c’est-à-dire à peine plus d’un million de caractères au lieu de plus de 2 milliards. 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. Quant à UTF-1, personne ne l’utilisait, 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 conçu, 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 à la norme ISO 10646. ISO 10646 est une simple table de caractères, une extension des standards précédents comme ISO/CEI 8859. En revanche, Unicode ajoute des règles de collation, normalisation de formes, et d’algorithme bidirectionnel pour les écritures comme l’hébreu et l’arabe. Pour l’interopérabilité entre les plates-formes, spécialement quand les écritures bidirectionnelles sont utilisées, il ne suffit pas de supporter l’ISO 10646 ; Unicode doit être implémenté.

Certaines applications peuvent utiliser les caractères ISO 10646 sans implémenter complètement Unicode. Une de celles-là est xterm, qui peut correctement afficher tous les caractères ISO 10646 qui ont une bijection entre caractère et glyphe et un seul sens d’écriture. Il peut gérer certaines marques combinatoires par méthodes de simple surimpression, mais ne peut afficher l’hébreu (écriture de droite à gauche), la dévanâgari (un même caractère représenté par plusieurs glyphes) ou l’arabe (qui cumule ces deux particularités). La plupart des applications à interface graphique utilisent des fonctionnalités de tracé de bibliothèques standard qui gèrent de tels systèmes d’écriture, bien que les applications elles-mêmes ne les traitent toujours pas exactement correctement. Par exemple, sélectionner du texte dans certaines écritures sous Mozilla Firefox fait que le texte se déplace bizarrement.

ISO 10646, une référence générale, informelle pour la famille de normes 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 du JUC. Cependant, une référence normative au JUC tout comme une publication devrait se référer à une version particulière de l’une de ces deux normes sous la forme ISO/CEI 10646:{année} ; par exemple : ISO/CEI 10646:2003.

Note :

Avant l’édition 2003, il y avait deux parties de la norme ISO/CEI 10646, auquel on se réfère alors comme suit : ISO/CEI 10646-{partie}:{année} ; par exemple : ISO/CEI 10646-1:1993