Unicode (3).

GB 18030 

Il s’agit d’une transformation de l’Unicode qui n’est pas définie par le Consortium Unicode, mais par l’administration de normalisation en Chine, où son support est obligatoire dans les applications. Historiquement c’était un jeu de caractères codé, qui a été étendu pour supporter l’intégralité du répertoire UCS par une transformation algorithmique complétant une large table de mappage d’un code à l’autre.

Les polices de caractères Unicode 

Affirmer qu’Unicode code des caractères revient à affirmer qu’il attribue un numéro à des symboles abstraits, selon un principe de codage logique. Unicode ne code en revanche pas les représentations graphiques des caractères, les glyphes. Il n’y a donc pas une bijection entre la représentation du caractère et son numéro, puisque toutes les variantes graphiques de style sont unifiées.

De plus, contrairement à une police ASCII ou latin-1 classique, la sélection d’un glyphe par un code n’est pas unique et est souvent contextuelle, et peut aussi afficher le même glyphe pour des codes différents. 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). Ceci est autorisé et même hautement recommandé car les différentes formes de codage sont classées par Unicode comme « canoniquement équivalentes », ce qui signifie que deux formes de codage équivalentes devraient être traitées de façon identique.

De nombreux caractères composites sont dans ce cas et peuvent être codés de ces deux manières (ou plus, certains caractères composés pouvant être décomposés de plusieurs façons, notamment quand ils comportent plusieurs signes diacritiques). Le plus souvent, le caractère précomposé est préférable pour le codage du texte, si celui-ci existe (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). Toutefois, tous les caractères composites ne disposent pas d’un point de code unique pour leur forme précomposée.

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 (voir Variante contextuelle et Lettre conjointe). La sélection du glyphe correct à utiliser nécessite un traitement permettant de déterminer la forme contextuelle à sélectionner dans la police, alors même que toutes les formes contextuelles sont codées de façon identique en Unicode.

Pour ces raisons, la police Unicode doit être utilisée 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 (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 ». Enfin, il existe des contraintes techniques dans les formats de polices de caractère, qui les empêche de supporter la totalité du répertoire et, en pratique, il est en 2009 impossible de trouver une police de caractères unique supportant tout le répertoire.

Une police de caractères Unicode est donc seulement une police permettant d’afficher directement un texte codé selon toutes les formes autorisées par Unicode, et permettant de supporter un sous-ensemble cohérent adapté à une ou plusieurs langues pour supporter une ou plusieurs écritures. Aucune police de caractère Unicode ne peut « fonctionner » seule, et le support complet de l’écriture nécessite un support de celles-ci dans un moteur de rendu, capable de détecter les formes de codage équivalentes, rechercher les formes contextuelles dans le texte et sélectionner les différents glyphes d’une police codée avec Unicode, en s’aidant au besoin de tables de correspondances incluses dans la police elle-même.

Détails techniques 

Bibliothèques logicielles

La bibliothèque multi plate-forme ICU permet de manipuler des données unicodées. Un support d’Unicode spécifique à certaines plates-formes (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 :

Types compatibles avec Unicode dans les langages de programmation

Langage de programmation	Type pour un seul caractère	Type pour tout texte
C	char[4]a ou wchar_t[2]b	char[] ou wchar_t[]
C++	char[4]a ou wchar_t[2]a	char[] ou wchar_t[] ou std::string ou std::wstring
Java	char[2] ou intc	char[] ou String
Bibliothèque ICU (pour C/C++ ou Java)	UChar	UChar[] ou String, UnicodeString
JavaScript ou ECMAScript	chard	string
C# ou J#	char	string
Delphi	char[4]a ou widechar[2]	stringa ou widestring
Python		unicode

Notes 

1. ↑ ^{a, b, c, d et e} En UTF-8
2. ↑ 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 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.
3. ↑ De manière similaire au C et au C++, le langage Java dispose de type unitaire permettant de coder 16 bits, mais ne permettant pas 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 grâce au type natif int (qui est un entier défini sur 32 bits) et aux méthodes statiques de la classe standard Character (cependant un objet instancié de ce type Character ne permet pas, tout comme le type natif char, de stocker n’importe quel point de code).
4. ↑ JavaScript comporte diverses implémentations non normalisées dont certaines plus anciennes ne supportent pas plus de 16 bits par caractère, et parfois seulement 8 bits. Toutefois la norme ECMAScript de ce langage définit une classe utilitaire Character sur 32 bits (en fait basée sur la classe Number) devant supporter tous les points de code des 17 plans normalisés, tandis que les chaines de caractères utilise des caractères codés obligatoirement sur 16 bits (mais sans restriction renforçant l’appariement des unités de code UTF-16, les chaînes ECMAScript de type String n’étant pas restreintes au seul codage UTF-16 mais étant des vecteurs de constantes entières codées sur 16 bits sans restriction, afin d’assurer l’interopérabilité avec Java et d’autres langages qui eux non plus ne renforcent pas les restrictions de conformité UTF-16 dans leurs types natifs de données). 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 encore d’un faible support des expressions rationnelles par certains logiciels, même si des bibliothèques comme ICU et Java peuvent les supporter. Un tel support n’a pas encore été standardisé pour ECMAScript et n’est fourni qu’avec l’aide de librairies créées avec le langage ou des interfaces d’interopérabilité avec d’autres systèmes (notamment avec CORBA, COM) ou langages (notamment C++ et Java).

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.

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

Plan multilingue de base (PMB, 0000 à FFFF) 

Points de code		Nom officiel du bloc	Commentaires
Début	Fin
0000	007F	Latin de base	voir norme ISO 646, code ASCII
0080	009F	Non-utilisé	voir plage non-utilisé norme ISO 8859 et ISO 8859-1
00A0	00FF	Supplément Latin-1	voir norme ISO 8859, code ISO 8859-1
0100	017F	Latin étendu A
0180	024F	Latin étendu B
0250	02AF	Alphabet phonétique international (API)	Alphabet phonétique international
02B0	02FF	Lettres modificatives avec chasse
0300	036F	Diacritiques	voir Diacritique
0370	03FF	Grec et copte
0400	04FF	Cyrillique	voir Alphabet cyrillique
0500	052F	Supplément cyrillique	voir Alphabet cyrillique
0530	058F	Arménien	voir langue Arménien
0590	05FF	Hébreu	voir Alphabet hébreu
0600	06FF	Arabe	voir alphabet arabe
0700	074F	Syriaque	voir langue Syriaque
0780	07BF	Thâna
0900	097F	Dévanâgarî
0980	09FF	Bengali	voir langue indienne Bengalî
0A00	0A7F	Gourmoukhî
0A80	0AFF	Goudjerate
0B00	0B7F	Oriya	voir langue indienne Oriya
0B80	0BFF	Tamoul	voir langue indienne Tamoul
0C00	0C7F	Télougou	voir langue indienne Télougou
0C80	0CFF	Kannara	voir langue indienne Kannara
0D00	0D7F	Malayalam	voir langue indienne Malayalam
0D80	0DFF	Singhalais	voir langue indo-européenne Cingalais
0E00	0E7F	Thai	voir langue asiatique Thai
0E80	0EFF	Lao	voir langue asiatique Lao
0F00	0FFF	Tibétain	voir langue asiatique Tibétain
1000	109F	Birman	voir langue asiatique Birman
10A0	10FF	Géorgien	voir langue Géorgien
1100	11FF	Jamos hangûl
1200	137F	Éthiopien	voir Alphabet éthiopien
13A0	13FF	Chérokî
1400	167F	Syllabaires autochtones canadiens unifiés
1680	169F	Ogam	voir Écriture oghamique
16A0	16FF	Runes	voir Alphabet runique
1700	171F	Tagalog	ou tagal, voir langue Tagalog
1720	173F	Hanounóo
1740	175F	Bouhide
1760	177F	Tagbanoua
1780	17FF	Khmer	voir langue Khmer
1800	18AF	Mongol	voir langue mongol (Монгол хэл, mongγol kele)
1900	194F	Limbou
1950	197F	Taï-le
19E0	19FF	Symboles khmers	voir langue Khmer
1D00	1D7F	Supplément phonétique
1E00	1EFF	Latin étendu additionnel
1F00	1FFF	Grec étendu
2000	206F	Ponctuation générale	voir aussi ponctuation
2070	209F	Exposants et indices
20A0	20CF	Symboles monétaires
20D0	20FF	Signes combinatoires pour symboles
2100	214F	Symboles de type lettre
2150	218F	Formes numérales
2190	21FF	Flèches
2200	22FF	Opérateurs mathématiques	voir Opérateurs mathématiques
2300	23FF	Signes techniques divers	2336 à 237A = symboles APL
2400	243F	Pictogrammes de commande
2440	245F	Reconnaissance optique de caractères	voir Reconnaissance optique de caractères
2460	24FF	Alphanumériques cerclés
2500	257F	Filets
2580	259F	Pavés
25A0	25FF	Formes géométriques
2600	26FF	Symboles divers
2700	27BF	Casseau
27C0	27EF	Divers symboles mathématiques - A
27F0	27FF	Supplément A de flèches
2800	28FF	Combinaisons Braille	voir Braille
2900	297F	Supplément B de flèches
2980	29FF	Divers symboles mathématiques-B
2A00	2AFF	Opérateurs mathématiques supplémentaires
2B00	2BFF	Divers symboles et flèches
2D30	2D6F	Alphabet Tifinagh et néo-Tifinagh	voir Alphabet berbère et Tifinagh (langue berbère)
2E80	2EFF	Formes supplémentaires des clés CJC	voir Chinois, japonais et coréen (CJC)
2F00	2FDF	Clés chinoises (K'ang-hsi ou Kangxi)	voir Dictionnaire de caractères de Kangxi
2FF0	2FFF	Description idéophonographique
3000	303F	Symboles et ponctuation CJC	voir ponctuation et Chinois, japonais et coréen (CJC)
3040	309F	Hiragana	voir Hiragana (langue japonaise)
30A0	30FF	Katakana	voir Katakana (langue japonaise)
3100	312F	Bopomofo	voir Bopomofo (notation taïwanaise et chinoise)
3130	318F	Jamos de compatibilité hangûls
3190	319F	Kanboun
31A0	31BF	Bopomofo étendu	voir Bopomofo (notation taïwanaise et chinoise)
31F0	31FF	Extension phonétique katakana	voir Katakana (langue japonaise)
3200	32FF	Lettres et mois CJC cerclés	voir Chinois, japonais et coréen (CJC)
3300	33FF	Compatibilité CJC	voir Chinois, japonais et coréen (CJC) (unités de mesure)
3400	4DB5	Supplément A aux idéophonogrammes unifiés CJC	voir Chinois, japonais et coréen (CJC)
4DC0	4DFF	Hexagrammes du Classique des mutations ou Yi Jing	voir Yi Jing, Hexagramme
4E00	9FA5	Idéophonogrammes unifiés CJC	voir Chinois, japonais et coréen (CJC)
A000	A48F	Syllabaire yi des Monts frais
A490	A4CF	Clés yi
AC00	D7A3	Hangûl
D800	DB7F	Demi-zone haute	points de code invalides isolément D800 à D83F : codets hauts utilisés en UTF-16 pour les points de code du plan multilingue complémentaire D840 à D87F : codets hauts utilisés en UTF-16 pour les points de code du plan idéographique complémentaire D880 à DB3F : codets hauts utilisés en UTF-16 pour les points de code des plans complémentaires réservés D840 à D87F : codets hauts utilisés en UTF-16 pour les points de code du plan complémentaire réservé
☒DB80	DBFF	Partie à usage privé de la demi-zone haute	points de code invalides isolément DB80 à DBBF : codets hauts utilisés en UTF-16 pour les points de code de la zone supplémentaire A à usage privé DBC0 à DBFF : codets hauts utilisés en UTF-16 pour les points de code de la zone supplémentaire B à usage privé
DC00	DFFF	Demi-zone basse	points de code invalides isolément DC80 à DFFD : codets bas utilisés en UTF-16 pour des points de code assignés aux caractères valides ou réservés des plans complémentaires (assignés, réservés ou à usage privé) DFFE à DFFF : codets bas pouvant être utilisés en UTF-16 pour la représentation de points de code assignés aux non-caractères en fin de chaque plan, lorsque le codet haut est le dernier assigné dans la demi-zone haute pour chaque plan complémentaire (assigné, réservé ou à usage privé)
☒E000	F8FF	Zone à usage privé
F900	FAFF	Idéogrammes de compatibilité CJC	voir Chinois, japonais et coréen (CJC)
FB00	FB4F	Formes de présentation alphabétiques
FB50	FDFF	Formes A de présentation arabes	voir alphabet arabe
FDD0	FDEF		non-caractères
FE00	FE0F	Sélecteurs de variante
FE20	FE2F	Demi-signes combinatoires
FE30	FE4F	Formes de compatibilité CJC	voir Chinois, japonais et coréen (CJC)
FE50	FE6F	Petites variantes de forme
FE70	FEFF	Formes B de présentation arabes
FF00	FFEF	Formes de demi et pleine chasse
FFF0	FFFD	Caractères spéciaux
FFFE	FFFF		non-caractères