Unicode

Unicode est une norme informatique, développée par le Consortium Unicode, qui vise à donner à tout caractère de n'importe quel système d'écriture de langue un nom et un identifiant numérique, et ce de manière unifiée, quelle que soit la plate-forme informatique ou le logiciel.

Aujourd’hui totalement compatible avec ISO/CEI 10646, la norme Unicode lui ajoute un modèle de représentation et de traitement de textes complets, en conférant à chaque caractère un jeu de propriétés normalisées ou informatives, en décrivant avec précision les relations sémantiques qui peuvent exister entre plusieurs caractères successifs d’un texte, et en normalisant des algorithmes de traitement qui préservent au maximum la sémantique des textes transformés, tout en étendant l’interopérabilité de la représentation de ces textes sur des systèmes hétérogènes.

On peut aujourd’hui dire que la norme Unicode inclut intégralement la norme ISO/CEI 10646 en tant que sous-ensemble, puisque cette dernière ne normalise que les caractères individuels en leur assignant un nom et un numéro normatif et une description informative très limitée, mais aucun traitement ni aucune spécification ou recommandation pour leur emploi dans l’écriture de langues réelles, ce que seule la norme Unicode définit précisément. Toutefois, la norme ISO/CEI 10646 confère à Unicode le statut de norme internationale approuvée pour le codage des textes ; Unicode est également une norme de facto pour le traitement de ces textes, et sert aujourd’hui de base à de nombreuses autres normes.

But

Unicode, dont la première publication remonte à 1991, a été développée dans le but de remplacer l'utilisation de pages de code nationales.

Ces pages de code présentaient en effet quelques problèmes. Par exemple lorsqu'était prévu un caractère « signe monétaire », le même texte autorisant aux États-Unis une dépense en dollars pouvait une fois transmis par courrier électronique au Royaume-Uni autoriser la même dépense en livres sterling, sans que quoi que ce soit ait été modifié au texte !

Dans la pratique, tous les systèmes d'écriture ne sont pas encore présents, car un travail de recherche documentaire auprès de spécialistes peut encore s'avérer nécessaire pour des caractères rares ou des systèmes peu connus (parce que disparus, par exemple).

Cependant, tous les systèmes les plus utilisés dans le monde sont représentés, ainsi que des règles sur la sémantique des caractères, leurs compositions et la manière de combiner ces différents systèmes. — Par exemple, comment insérer un système d'écriture de droite à gauche dans un système d'écriture de gauche à droite (Texte bi-directionnel).

Normes et versions

Le travail sur Unicode est parallèle et synchronisé avec celui sur la norme ISO/CEI 10646 dont les buts sont les mêmes. L’ISO/CEI 10646, une norme internationale publiée en français et en anglais, ne précise cependant ni les règles de composition de caractères, ni les propriétés sémantiques des caractères.

Unicode aborde cependant la problématique de la casse, du classement alphabétique, et de la combinaison d’accents et de caractères. Depuis la version 1.1 d’Unicode et dans toutes les versions suivantes, les caractères ont les mêmes identifiants que ceux de la norme ISO/CEI 10646 : les répertoires sont maintenus parallèlement, à l’identique lors de leur normalisation définitive, les deux normes étant mises à jour simultanément. Les deux normes Unicode (depuis la version 1.1) et ISO/CEI 10646 assurent une compatibilité ascendante totale : tout texte conforme à une version antérieure doit rester conforme dans les versions ultérieures.

Ainsi les caractères de la version 3.0 d’Unicode sont ceux de la norme ISO/CEI 10646:2000. La version 3.2 d’Unicode classait 95 221 caractères, symboles et directives.

L’actuelle version 4.1.0 d’Unicode, mise à jour en novembre 2005, contient :

• 137 468 caractères à usage privé (assignés dans toutes les version d’Unicode et suffisants pour tous les usages) ;
• plus de 97 755 lettres ou syllabes, chiffres ou nombres, symboles divers, signes diacritiques et signes de ponctuation, avec parmi eux :
  • plus de 70 207 caractères idéographiques, et
  • parmi eux, 11 172 syllabes hangûles précomposées ; ainsi que
• 8 258 points de codes réservés de façon permanente interdits pour le codage de texte (assignés dans toutes les version d’Unicode) ; et
• plusieurs centaines de caractères de contrôle ou modificateurs spéciaux ;

soit un total de près de 245 000 points de codes assignés dans un espace pouvant contenir 1 114 112 codes différents.

Quelques problèmes semblent cependant exister, pour le codage des caractères chinois, à cause de l’unification des jeux idéographiques utilisés dans différentes langues, avec une calligraphie légèrement différente et parfois signifiante, mais ils sont en cours de résolution par Unicode qui a défini des sélecteurs de variantes et ouvert un registre de séquences normalisées qui les utilise.

Les couches d’Unicode

Unicode est défini suivant un modèle en couches (Note technique Unicode #17). Les autres normes ne faisaient typiquement pas de distinction entre le jeu de caractères et la représentation physique. Les couches sont ici présentées en partant de la plus haute (la plus éloignée de la machine).

Jeu de caractères abstraits (Abstract Character Repertoire)

La couche la plus élevée est la définition du jeu de caractères. Par exemple, Latin-1 a un jeu de 256 caractères et Unicode normalise actuellement plus de 120 000 caractères. En outre, Unicode leur donne des noms. Dresser la liste des caractères et leur donner des noms est donc la première couche d’Unicode.

Par exemple, le caractère Ç est nommé "Lettre majuscule latine c cédille".

Cette définition est totalement identique avec celle de l’ISO/CEI 10646, qui approuve toute extension du répertoire. Il faut noter qu’Unicode ne reprend dans le texte de sa norme que les noms normatifs en Anglais, mais que la norme ISO/CEI 10646 est publiée en deux langues également normatives. Aussi les noms en anglais et en français sont tous deux normalisés.

Dans les faits, toute extension du répertoire se fait aujourd’hui conjointement entre le Groupe de travail WG2 de l’ISO/CEI 10646 (dont les membres votants sont uniquement des autorités de normalisation nationales de tous les pays du monde, 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éret public, ou même un gouvernement, qui a adhéré et paye une redevance annuelle leur permettant de participer à ces décisions).

Jeu de caractères codés (Coded Character Set)

Ici, on ajoute à la table précédente un index numérique. Notons bien qu’il ne s’agit pas d’une représentation en mémoire, juste d’un nombre.

Ce nombre, le point de code, est noté U+xxxx où xxxx est en hexadécimal, et comporte 4 chiffres pour tous les points de codage du premier plan de base multilingue (donc entre U+0000 et U+FFFF), 5 chiffres pour les 15 plans suivants (entre U+10000 et U+FFFFF), ou 6 chiffres pour le dernier plan (entre U+100000 et U+10FFFF).

Ainsi, le caractère nommé "Lettre majuscule latine c cédille" a un index de U+00C7.

Il faut noter que tous les points de code entre U+0000 et U+10FFFF sont valides, même si certains sont réservés et pas encore assignés à des caractères, ou si certains points de code sont assignés à des non-caractères (par exemple U+FFFE ou U+FFFF) dont l’usage est interdit dans un texte, ou sont réservés pour permettre l’encodage de n’importe quel texte conforme avec une des formes de transformation standard Unicode (voir UTF-16, plus bas).

On notera également qu’Unicode (ou ISO/CEI 10646) a 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 dédié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 normalisation du codage, c’est-à-dire l’assignation 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 équivalent).

On peut noter que si le répertoire des caractères est extensible, il ne l’est que dans les limites permises par le codage des points de code assignables aux caractères codés. Une grande majorité des points de code possibles n’est pas assignée à un caractère particulier, mais peut le devenir à tout moment.

Aussi ces points de code encore libres ne sont pas considérés comme invalides mais représentent bien des caractères abstraits (non encore spécifiés, et temporairement réservés). 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 normalisé 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/IEC 10646 et d’Unicode (depuis la version 1.1 uniquement).

Forme codée en mémoire (Character Encoding Form)

Cette fois, nous arrivons à une représentation en mémoire : cette couche spécifie quelles unités de stockage (code units), octets ou bien mots de 16 - seizets - ou de 32 bits, vont représenter un caractère ou plus exactementun point de code.

Mécanisme de sérialisation des caractères (Character Encoding Scheme)

Cette couche s’occupe de sérialiser les unités de stockage définies par la couche du dessus. C’est ici que se traite l’opposition entre gros boutiens (octet le plus significatif d’abord) et petits boutiens (octet le moins significatif d’abord).

C’est également ici qu’on spécifie la marque de boutianité (BOM, pour Byte Order Mark) qui permet d’indiquer en début de fichier 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)

Ici, interviennent optionnellement les mécanismes de compression ou de chiffrement.

Il peut aussi y avoir un surencodage comme pour le LDAP qui spécifie que les chaînes Unicode doivent être encodées en UTF-8 et surencodées en Base64.

La limite de l’octet

Contrairement aux normes précédentes, Unicode sépare la définition du jeu de caractères (la liste des caractères, leur nom et leur index, le point de code) de celle de l’encodage. Ainsi, on ne peut donc pas parler de la taille d’un caractère Unicode, car elle dépend de l’encodage choisi.

Là où l’ASCII utilisait jadis 7 bits et ISO 8859-1 8 bits (comme la plupart des pages de codes nationales), Unicode, qui rassemble les caractères de chaque page de code, avait besoin d’utiliser plus que les 8 bits d’un octet. La limite fut dans un premier temps fixée à 16 bits pour les premières versions d’Unicode, et à 32 bits pour les premières versions de la norme ISO/IEC 10646.

La limite actuelle est désormais placée entre 20 et 21 bits par point de code assigné aux caractères normalisés dans les deux normes, désormais mutuellement compatibles :

• Le groupe de travail international de l’ISO normalise l’assignation des points de code aux caractères, leur nom officiel et réserve les blocs de points de code utilisés par chaque écriture ou groupe d’écritures. Il documente aussi une représentation graphique possible (indicative) pour chaque caractère (cette représentation graphique étant si possible non ambiguë grace au placement des caractères normalisés dans les blocs de code appropriés pour un nombre limité d’écritures).
• Le groupe de travail du Consortium Unicode normalise plus précisément (dans la norme Unicode) leur sémantique pour les traitements automatisés grace aux tables de propriétés des caractères, et la mise au point d’algorithmes standards utilisant ces propriétés.
• Les deux organismes de normalisation collaborent pour synchroniser en permanence leur répertoire normalisé dans des versions officielles référencées mutuellement, et travaillent ensemble pour les amendements (les versions ne devenant officielles qu’une fois que les deux organismes ont chacun approuvé et complètement définis les additions de nouveaux caractères).
• En pratique, pour la plupart des développeurs d’applications, la norme ISO 10646 apparait comme un sous-ensemble de la norme Unicode plus complète, mais elle dispose des mêmes points de code pour exactement le même jeu de caractères que ceux de la norme Unicode (c’est pourquoi la norme Unicode est plus connue car plus appropriée pour les traitements informatisés, mais aussi la norme Unicode est plus accessible car consultable gratuitement sur Internet).

UTF, Universal Transformation Format

Unicode et ISO/IEC 10646 acceptent plusieurs formes de transformation universelle pour représenter un point de code valide. Citons :

• UTF-8 ;
• UTF-16 ;
• UTF-32.

Le nombre après UTF représente le nombre minimal de bits des codets avec lequels un point de code valide est représenté.

Ces transformations ont été initialement créées pour la représentation interne et les schémas de codage des points de code de la norme ISO 10646, qui au départ pouvait définir des points de code sur 31 bits. Depuis, la norme ISO/IEC10646 a été amendée, afin que les trois formes soient totalement compatibles entre elles et permettent de coder tous les points de code (car UTF-16 ne permet de représenter que les points de code des 17 premiers plans).

Unicode a normalisé également de façon très stricte ces trois formes de transformation de tous les points de code valides (U+0000 à U+D7FF et U+E000 à U+10FFFF) et uniquement eux, que ce soit pour représenter du texte sous forme de suites de points de codes, ou des points de code assignés aux caractères valides, ou réservés, ou assignés à des non-caractères. Il faut noter que les points de code assignés aux demi-zones (U+D800 à U+DFFF), utilisés uniquement en UTF-16, sont invalides isolément puisqu’il servent à la représentation, par un couple de 2 codets de 16 bits, des points de code des 16 plans supplémentaires.

UTF-8

L’UTF-8, spécifié dans le RFC 2279, 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. Mais cela ralentit nettement les opérations où interviennent des extractions de sous-chaînes, 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 (langage) peuvent souvent fonctionner sans modification.

Initialement, l’UTF-8 pouvait coder n’importe quel point de code entre U+0000 et U+8FFFFFFF (donc jusqu’à 31 bits). Cet usage est obsolète et la norme ISO/IEC 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/IEC10646 pour ne plus accepter que la représentation la plus courte de chaque point de code.

Son avantage sur l’UTF-16 est qu’il n’existe qu’un seul schéma de codage possible pour la transmission de séquences d’octets dans un réseau de systèmes hétérogènes. La plupart des protocoles d’échange normalisés aujourd’hui utilisent cette transformation car elle est indépendante de l’ordonnancement des octets composant un entier plus long.

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-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 défaut est le codage de longueur très variable (1 octet pour les points de code assignés aux caractères ASCII/ISO646, 2 à 4 octets pour les autres points de code), même s’il est possible de déterminer le début du codage d’un point de code à partir d’une position aléatoire d’un texte transformé en UTF-8 (en effectuant au plus 3 lectures supplémentaires des codets qui précèdent). Aussi, cette transformation est rarement utilisée pour le traitement interne des textes, et on lui préfère souvent l’UTF-16, parfois l’UTF-32.

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.

Toutefois les points de code des 16 plans supplémentaires nécessitent une transformation sur deux codets :

• le premier codet pris dans la demi-zone haute (0xD800 à 0xDBFF) permet de représenter les 10 bits de poids fort de la différence entre le point de code supplémentaire et le premier point de code hors du plan multilingue de base ;
• le second codet pris dans la demi-zone basse (0xDC00 à 0xDFFF) permet de représenter les 10 bits de poids faible du point de code supplémentaire.

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).

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 ambiguité 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 encodé avec la représentation du point de code valide U+FEFF (assigné au caractère « espace insécable de largeur nulle »), puisque le point de code U+FFFE valide est un non-caractère, interdit dans les textes conformes à Unicode et ISO/IEC10646.

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.

C’est notamment l’encodage qu’utilise la plateforme Java en interne, ainsi que Windows pour ses APIs compatibles Unicode (avec le type "WCHAR"). Toutefois la plateforme Java utilise aussi un format compact spécifique supplémentaire codé sur 8 bits (proche de UTF-8, mais distinct puisque le point de code U+0000 y est représenté par une séquence invalide en UTF-8 de deux octets non nuls) pour certains échanges natifs avec les bibliothèques C de la plateforme supportée ou dans le format interne des fichiers de classes compilées, puisque ce format alternatif (mais portable) ne dépend pas non plus de l’ordonnancement interne des octets composant un entier de plus de 8 bits.

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).

L’avantage de cette transformation normalisée est que tous les codets ont la même taille, et donc qu’il n’est pas nécessaire de lire des codets supplémentaires pour déterminer le début de la représentation d’un point de code. De plus la lecture ou l’écriture

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 physique, 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 normalisé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 normalisé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 à 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 couteuse en terme 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 (qui restent rares 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+D7FFF 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 normalisé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 normalisées sont bijectivement compatibles.

GB18030

Il s'agit d'un encodage de l'Unicode qui n'est pas défini par le consortium unicode, mais par l'Administration de Standardisation Administration de Chine populaire.

Les polices de caractères Unicode

Avant de parler de police Unicode, il faut bien comprendre un principe essentiel : dire qu'Unicode code des caractères revient à dire qu'il attribue un numéro à des symboles. Unicode ne code en revanche pas les descriptions des caractères, les glyphes, c'est-à-dire la représentation graphique du caractère. Il n'y a donc pas une bijection entre la représentation du caractère et son numéro comme c'est le cas dans une police ASCII ou latin-1 classique.

Ainsi, le caractère français é peut-il être décrit de deux manières : soit en utilisant directement le numéro correspondant au é, soit en faisant suivre le numéro du 'e' par celui de l'accent aigu sans chasse. Quelle que soit l'option choisie le même glyphe sera affiché. On dira du premier caractère qu'il est précomposé, du second que c'est une composition (deux caractères forment un seul glyphe composé des deux). De nombreux glyphes sont dans ce cas et peuvent être codés de ces deux manières. Le plus souvent, le glyphe précomposé est préférable (c'est le cas pour le grec polytonique, par exemple, lequel, codé en décomposition, peut ne pas être satisfaisant graphiquement : selon les polices de caractères, les différents constituants du glyphe étant parfois mal disposés et peu lisibles).

De même, certains systèmes d'écriture, comme la devânagarî ou les caractères arabes, nécessitent un traitement complexe des ligatures : les graphèmes changent en effet de forme en fonction de leur position et/ou par rapport à leurs voisines (cf. Variante contextuelle et Lettre conjointe).

On comprend donc que le terme de police Unicode doit être utilisé très prudemment. Avoir une police qui représente un certain nombre ou toutes les représentations graphiques que l'on peut obtenir avec Unicode n'est pas suffisant, il faut en plus que le système d'affichage possède les mécanismes de représentation idoines (ce que l'on nomme le moteur de rendu) capable de gérer les ligatures, variantes contextuelles et formes conjointes de certaines écritures. Au contraire, une police qui ne représente que certains caractères mais qui sait comment les afficher mérite mieux le terme de police Unicode.

Le moteur de rendu doit comporter dans certains cas des informations sur les coupures de lettres. Ainsi la lettre allemande s/z, lorsqu'elle se trouve sur une coupure, se traduit en deux s : un avant et un après la coupure.

Détails techniques

Bibliothèques logicielles

La bibliothèque multiplateforme ICU permet de manipuler des données unicodées. Un support d'Unicode spécifique à certaines plateformes (non compatible quant au code-source) est également fourni par les systèmes modernes (Java, MFC, GNU/Linux).

Les types à utiliser pour stocker des variables Unicode, sont les suivants:

Notes:

• (0) En UTF-8
• (1) On notera toutefois que le type wchar_t du langage C ne permet pas toujours de coder tous les caractères Unicode, car la norme de ce langage ne prévoit pas de nombre minimum suffisante pour ce type standard. Cependant de nombreux compilateurs du langage définissent wchar_t sur 32 bits (voire 64 bits sur les environnements manipulant les entiers standards sur 64 bits), ce qui suffit pour stocker n’importe quel point de code Unicode normalisé. Mais d’autres compilateurs représentent wchar_t sur 16 bits (notamment sous Windows en environnement 16 ou 32 bits), voire même sur 8 bits seulement (notamment dans les environnements embarqués ne disposant pas d’un système d’exploitation d’usage général) car wchar_t peut utiliser la même représentation que le type char qui compte un minimum de 8 bits.
• (2) De même, le langage Java ne dispose pas de type unitaire permettant de coder un seul point de code d’une valeur quelconque (le type natif char est un entier positif sur 16 bits seulement). Pour manipuler les caractères normalisés hors du premier plan, il faut utiliser une paire de codets, chacun contenant une valeur égale aux deux codets définis par la forme UTF-16. Aussi les types d’objets String ou char[2] sont les plus appropriés pour représenter un caractère Unicode. Depuis Java 1.4.1, la bibliothèque standard fournit un support complet d’Unicode grace au type natif int (qui est un entier défini sur 32 bits) et aux méthodes statiques de la classe standard Char (cependant un objet instancié de ce type Char ne permet pas, tout comme le type natif char, de stocker n’importe quel point de code).
• (3) JavaScript comporte diverses implémentations non normalisées dont certaines plus anciennes ne supportent pas plus de 16 bits par caractère. Toutefois la norme ECMAScript de ce langage définit un type char sur 32 bits devant supporter tous les points de code des 17 plans normalisés. Ces deux langages ne supportent pas de typage explicite des variables, le type étant défini dynamiquement par les valeurs qu’on leur assigne (aussi, plusieurs représentations internes sont possibles, leurs différences étant normalement transparentes pour le programmeur).

Unicode souffre toutefois d'un faible support des expressions rationnelles par certains logiciels, même si des bibliothèques comme ICU et Java semblent les supporter.

Partitionnement

Le partitionnement à jour peut être trouvé sur le site officiel d'Unicode. Cependant, vu le rôle important d'Unicode, (ISO 10646) on décrira ici les principaux blocs de caractères. Les noms français sont les noms officiels de l'ISO/CEI 10646, la norme internationale bilingue qui reprend les mêmes caractères qu'Unicode. Ils sont aussi officiels que les noms anglais.

Il faut noter que l'ancienne norme Unicode 1.0 est obsolète et incompatible avec la norme ISO 10646 et la norme Unicode 1.1 et toutes ses versions ultérieures ; la principale incompatibilité est celle des blocs de caractères Hangul utilisés pour l'écriture de la langue coréenne qui ont changé de position et dont les anciens points de code ont depuis été assignés à d'autres blocs. La table ci-dessous est compatible avec ISO 10646 (toutes versions) et Unicode 1.1 (ou ultérieur)

Note : La casse des noms de bloc n'est pas normative. « Latin de base » est donc équivalent à « LATIN DE BASE ».

Les zones à usage privé indiquées par le symbole ☒ 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 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 listés sont des points de code valides, mais ils ne sont pas (et ne seront jamais) assignés à des caractères normalisé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 normalisées (dont UTF-8, UTF-16, UTF-32) les schémas d'encodage correspondants, et les autres encodages normalisés compatibles avec Unicode et ISO 10646 (BOCU-1, SCSU, différentes versions de la norme chinoise GB18030, 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 normalisé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 d'encodage correspondants) pour représenter sur deux codets (à 16 bits chacun) des points de code valides dans un des 16 plans supplé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 supplémentaires, et sont donc interdites dans les textes conformes à la norme).

Les autres zones libres (non assignées à un bloc nommé normalisé, ou les points de code laissés libres et réservés dans les blocs nommés existants) sont réservés pour un usage ultérieur dans des versions futures d'Unicode et ISO 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).

Voir aussi

Liens internes

• Aide:Unicode, Aide:Caractères spéciaux,
• Table des caractères Unicode
• ISO/CEI 10646
• ISO 646, ASCII
• EBCDIC
• Caractères asiatiques
• Caractères APL/APL2 en Unicode
• DejaVu

<div style="clear:both;" />

Liens externes

Références normatives

• (en) Page d'accueil du consortium Unicode.
• (fr) Traduction française officielle de l’ISO/CEI 10646 et Unicode.
• (fr) Tables de caractères Unicode annotées avec les équivalences.
• (en) Ordonnancement Unicode normalisé (pour le classement ou le tri).
• (en) RFC 3718, RFC 3492, RFC 2482, RFC 2044, RFC 1642, RFC 1641.

Références non officielles

• (en) (de) DecodeUnicode - Unicode WIKI, chaque charactère du plan basique multilingue (BMP) d’Unicode avec 50 000 images GIF dans trois tailles.
• (en) Site recensant les différents blocs d’Unicode avec pages de tests, conseils et liens vers les polices permettant d'afficher les blocs en question.
• (fr) Table des caractères Unicode de 1 à 65535.
• (fr) Chapitres 2, 3, et 4 du livre Fontes et codages.
• (fr) Présentation du codage de caractères phonétiques à l'aide d'Unicode, à l'usage des novices.

Utilisation d’Unicode

• (fr) Exemple d’utilisation d’Unicode et tests.
• (en) (fr) Comment utiliser Unicode sur les systèmes libres GNU/Linux ou compatibles.
• (en) Une liste des logiciels libres supportant mal l'Unicode

Utilitaires pour le support d’Unicode

• (fr) Graticiel BabelMap, visualisation et recherche des caractères des polices Unicodes, de leurs propriétés et de leurs codages UTF-8, UTF-16, UTF-32.
• (fr) The Unicode Sliderule, outil Internet de saisie de caractères Unicode.

Articles et discussions

• (en) UTF-8 and Unicode FAQ de Markus Kuhn, article très complet.
• (en) Article “UniHan”, par Otfried Cheong sur les problèmes d’unification des sinogrammes avec UniHan dans Unicode.

Portail de l'informatique – Accédez aux articles de Wikipédia concernant l’informatique.

Portail de l'écriture – Accédez aux articles de Wikipédia concernant les écritures et les alphabets.

{{{{{3}}}}}

Portail de l'informatique – Accédez aux articles de Wikipédia concernant l’informatique.

Portail de l'écriture – Accédez aux articles de Wikipédia concernant les écritures et les alphabets.

<span class="AdQ" id="ru" style="display:none;" />

Catégorie 

Rechercher

Rechercher