Répertoire des caractères abstraits (abstract character repertoire)

La couche la plus élevée est la définition du jeu de caractères abstraits. Par exemple, Latin-1 a un jeu de 256 caractères quand Unicode et l'ISO/CEI 10646 normalisent conjointement actuellement près de 110 000 caractères dans un répertoire commun.

En outre, Unicode et l'ISO/CEO 10646 affectent une dénomination commune et normalisée à chacun de ces caractères. La liste des caractères abstraits avec leurs noms normalisés constituent la couche commune de présentation de la norme ISO/CEI 10646 et du standard Unicode. Par exemple, le caractère Ç est nommé « lettre majuscule latine c cédille ». Cette définition est totalement identique à celle de l'ISO/CEI 10646, qui approuve toute extension du répertoire. Unicode ne reprend dans le texte de sa norme que les noms normatifs en anglais, mais la norme ISO/CEI 10646 est publiée en deux langues également normatives. Ainsi les noms en anglais et en français sont tous deux normalisés par l'ISO.

Dans les faits, toute extension du répertoire se fait aujourd'hui conjointement entre le groupe de travail responsable de l'ISO/CEI 10646 (JTC1/SC2/WG2, dont les membres votants sont uniquement des autorités de normalisation nationales des pays participants, ou leur représentant officiel), et le Comité technique Unicode UTC (dont les membres votants peuvent être n'importe quelle organisation privée ou d'intérêt public, ou même un gouvernement, qui a adhéré et paye une redevance annuelle permettant de participer à ces décisions).

Jeu de caractères codés (coded character set)

La normale ISO/CEI 10646 ajoute à la table précédente un numéro associé à chaque caractère abstrait du répertoire commun, lequel est repris dans le standard Unicode. Notons bien qu'il ne s'agit pas d'une représentation en mémoire, juste d'un nombre entier, appelé point de code.

L'espace de codage de ces nombres est divisé en 17 zones de 65 536 points de code : ces zones sont appelées « plans de code ». Les plans de code sont eux-mêmes divisés en « colonnes de code » comprenant 16 points de code, qui sont (autant que possible) l'unité minimale de réservation dans le répertoire pour des groupes de caractères (assignés ou à venir) souvent utilisés conjointement dans une même écriture ou ayant des propriétés de base communes).

Chaque point de code est noté « U+ » suivi(s) de 4 à 6 chiffres en hexadécimal :

• 4 chiffres pour le premier plan appelé plan multilingue de base (donc entre U+0000 et U+FFFF) ;
• 5 chiffres pour les 15 plans suivants (entre U+10000 et U+FFFFF) ;
• 6 chiffres pour le dernier plan (entre U+100000 et U+10FFFF).

Ainsi le caractère nommé « Lettre majuscule latine c cédille » (Ç) a le numéro U+00C7. Il appartient au premier plan.

En principe tous les points de code entre U+0000 et U+10FFFF sont disponibles, mais certaines plages sont perpétuellement réservées à des usages particuliers, notamment une zone d'indirection exclue afin de permettre le codage UTF-16 (cf. infra), les zones à usage privé, ainsi que quelques régions (dont les deux derniers points de code de chacun des plans de code, par exemple U+FFFE ou U+FFFF) contenant des « non-caractères » et dont l'usage est interdit dans un échange de données conforme. Les autres points de code sont soit déjà affectés à des caractères, soit réservés par l'ISO/CEI 10646 pour une normalisation future.

Zone à usage privé : l'ISO/CEI 10646 et Unicode ont assigné de nombreux points de code à des caractères valides, mais dont la sémantique est inconnue car d'usage privé (par exemple les deux derniers plans entre U+F0000 et U+10FFFF sont entièrement destinés à cet usage, hormis les deux points de code à la fin de chaque plan qui sont des non-caractères interdits dans un texte conforme).

Là encore, la standardisation du codage, c'est-à-dire l'affectation des points de codes aux caractères du répertoire commun est une décision conjointe partagée entre les normes Unicode et ISO/CEI 10646. Tous les caractères du répertoire disposent d'un point de code unique (même si pour certaines langues ou pour Unicode certains caractères sont considérés comme équivalents, avec l'un d'eux désigné comme standard et recommandé et les autres présents pour des raisons de compatibilité ascendante, par exemple avec d'anciennes normes ou avec des standards encore fréquemment utilisés).

On peut noter que si le répertoire des caractères est extensible, il est limité par la borne supérieure de l'espace de codage : U+10FFFF. La grande majorité des points de code possibles n'est encore associée à aucun caractère particulier, mais peut l'être à tout moment.

Aussi ces points de code encore libres ne sont pas considérés comme non valides, mais représentent bien des caractères abstraits (non encore spécifiés, et réservés jusqu'à nouvel ordre). Ces caractères abstraits (de même que les caractères à usage privé) complètent le jeu de caractères codés du répertoire standardisé pour former un jeu unique, dit « jeu de caractères codés universel » (Universal Coded Character Set, souvent abrégé en UCS), qui contient tous les jeux de caractères codés des répertoires de chacune des versions passées, présentes et futures de l'ISO/CEI 10646 et ceux d'Unicode (depuis la version 1.1 uniquement).

Formalisme de codage des caractères (character encoding form)

La couche suivante spécifie une représentation physique (en mémoire, sur disque…) de chacun des caractères abstraits : quelle unité de codage (code units), ou codet, va représenter un caractère ou plus exactement un point de code : octet, seizet (en) (mot de 16 bits) ou trente-deuzet (en) (mot de 32 bits).

Il peut exister (et il existe) plusieurs de ces formalismes. Un formalisme particulier doit préciser la taille de l'unité de codage et indiquer de quelle façon le nombre entier représentant un point de code est représenté en une suite d'unités de codage − et inversement, c'est-à-dire comment retrouver le point de code étant donné une suite d'unités de codage.

Mécanisme de sérialisation des caractères (character encoding scheme)

Cette couche s'occupe de sérialiser les suites d'unités de codage définies par la couche précédente en suites d'octets. C'est ici que se choisit l'ordre des octets entre les ordres gros-boutien (octet le plus significatif d'abord) et petit-boutien (octet le moins significatif d'abord).

C'est également à cette étape qu'il est possible d'ajouter un indicateur d'ordre des octets (ou BOM, pour byte order mark), qui permet d'indiquer en début de fichier ou de flot de données s'il est en gros-boutien ou en petit-boutien. Dans le monde Internet, on l'utilise rarement, en préférant un marquage explicite (« charset=UTF-16BE » en MIME, par exemple, pour indiquer un flot de données gros-boutien, où BE signifie big endian).

Surcodage de transfert (transfer encoding syntax)

À ce niveau peuvent intervenir les mécanismes de compression ou de chiffrement. Il peut aussi y avoir également des surcodages, notamment au sein des protocoles MIME et HTTP qui les utilisent presque partout, mais aussi pour le LDAP, qui spécifient par exemple que les chaînes Unicode doivent être codées en UTF-8 puis surcodées en Base64 (ou avec d'autres formats d'échappement) et comment indiquer ces options de surcodage au sein des données échangées par ces applications.

Ces compressions, chiffrements et surcodages, le plus souvent nécessaires et adaptés (et souvent standardisés) à divers protocoles pour la sécurisation et l'encapsulation correcte du texte codé et transporté (ou stocké), ne font partie ni standard Unicode, ni de la norme ISO/CEI 10646.

UTF-8

L'UTF-8, spécifié dans le RFC 3629^[5], est le plus commun pour les applications Unix et Internet. Son codage de taille variable lui permet d'être en moyenne moins coûteux en occupation mémoire (pour les langues à alphabet latin). Mais cela ralentit nettement les opérations où interviennent des extractions de sous-chaînes dans certains langages qui indexent des chaînes par des entiers (exemple = "815^e caractère de la chaîne"), car il faut compter les caractères depuis le début de la chaîne pour savoir où se trouve le premier caractère à extraire.

L'UTF-8 assure aussi, et c'est son principal avantage, une compatibilité avec les manipulations simples de chaînes en ASCII dans les langages de programmation. Ainsi, les programmes écrits en C peuvent souvent fonctionner sans modification.

Initialement, l'UTF-8 pouvait coder n'importe quel point de code entre U+0000 et U+7FFFFFFF (donc jusqu'à 31 bits). Cet usage est déprécié et la norme ISO/CEI 10646 a été amendée pour ne plus supporter que les points de code valides des 17 premiers plans, sauf ceux de la demi-zone correspondant aux codets utilisés en UTF-16 pour la représentation sur deux codets des points de code des 16 plans supplémentaires. Aussi les séquences les plus longues en UTF-8 nécessitent au maximum 4 octets, au lieu de 6 précédemment. De plus, UTF-8 a été amendé d'abord par Unicode puis par l'ISO/CEI 10646 pour ne plus accepter que la représentation la plus courte de chaque point de code (unicité du codage). Le fait de pouvoir représenter de plusieurs façons différentes un même caractère posait des problèmes de sécurité, car le pirate pouvait contourner par une écriture différente une forme "filtrée".

Son avantage sur l'UTF-16 (et l'UTF-32) est que les différences d'ordonnancement des octets composant un mot (endianness) ne posent pas de problème dans un réseau de systèmes hétérogènes ; ainsi, cette transformation est utilisée aujourd'hui par la plupart des protocoles d'échange standardisés.

D'autre part, l'UTF-8 est totalement compatible pour la transmission de textes par des protocoles basés sur le jeu de caractères ASCII, ou peut être rendu compatible (au prix d'une transformation sur plusieurs octets des caractères non-ASCII) avec les protocoles d'échange supportant les jeux de caractères codés sur 8 bits (qu'ils soient basés sur ISO/CEI 8859 ou de nombreux autres jeux de caractères codés sur 8 bits définis par des normes nationales ou des systèmes propriétaires particuliers).

Son principal défaut est le codage de longueur très variable (1 octet pour les points de code assignés aux caractères ASCII–ISO/CEI 646, 2 à 4 octets pour les autres points de code), même si l'auto-synchronisation propre à l'encodage UTF-8 permet de déterminer le début d'une séquence à partir d'une position aléatoire (en effectuant au plus 3 lectures supplémentaires des codets qui précèdent). Cependant, cet encodage n'est pas conçu pour faciliter le traitement des chaînes de caractères : on lui préfère alors souvent l'UTF-16, parfois l'UTF-32 (gourmand en mémoire).

UTF-16

L'UTF-16 est un bon compromis lorsque la place mémoire n'est pas trop restreinte, car la grande majorité des caractères Unicode assignés pour les écritures des langues modernes (dont les caractères les plus fréquemment utilisés) le sont dans le plan multilingue de base et peuvent donc être représentés sur 16 bits. La version française de l'ISO/CEI 10646 nomme ces mots de 16 bits des « seizets », mais la version internationale les décrit cependant bien comme de classiques mots de 16 bits composés de deux octets, et soumis aux règles usuelles de boutisme.

C'est notamment le codage qu'utilise la plateforme Java en interne, ainsi que Windows pour ses API compatibles Unicode (avec le type wchar).

Certains cadres légaux, tels le GB 18030 utilisé en Chine, peuvent exiger la prise en charge des plans supplémentaires, ceux-ci contenant notamment des caractères présents dans les noms propres.

Les points de code des seize plans supplémentaires nécessitent une transformation sur deux mots de 16 bits :

• on soustrait 0x10000 au point de code, ce qui laisse un nombre de 20 bits dans l'intervalle de 0 à 0xFFFFF ;
• les 10 bits de poids fort (un nombre entre 0 et 0x3FF) sont additionnés à 0xD800, et donnent la première unité de code dans la demi-zone haute (0xD800 à 0xDBFF) ;
• les 10 bits de poids faible (un nombre entre 0 et 0x3FF) sont additionnés à 0xDC00, et donnent la seconde unité de code dans la demi-zone basse (0xDC00 à 0xDFFF) ;

Il est possible de déterminer le début de la séquence de codage à partir d'un point quelconque d'un texte représenté en UTF-16 en effectuant au maximum une lecture supplémentaire, uniquement si ce codet est dans la demi-zone basse. Cette forme est plus économique et plus facile à traiter rapidement que l'UTF-8 pour la représentation de textes contenant peu de caractères ASCII (U+0000 à U+007F).

Comme la plupart des caractères couramment usités résident dans le plan de base, l'encodage des plans supplémentaires a longtemps été peu testé dans les logiciels, conduisant à des bogues ou des problèmes de sécurité même dans des logiciels largement diffusés, par exemple en supposant à tort qu'il soit sain de découper ou de tronquer une chaîne entre deux unités de code quelconque (ce qui n'est pas le cas avec UTF-16, pas plus qu'avec UTF-8, ni même avec tous les autres codages multi-octets dont les codages historiques d'avant Unicode/ISO/CEI 10646)^[8].

Toutefois, cette transformation possède deux schémas de codage incompatibles qui dépendent de l'ordonnancement des octets dans la représentation d'entiers sur 16 bits. Pour résoudre cette ambiguïté et permettre la transmission entre systèmes hétérogènes, il est nécessaire d'adjoindre une information indiquant le schéma de codage utilisé (UTF-16BE ou UTF-16LE), ou bien de préfixer le texte codé avec la représentation du point de code valide U+FEFF (assigné au caractère « espace insécable de largeur nulle », un caractère aujourd'hui réservé à ce seul usage en tant que marqueur d'ordonnancement des octets), puisque le point de code « renversé » U+FFFE valide est un non-caractère, interdit dans les textes conformes à Unicode et ISO/CEI 10646.

L'autre défaut d'UTF-16 est qu'un texte transformé avec lui et transmis avec l'un ou l'autre des deux schémas de codage contient un grand nombre d'octets nuls ou ayant une valeur en conflit avec les valeurs d'octets réservées par certains protocoles d'échange : le principal usage d'UTF-16 est dans le traitement en mémoire au sein des logiciels (également dans le stockage de métadonnées de certains systèmes de fichiers, et dans certaines bases de données où il peut être plus compact que l'UTF-8, notamment pour les textes asiatiques), le codage UTF-8 lui étant préféré pour les échanges sur les réseaux (et même dont la prise en charge est hautement recommandée voire maintenant exigée pour les protocoles du web de l'IETF, la prise en charge de l'UTF-16 et ses variantes dans ces protocoles restant facultative et en pratique très peu utilisée, d'autant que l'avantage relatif de compacité de l'UTF-16 disparaissant avec l'emploi fréquent de la compression de données, maintenant bien prise en charge dans de nombreux protocoles Internet).

UTF-32

L'UTF-32 est utilisé lorsque la place mémoire n'est pas un problème et que l'on a besoin d'avoir accès à des caractères de manière directe et sans changement de taille (hiéroglyphes égyptiens).

L'avantage de cette transformation standardisée est que tous les codets ont la même taille. Il n'est donc pas nécessaire de lire des codets supplémentaires pour déterminer le début de la représentation d'un point de code.

Toutefois, ce format est particulièrement peu économique (y compris en mémoire) puisqu'il « gaspille » inutilement au moins un octet (toujours nul) par caractère. La taille en mémoire d'un texte joue négativement sur les performances puisque cela nécessite plus de lectures et écritures sur disque en cas de saturation de la mémoire vive, et que cela diminue aussi les performances du cache mémoire des processeurs.

Pour les textes écrits dans les langues modernes actuelles (hormis certains caractères rares du plan idéographique supplémentaire) et n'utilisant donc que les points de code du plan multilingue de base, cette transformation double la quantité mémoire nécessaire par rapport à l'UTF-16.

Comme l'UTF-16, l'UTF-32 possède plusieurs schémas de codage dépendant de l'ordonnancement des octets composant un entier de plus de 8 bits (deux schémas de codage de l'UTF-32 sont standardisés, UTF-32BE et UTF-32LE). Il est donc aussi nécessaire de préciser ce schéma de codage, ou de le déterminer en préfixant le texte par la représentation en UTF-32 du point de code U+FEFF. Comme l'UTF-16, la présence d'octets nuls dans les schémas de codage standardisés de l'UTF-32 le rend incompatible avec de nombreux protocoles d'échange entre systèmes hétérogènes.

Aussi ce format n'est utilisé le plus souvent que très localement pour certains traitements en tant que forme intermédiaire plus facile à manipuler, et on lui préfère souvent la transformation UTF-16 souvent plus performante pour traiter et stocker des quantités importantes de textes, la conversion entre les deux étant très simple à réaliser, et très peu coûteuse en termes de complexité de traitement.

En fait, de très nombreuses bibliothèques de traitement de textes sont écrites uniquement avec l'UTF-16 et sont plus performantes qu'en UTF-32, même lorsque les textes contiennent des caractères des plans supplémentaires (car ce cas de figure reste rare dans la très grande majorité des cas).

On notera toutefois que la transformation en UTF-32 utilise des codets sur 32 bits, dont de très nombreuses valeurs peuvent ne représenter aucun point de code valide (valeurs hors des deux intervalles représentant les points de code valides U+0000 à U+D7FF et U+E000 à U+10FFFF), donc aucun caractère valide ou réservé (toute information qui y serait contenue ne peut donc pas être du texte au sens d'Unicode). La transmission de textes utilisant ces valeurs invalides de codets dans un des schémas de codage standardisés de l'UTF-32 est interdite pour tout système conforme à Unicode (il faut utiliser plutôt les points de code à usage privé), puisqu'il sera impossible de les représenter dans une autre transformation UTF avec lesquelles les trois UTF standardisées sont bijectivement compatibles.

Plan multilingue de base (PMB, U+0000 à U+FFFF)

Plan multilingue complémentaire (PMC, U+10000 à U+1FFFF)

Plan sinographique complémentaire (PSC, U+20000 à U+2FFFF)

Plan sinographique ternaire (PST, U+30000 à U+3FFFF)

Plans complémentaires réservés (U+40000 à U+DFFFF)

Plan complémentaire spécialisé (PCS, U+E0000 à U+EFFFF)

Plans complémentaires à usage privé (U+F0000 à U+10FFFF)

Les zones à usage privé ne contiennent pas les mêmes œils d'une police à l'autre et doivent donc être évités pour le codage de textes destinés aux échanges entre systèmes hétérogènes. Toutefois, ces points de codes à usage privé sont valides et peuvent être utilisés dans tout traitement automatisé conforme aux normes Unicode et ISO/CEI 10646, y compris entre systèmes différents s'il existe un accord mutuel privé concernant leur usage.

En l'absence d'accord entre les deux parties, des systèmes utilisant ces caractères peuvent rejeter les textes les contenant, car les traitements qu'ils leur font subir pourraient ne pas fonctionner correctement ou causer des problèmes de sécurité ; les autres systèmes qui n'attribuent aucune fonction spéciale à ces caractères doivent en revanche les accepter comme valides et les conserver comme partie intégrante des textes, comme s'il s'agissait de symboles graphiques, même s'ils ne savent pas les afficher correctement.

Les non-caractères sont des points de code valides, mais ils ne sont pas (et ne seront jamais) assignés à des caractères standardisés. Leur usage dans le codage de textes transmis entre systèmes (même si identiques) est interdit, car il est impossible de les rendre compatibles avec les formes de transformation universelles standardisées (dont UTF-8, UTF-16, UTF-32) les schémas de codage correspondants, et les autres codages standardisés compatibles avec Unicode et ISO/CEI 10646 (BOCU-1, SCSU, différentes versions de la norme chinoise GB 18030, etc.). Toutefois, certains systèmes les génèrent et les utilisent localement, mais pour un traitement strictement interne destiné à faciliter l'implémentation des algorithmes de traitement de textes utilisant les autres caractères standardisés.

Parmi ces derniers non-caractères figurent les points de code valides mais réservés aux demi-zones (privées ou non). Ces points de code ne peuvent pas être utilisés individuellement pour coder un caractère. Ils servent uniquement pour la forme de transformation universelle UTF-16 (et les schémas de codage correspondants) pour représenter sur deux codets (à 16 bits chacun) des points de code valides dans un des 16 plans complémentaires (certaines combinaisons de codets correspondent à des caractères valides de ces plans, standards ou privés, d'autres combinaisons peuvent ne représenter aucun caractère valide car elles correspondraient à des non-caractères de ces plans complémentaires, et sont donc interdites dans les textes conformes à la norme).

Les autres zones libres (non assignées à un bloc nommé standardisé, ou les points de code laissés libres et réservés dans les blocs nommés existants) sont réservées pour un usage ultérieur dans des versions futures d'Unicode et ISO/CEI 10646, mais sont valides. Tout système traitant des textes contenant ces points de code réservés doivent les accepter sans les filtrer. Unicode définit des propriétés par défaut pour les hypothétiques caractères correspondants, afin de préserver la compatibilité des systèmes (conformes à la norme Unicode) avec les futurs textes conformes qui les contiendraient. Aucune application conforme ne doit leur assigner un caractère ou une sémantique spéciale (les zones privées sont destinées à cet usage).

Références normatives

• (en) « Unicode – The World Standard for Text and Emoji » — page d’accueil du site officiel.
  • (en) « The Unicode Standard » — lien permanent vers la dernière version publiée de la norme Unicode.
    • (en) « Unicode Character Code Charts » — collection de documents PDF.
    • (fr) « Tableaux des caractères Unicode » — collection de documents PDF.
  • (en) « Unicode Technical Reports » — annexes normalisées, normes techniques et rapport techniques (dont certains pour d'anciennes versions d’Unicode).
    • (en) « UAX #41: Common References for UAXs » — liste officielle des références utilisées dans la norme Unicode.
    • (en) « UTS #10 : Unicode Collation Algorithm (UCA) » — algorithme d'ordonnancement normalisé Unicode (pour le tri, la reconnaissance ou la recherche de texte).
• (en) RFC 3629 : UTF-8, a transformation format of ISO 10646 — standard de l’IETF (novembre 2003) ; remplace RFC 2279 (obsolète).

Références informatives

• (fr) Traduction française officielle des normes ISO/CEI 10646 et Unicode.
• (fr) Unicode 5.0 en pratique, par Patrick Andries, paru chez Dunod (avril 2008) — ouvrage de référence.
• (en) RFC 1641 : Using Unicode with MIME — expérimental (juillet 1994)
• (en) RFC 2152 : UTF-7, A Mail-Safe Transformation Format of Unicode — expérimental (mai 1997) ; remplace RFC 1642 (obsolète)
• (en) RFC 2482 : Language Tagging in Unicode Plain Text — informatif (janvier 1999)
• (en) RFC 3718 : A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access — informatif (février 2004)
• (en) RFC 5891 : Internationalized Domain Names in Applications (IDNA): Protocol — standard proposé ; remplace RFC 3490 et RFC 3491 (obsolètes), met à jour RFC 3492 Punycode
• (en) Unicode — The Movie Tous les 109 242 caractères de Unicode 6.0 dans un seul film

Tables et données tierces de mise en œuvre ou d'utilisation

• (en) The Gallery of Unicode Fonts : inventaire de 1 239 fontes (août 2007) et des caractères qu'elles comprennent.
• (en) Unicode and Multilingual Support in HTML, Fonts, Web Browsers and Other Applications, le site d'Alan Wood recensant les différents blocs d'Unicode avec pages de tests, conseils et liens vers les ressources, polices, et utilitaires permettant de saisir et d'afficher les blocs en question avec les navigateurs Web ou dans d'autres logiciels.
• (en) (de) Decode Unicode, Wiki recensant et commentant tous les 98 884 caractères d'Unicode en images.
• (fr) CoeurLumiere.com, simple table des caractères Unicode de U+0000 à U+FFFF (attention, certains sont invalides en HTML et ne sont pas signalés).

Guides d'utilisation

• (en) Markus Kuhn, UTF-8 and Unicode FAQ
• (en) Comment utiliser Unicode sur les systèmes libres GNU/Linux ou compatibles.
• (fr) Chapitres 2, 3, et 4 du livre Fontes et codages.
• (fr) La saisie et l'échange de caractères phonétiques avec Unicode, à l'usage des novices.
• (fr) Exemple d'utilisation d'Unicode et tests.
• (fr) Vos applications Web en Unicode, (article et tutoriel sur la mise en pratique d'Unicode avec PHP et MySQL ainsi que l'implémentation côté client dans les documents XML, HTML et CSS)

Discussions et articles

• (fr) Unicode, écriture du monde ? (vol. 6 (2003) de la revue Document numérique, 364 pages). Intérêt : points de vue critiques (typographes, informaticiens, égyptologues, etc.) et entretien avec Ken Whistler, directeur technique du Consortium Unicode.
• (en) Otfried Cheong, UniHan (article sur les problèmes d'unification des sinogrammes avec UniHan dans Unicode)