Unicode

ÔĽŅ
Unicode

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

Totalement compatible avec le jeu universel de caractères (JUC) de l'ISO/CEI 10646, la norme Unicode l'étend en lui ajoutant 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.

Le standard Unicode est constitué d'un répertoire de plus de 109.000 caractères couvrant 93 écritures, d'un ensemble de tableaux de codes pour référence visuelle, d'une méthode de codage et de plusieurs codages de caractères standard, d'une énumération des propriétés de caractère (lettres majuscules, minuscules, symboles, ponctuation, etc.) d'un ensemble de fichiers de référence des données informatiques, et d'un certain nombre d'éléments liés, tels que des règles de normalisation, de décomposition, de tri, de rendu et d'ordre d'affichage bidirectionnel (pour l'affichage correct de texte contenant contenant à la fois des caractères d'écritures droite à gauche, comme l'arabe et l'hébreu, et de gauche à droite). En 2011, la révision la plus récente importante de l'Unicode est Unicode 6.0, la première version à n'être publiée que sous forme électronique.

En pratique, Unicode reprend int√©gralement la norme ISO/CEI 10646, puisque cette derni√®re ne normalise que les caract√®res individuels en leur assignant un nom et un num√©ro normatif (appel√© position de code) 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. L'ISO/CEI 10646 fait normativement r√©f√©rence √† certaines partie du standard Unicode (notamment l'algorithme bidirectionnel et les propri√©t√©s des caract√®res) ; Unicode est √©galement une norme de facto pour le traitement du texte et sert de base √† de nombreuses autres normes.

Sommaire

But

Tables Unicode (plan 0)
0000 ‚Äď 0FFF   8000 ‚Äď 8FFF
1000 ‚Äď 1FFF 9000 ‚Äď 9FFF
2000 ‚Äď 2FFF A000 ‚Äď AFFF
3000 ‚Äď 3FFF B000 ‚Äď BFFF
4000 ‚Äď 4FFF C000 ‚Äď CFFF
5000 ‚Äď 5FFF D000 ‚Äď DFFF
6000 ‚Äď 6FFF E000 ‚Äď EFFF
7000 ‚Äď 7FFF F000 ‚Äď FFFF
Autres plans Unicode
0000 ‚Äď FFFF : plan 0 (BMP)
10000 ‚Äď 1FFFF : plan 1 (SMP)
20000 ‚Äď 2FFFF : plan 2 (SIP)
30000 ‚Äď DFFFF : plans 3‚Äď13 (r√©serv√©s)
E0000 ‚Äď EFFFF : plan 14 (SSP)
F0000 ‚Äď FFFFF : plan 15 (priv√© - A)
100000 ‚Äď 10FFFF : plan 16 (priv√© - B)

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 d'écriture peu connus (parce que disparus, par exemple).

Cependant, les √©critures les plus utilis√©es dans le monde sont repr√©sent√©es, 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 presque 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.

La version 4.1 d‚ÄôUnicode, mise √† jour en novembre 2005, contient :

  • 137 468 caract√®res √† usage priv√© (assign√©s dans toutes les versions 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 positions de codes r√©serv√©es de fa√ßon permanente, interdites pour le codage de texte (assign√©es dans toutes les versions d‚ÄôUnicode) ; et
  • plusieurs centaines de caract√®res de contr√īle ou modificateurs sp√©ciaux ;

soit un total de pr√®s de 245 000 positions de codes assign√©es 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.

La version 5.0 a √©t√© publi√©e en juillet 2006, la version 5.2 en octobre 2009 et la version 6.0 en f√©vrier 2011.

Les couches d’Unicode

Unicode est défini suivant un modèle en couches (Note technique Unicode #17[1]). 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).

Répertoire des 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 pr√®s de 110 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 à 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.

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 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 associé à chaque caractère. Notons bien qu’il ne s’agit pas d’une représentation en mémoire, juste d’un nombre entier, appelé position de code. L'espace de codage de ces nombres est divisé en 17 zones de 65 536 points de codes. Ces zones sont appelées plans.

La position de code est not√©e U+xxxx o√Ļ xxxx est en hexad√©cimal, et comporte 4 √† 6 chiffres :

  • 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 un index de U+00C7. Il appartient au premier plan.

En principe toutes les positions de code entre U+0000 et U+10FFFF sont disponibles, mais certains intervalles sont perpétuellement réservés à des usages particulier, notamment une zone d'indirection exclue pour permettre le codage UTF-16 (cf. infra), les zones à usage privé et quelques régions (par exemple U+FFFE ou U+FFFF) contenant des non-caractères dont l'usage est interdit dans un échange de données conforme. Les autres positions de code sont soit déjà assignées à des caractères, soit réservées pour normalisation future.

Zone √† usage priv√© : Unicode a assign√© de nombreuses positions 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 positions 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’une position de code unique (même si pour certaines langues ou pour Unicode certains caractères sont considérés comme équivalents).

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. Une grande majorit√© des position de code possibles n‚Äôest pas assign√©e √† un caract√®re particulier, mais peut le devenir √† tout moment.

Aussi ces positions 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/CEI 10646 et d‚ÄôUnicode (depuis la version 1.1 uniquement).

Formalisme de codage des caractères (Character Encoding Form)

Cette fois, nous arrivons √† une repr√©sentation physique (en m√©moire, sur disque, etc.) : cette couche sp√©cifie quelles unit√©s de codage (code units), octets ou bien mots de 16 - seizets - ou de 32 bits, vont repr√©senter un caract√®re ou plus exactement une position de code.

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 une position de code est représenté en une suite d'unités de codage (et inversement, c'est à dire comment retrouver la position de codage étant donnée 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 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 surcodage comme pour le LDAP qui sp√©cifie que les cha√ģnes Unicode doivent √™tre cod√©es en UTF-8 et surcod√©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 du codage. Ainsi, on ne peut donc pas parler de la taille d’un caractère Unicode, car elle dépend du codage 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/CEI 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√ę gr√Ęce 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 gr√Ęce 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√©fini les additions de nouveaux caract√®res).
  • En pratique, pour la plupart des d√©veloppeurs d‚Äôapplications, la norme ISO 10646 appara√ģt 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/CEI 10646 acceptent plusieurs formes de transformation universelle pour repr√©senter un point de code valide. Citons :

Le nombre après UTF représente le nombre minimal de bits des codets avec lesquels 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/CEI10646 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. 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

Article d√©taill√© : UTF-8.

L‚ÄôUTF-8, sp√©cifi√© dans le RFC 3629, 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 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 obsol√®te 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/CEI10646 pour ne plus accepter que la repr√©sentation la plus courte de chaque point de code (unicit√© du codage).

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 normalis√©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-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/ISO646, 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, √† cet usage on lui pr√©f√®re souvent l‚ÄôUTF-16, parfois l‚ÄôUTF-32 (gourmand en m√©moire).

Dérivés
  • Certains programmes (par exemple, la base de donn√©es Oracle) repr√©sentant en interne leurs donn√©es Unicode au format UTF-16 ont (ou ont connu) un d√©faut de conversion vers UTF-8 : un caract√®re compris entre U+10000 et U+10FFFF, stock√© sur deux mots de 16 bits, se retrouve converti en UTF-8 comme √©tant une suite de deux caract√®res Unicode. Cela a amen√© la cr√©ation ¬ę accidentelle ¬Ľ du CESU-8 et a pour avantage de faciliter l'usage d'Unicode sur des plates-formes 16 bits.
  • Le caract√®re Unicode nul U+0000 est cod√© en UTF-8 sous forme d‚Äôun unique octet nul 0x00. Selon le standard Unicode, ce caract√®re n'a aucune signification particuli√®re[2] ; toutefois (pour des raisons conceptuelles historiques), les biblioth√®ques de traitement de cha√ģnes du langage C consid√®rent ce caract√®re de contr√īle comme une fin de cha√ģne, ce qui complique l'impl√©mentation de certains cas d'application. Sous la plate-forme Java, la version ¬ę (en)Modified UTF-8 ¬Ľ est n√©e en reprenant l'avantage de la portabilit√© ¬ę 16 bits ¬Ľ du CESU-8 et en y ajoutant la possibilit√© d'encoder U+0000 sous la s√©quence 0xC0 0x80 (normalement interdite en UTF-8[3]) : en √©changeant de la sorte avec les biblioth√®ques C natives de la plateforme support√©e, la plate-forme peut g√©rer facilement tous les textes Unicode valides ainsi que les fichiers de classes compil√©es (format alternatif portable, ind√©pendant de l'endianness et de la taille des mots).

UTF-16

Article d√©taill√© : 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.

Codage UTF-16
hi \ lo DC00 DC01    ‚Ķ    DFFF
D800 10000 10001 … 103FF
D801 10400 10401 … 107FF
  ‚čģ ‚čģ ‚čģ ‚čĪ ‚čģ
DBFF 10FC00 10FC01 … 10FFFF

Les points de code des 16 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'√©tendue 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)

Comme la plupart des caractères couramment usités résident dans le plan de base, l'encodage des plans supplémentaires est souvent peu testé dans les logiciels, conduisant à des bugs ou des problèmes de sécurité même dans des logiciels largement diffusés[4]. Certains cadres légaux, tels le GB 18030, peuvent demander le support des plans supplémentaires, ceux-ci contenant notamment des caractères présents dans les noms propres.

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 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/CEI10646.

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 le codage qu’utilise la plate-forme Java en interne, ainsi que Windows pour ses APIs compatibles Unicode (avec le type "WCHAR").

UTF-32

Article d√©taill√© : 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. 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 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 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 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.

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] [note 0] ou wchar_t[2] [note 1] char[] ou wchar_t[]
C++ char[4] [note 0] ou wchar_t[2] [note 1] char[] ou wchar_t[] ou std::wstring
Java char[2] ou int [note 2] char[] ou String
Bibliothèque ICU (pour C/C++ ou Java) UChar UChar[] ou String, UnicodeString
Javascript ou ECMAScript char [note 3] string
C# ou J# char string
Delphi char[4] [note 0] ou widechar[2] string [note 0] ou widestring
Python unicode

Notes :

  • [note 0] En UTF-8
  • [note 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 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.
  • [note 2] 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).
  • [note 3] 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 ¬Ľ.

Points de code Nom officiel du bloc Commentaires
Début Fin
0000 FFFF Plan multilingue de base (PMB)
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
10000 1FFFF Plan multilingue complémentaire (PMC)
10000 1007F Syllabaire linéaire B ou syllabaire mycénien
10080 100FF Idéogrammes du linéaire B
10100 1013F Nombres égéens
10300 1032F Alphabet italique
10330 1034F Gotique voir langue Gotique
10380 1039F Ougaritique voir langue Ougaritique
10400 1044F Déséret
10450 1047F Shavien
10480 104AF Osmanya
10800 1083F Syllabaire chypriote
1D000 1D0FF Symboles musicaux byzantins
1D100 1D1FF Symboles musicaux occidentaux
1D300 1D35F Symboles du Classique du mystère suprême
1D400 1D7FF Symboles mathématiques alphanumériques
1FFFE 1FFFF non-caractères
20000 2FFFF Plan idéographique complémentaire (PIC)
20000 2A6D6 Supplément B aux idéogrammes unifiés CJC
2F800 2FA1F Supplément aux idéogrammes de compatibilité CJC
2FFFE 2FFFF non-caractères
30000 DFFFF Plans complémentaires réservés
3FFFE 3FFFF non-caractères
4FFFE 4FFFF non-caractères
5FFFE 5FFFF non-caractères
6FFFE 6FFFF non-caractères
7FFFE 7FFFF non-caractères
8FFFE 8FFFF non-caractères
9FFFE 9FFFF non-caractères
AFFFE AFFFF non-caractères
BFFFE BFFFF non-caractères
CFFFE CFFFF non-caractères
DFFFE DFFFF non-caractères
E0000 EFFFF Plan complémentaire spécialisé (PCS)
E0000 E007F √Čtiquettes
E0100 E01EF Supplément de sélecteurs de variante
EFFFE EFFFF non-caractères
F0000 10FFFF Plans complémentaires à usage privé
‚ėíF0000 FFFFD Zone suppl√©mentaire A √† usage priv√©
FFFFE FFFFF non-caractères
‚ėí100000 10FFFD Zone suppl√©mentaire B √† usage priv√©
10FFFE 10FFFF non-caractères

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 de codage correspondants, et les autres codages 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 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é 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).

Notes et références

  1. ‚ÜĎ Unicode Technical Report #17: Unicode Character Encoding Model
  2. ‚ÜĎ (en)The Unicode Standard, Version 5.0, Chapter 16 : Special Areas and Format Characters, p354
  3. ‚ÜĎ Les s√©quences UTF-8 doivent √™tre les plus courtes possibles. Cette restriction doit √™tre v√©rifi√©e pour √©viter certaines failles de s√©curit√©, du type "/../" ‚Äď se reporter aux d√©tails dans la section ¬ę Inconv√©nients ¬Ľ de l'article UTF-8.
  4. ‚ÜĎ Code in Apache Xalan 2.7.0 which can fail on surrogate pairs, Apache Foundation

Voir aussi

Liens externes

Références normatives

Références informatives

Tables et données

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

Utilitaires

Guides d'utilisation

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)

Articles connexes


Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article Unicode de Wikipédia en français (auteurs)

Regardez d'autres dictionnaires:

  • UNICODE ‚ÄĒ –ģ–Ĺ–ł–ļ–ĺ–ī, –ł–Ľ–ł –£–Ĺ–ł–ļ–ĺ–ī (–į–Ĺ–≥–Ľ. Unicode)¬† —Ā—ā–į–Ĺ–ī–į—Ä—ā –ļ–ĺ–ī–ł—Ä–ĺ–≤–į–Ĺ–ł—Ź —Ā–ł–ľ–≤–ĺ–Ľ–ĺ–≤, –Ņ–ĺ–∑–≤–ĺ–Ľ—Ź—é—Č–ł–Ļ –Ņ—Ä–Ķ–ī—Ā—ā–į–≤–ł—ā—Ć –∑–Ĺ–į–ļ–ł –Ņ—Ä–į–ļ—ā–ł—á–Ķ—Ā–ļ–ł –≤—Ā–Ķ—Ö –Ņ–ł—Ā—Ć–ľ–Ķ–Ĺ–Ĺ—č—Ö —Ź–∑—č–ļ–ĺ–≤. –°—ā–į–Ĺ–ī–į—Ä—ā –Ņ—Ä–Ķ–ī–Ľ–ĺ–∂–Ķ–Ĺ –≤ 1991 –≥–ĺ–ī—É –Ĺ–Ķ–ļ–ĺ–ľ–ľ–Ķ—Ä—á–Ķ—Ā–ļ–ĺ–Ļ –ĺ—Ä–≥–į–Ĺ–ł–∑–į—Ü–ł–Ķ–Ļ ¬ę–ö–ĺ–Ĺ—Ā–ĺ—Ä—Ü–ł—É–ľ –ģ–Ĺ–ł–ļ–ĺ–ī–į¬Ľ (–į–Ĺ–≥–Ľ. Unicode Consortium,… ‚Ķ   –í–ł–ļ–ł–Ņ–Ķ–ī–ł—Ź

  • Unicode ‚ÄĒ –ģ–Ĺ–ł–ļ–ĺ–ī, –ł–Ľ–ł –£–Ĺ–ł–ļ–ĺ–ī (–į–Ĺ–≥–Ľ. Unicode)¬† —Ā—ā–į–Ĺ–ī–į—Ä—ā –ļ–ĺ–ī–ł—Ä–ĺ–≤–į–Ĺ–ł—Ź —Ā–ł–ľ–≤–ĺ–Ľ–ĺ–≤, –Ņ–ĺ–∑–≤–ĺ–Ľ—Ź—é—Č–ł–Ļ –Ņ—Ä–Ķ–ī—Ā—ā–į–≤–ł—ā—Ć –∑–Ĺ–į–ļ–ł –Ņ—Ä–į–ļ—ā–ł—á–Ķ—Ā–ļ–ł –≤—Ā–Ķ—Ö –Ņ–ł—Ā—Ć–ľ–Ķ–Ĺ–Ĺ—č—Ö —Ź–∑—č–ļ–ĺ–≤. –°—ā–į–Ĺ–ī–į—Ä—ā –Ņ—Ä–Ķ–ī–Ľ–ĺ–∂–Ķ–Ĺ –≤ 1991 –≥–ĺ–ī—É –Ĺ–Ķ–ļ–ĺ–ľ–ľ–Ķ—Ä—á–Ķ—Ā–ļ–ĺ–Ļ –ĺ—Ä–≥–į–Ĺ–ł–∑–į—Ü–ł–Ķ–Ļ ¬ę–ö–ĺ–Ĺ—Ā–ĺ—Ä—Ü–ł—É–ľ –ģ–Ĺ–ł–ļ–ĺ–ī–į¬Ľ (–į–Ĺ–≥–Ľ. Unicode Consortium,… ‚Ķ   –í–ł–ļ–ł–Ņ–Ķ–ī–ł—Ź

  • Unicode ‚ÄĒ es una norma de codificaci√≥n de caracteres. Su objetivo es asignar a cada posible car√°cter de cada posible lenguaje un n√ļmero y nombre √ļnico, a diferencia de la mayor parte de los juegos ISO como el ISO 8859 1, que s√≥lo definen los necesarios… ‚Ķ   Enciclopedia Universal

  • Unicode ‚ÄĒ ¬† [dt. ¬Ľein (einziger) Code¬ę], ein 1996 ver√∂ffentlichter Standard f√ľr Zeichens√§tze, die anerkannte Implementierung der internationalen Norm ISO/IEC 10646. Der Unicode Standard wird von einem Konsortium weiterentwickelt, dem fast 100 Firmen und… ‚Ķ   Universal-Lexikon

  • Unicode ‚ÄĒ /Ňęňąni kŇćd/ noun (computing) An international standard for representing symbols and characters in 16 bit codes, with space for all foreseeable languages and symbols ORIGIN: ‚ÜĎuni or ‚ÜĎunique ‚Ķ   Useful english dictionary

  • Unicode ‚ÄĒ For the 1889 Universal Telegraphic Phrase book, see Commercial code (communications). The Unicode official logo since October 2009 ‚Ķ   Wikipedia

  • Unicode ‚ÄĒ Logo von Unicode Unicode [ňąjuňźn…™ko äd] ist ein internationaler Standard, in dem langfristig f√ľr jedes sinntragende Schriftzeichen oder Textelement aller bekannten Schriftkulturen und Zeichensysteme ein digitaler Code festgelegt wird. Ziel ist es,… ‚Ķ   Deutsch Wikipedia

  • Unicode ‚ÄĒ El Est√°ndar Unicode es un est√°ndar de codificaci√≥n de caracteres dise√Īado para facilitar el tratamiento inform√°tico, transmisi√≥n y visualizaci√≥n de textos de m√ļltiples lenguajes y disciplinas t√©cnicas adem√°s de textos cl√°sicos de lenguas muertas ‚Ķ   Wikipedia Espa√Īol

  • Unicode ‚ÄĒ International character encoding system designed to support the electronic interchange, processing, and display of the written texts of the diverse languages of the modern and classical world. The Unicode Worldwide Character Standard includes… ‚Ķ   Universalium

  • Unicode ‚ÄĒ ¬†¬†¬†A 16 bit character code, defined by the Unicode Consortium and by ISO 10646, that supports a maximum of 65,536 unique characters rather than the 256 characters available in the current ASCII character set. ¬†¬†¬†By using two bytes to represent… ‚Ķ   Dictionary of networking


Share the article and excerpts

Direct link
… Do a right-click on the link above
and select ‚ÄúCopy Link‚ÄĚ

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.