Unicode
Unicode est un standard informatique qui permet des échanges de textes dans différentes langues, à un niveau mondial. Il est développé par le Consortium Unicode, qui vise au 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, quels que soient la plateforme informatique ou le logiciel utilisé.
Ce standard est lié à la norme Modèle:Nobr qui décrit une table de caractères équivalente. La dernière version, Modèle:Nobr, a été publiée en Modèle:Date<ref name="archives">Modèle:Lien web</ref>.
Totalement compatible avec le jeu universel de caractères (JUC) de l'Modèle:Nobr, le standard Unicode l'étend en lui ajoutant un modèle complet de représentation et de traitement de textes, en conférant à chaque caractère un jeu de propriétés (qui peuvent être soit pour certaines standardisées et stabilisées dans toutes les versions d'Unicode où le caractère a été encodé, soit informatives avec seulement une recommandation sur leur usage qui peut évoluer en fonction des nouveaux besoins trouvés). Ces propriétés décrivent avec précision les relations sémantiques qui peuvent exister entre plusieurs caractères successifs d'un texte, et permettent de standardiser ou recommander des algorithmes de traitement qui préservent au maximum la sémantique des textes transformés. Unicode a pour objet de rendre un même texte utilisable à l'identique sur des systèmes informatiques totalement différents.
Le standard Unicode est constitué d'un répertoire de Modèle:Unité, couvrant plus de 150 é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, APL, symboles, ponctuationModèle: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 à la fois des caractères d'écritures de droite à gauche, comme l'arabe et l'hébreu, et de gauche à droite).
En pratique, Unicode reprend intégralement la norme Modèle:Nobr, puisque cette dernière ne standardise que les caractères individuels en leur assignant un nom et un numéro normatif (appelé point 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 seul le standard Unicode définit précisément. L'Modèle:Nobr fait normativement référence à certaines parties du standard Unicode (notamment Modèle:Lien) ; Unicode est également une norme Modèle:Langue pour le traitement du texte et sert de base à de nombreuses autres normes.
But
Unicode, dont la première publication remonte à Modèle:Date, a été développé dans le but de remplacer l'utilisation de pages de code nationales.
Ces pages de code avaient dans le passé quelques problèmes. Par exemple, sur les [[Terminal 3270|Modèle:Nobr]] fonctionnant en EBCDIC : lorsqu'une note de service électronique comportait un caractère « signe monétaire », le même texte plafonnant une dépense en dollars pour le lecteur américain faisait afficher sur un écran britannique le même montant en livres sterling, puisque le signe monétaire était différent dans chacun des deux pays.
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 bidirectionnel).
Standardisation
Interopérabilité
Sous sa forme UTF-8, l'Unicode offre une certaine interopérabilité avec le code ASCII : en effet, les 128 caractères ASCII, y compris les caractères de contrôle, sont représentés de manière identique (sur un octet) en UTF-8 par les points de code U+0000 à U+007F.
Conformité
Le standard Unicode définit des exigences permettant d'évaluer la conformité de l'implémentation d'un processus (ou d'un logiciel) à Unicode<ref>{{#invoke:Langue|indicationDeLangue}} [1].</ref>Modèle:Refins. Ces exigences concernent notamment (dans la Modèle:Nobr) :
- le traitement de Points de Code non assignés ;
- l'interprétation des séquences de caractères équivalentes ;
- ce qu'est une modification d'interprétation du texte ;
- le codage des caractères ;
- l'affichage du texte bidirectionnel ;
- la normalisation ;
- les algorithmes ;
- la casse.
Ces exigences permettent le support d'un sous-ensemble d'Unicode.
Alors que l'Modèle:Nobr définit le même jeu de caractères qu'Unicode, la différence entre Modèle:Nobr et Unicode tient essentiellement dans le surplus d'exigence de conformité fourni par Unicode.
Limitations
Unicode est en 2016<ref>Modèle:Lien web.</ref> le standard leader pour le codage informatique des caractères. Il sert à l'interopérabilité de logiciels, et permet par exemple de copier des textes utilisant des caractères de différents alphabets entre des logiciels différents, même n'ayant pas été spécifiquement conçus pour eux (par exemple un programme en caractères APL dans un texte LibreOffice ou dans un courriel sous Gmail). Tous les textes Unicode ne sont cependant pas codés de la même manière. Suivant la normalisation Unicode adoptée, un même signe graphique peut parfois être codé de différentes manières. Certains textes utilisent la convention Modèle:Abréviation discrète, d'autres la convention Modèle:Abréviation discrèteModèle:Etc. Et le standard n'interdit pas de mélanger plusieurs conventions dans un même texte. Il en va de même des logiciels.
Cette coexistence de plusieurs façons d'écrire la même chose a été exploitée par les pirates dans les Modèle:Nobr en leur permettant de déjouer des filtres : les pirates contournaient les interdictions de certaines chaînes de caractères jugées dangereuses tout simplement en les codant sous une autre forme, plus inhabituelle et de ce fait parfois non filtrée.Modèle:Référence nécessaire
Unicode répond à ces limitations en apportant la notion d'équivalence canonique.
Normes et versions
Le travail sur Unicode est parallèle et synchronisé avec celui sur la norme Modèle:Nobr dont les buts sont les mêmes. L'Modèle:Nobr, une norme internationale publiée en français et en anglais, qui ne précise 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 Modèle:Nobr d'Unicode et dans toutes les versions suivantes, les caractères ont les mêmes identifiants que ceux de la norme Modèle:Nobr : les répertoires sont maintenus parallèlement, à l'identique lors de leur standardisation définitive, les deux normes étant mises à jour presque simultanément. Les deux normes Unicode (depuis la Modèle:Nobr) et Modèle:Nobr 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 Modèle:Nobr d'Unicode sont ceux de la norme Modèle:Nobr. La Modèle:Nobr d'Unicode classait Modèle:Nombre, symboles et directives.
La Modèle:Nobr d'Unicode, mise à jour en Modèle:Date, comprenait :
- Modèle:Unité à usage privé, dont Modèle:Nombre dans le plan multilingue de base (définis dans toutes les versions d'Unicode) et Modèle:Nombre dans les deux derniers plans (depuis la version 2.0 d'Unicode), ce qui doit suffire à tous les usages ;
- plus de Modèle:Unité ou syllabes, chiffres ou nombres, symboles divers, signes diacritiques et signes de ponctuation, avec parmi eux :
- plus de Modèle:Unité idéographiques (pour l'écriture classique ou modernisée des langues chinoises, et utilisés en partie et en association avec d'autres écritures plus simples en japonais, en coréen classique, ainsi qu'en vietnamien classique) ;
- Modèle:Unité précomposées de l'alphabet hangûl (pour la langue coréenne moderne) ;
- plusieurs centaines de caractères de contrôle ou modificateurs spéciaux ; ainsi que
- Modèle:Nombre de codes réservés de façon permanente, interdits pour le codage de texte (assignés dans toutes les versions d'Unicode).
Soit un total de près de Modèle:Unité de codes assignés dans un espace pouvant contenir Modèle:Nombre 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.
| Version | Date de publication | Nombre de caractères | Ajouts notables |
|---|---|---|---|
| 1.0.0 | Modèle:Date | 7129 | Unicode 1.0 incluait ces scripts: Arabe, arménien, bengali, bopomofo, cyrillique, devanagari, géorgien, grec et copte, gujarati, gurmukhi, hangul, hébreu, hiragana, kannada, katakana, lao, latin, malayalam, oriya, tamoul, télougou, thaï et tibétain |
| 1.0.1 | Modèle:Date | 28327 | 20 902 caractères CJC sont définis |
| 1.1 | Modèle:Date | 34168 | 4306 syllabes Hangul supplémentaires ont été ajoutées à l'ensemble original de 2350. Le tibétain a été supprimé dans cette mise à jour. |
| 2.0 | Modèle:Date | 38885 | Le Hangul original est supprimé et est déplacé et remplacé par un nouvel ensemble de 11172. Le tibétain est rajouté à un endroit différent. |
| 2.1 | Modèle:Date | 38887 | Le signe Euro et le caractère de remplacement d'objet ont été ajoutés. |
| 3.0 | Modèle:Date | 49194 | Cherokee, éthiopien, khmer, mongol, birman, ogham, runique, cinghalais, syriaque, thaana, syllabes autochtones canadiennes unifiées et syllabes yi ajoutées, ainsi qu'un ensemble de motifs braille. |
| 3.1 | Modèle:Date | 94140 | Deseret, gothique et vieil italique ajoutés, ainsi que des ensembles de symboles pour la musique occidentale et la musique byzantine, et 42 711 idéogrammes unifiés CJC supplémentaires |
| 3.2 | Modèle:Date | 95156 | Buhid, Hanunó'o, Tagalog et Tagbanwa ajoutés |
| 4.0 | Modèle:Date | 96382 | Syllabaire chypriote, Limbu, Linéaire B, Osmanya, Shavian, Tai Le et Ugaritic ajoutés, ainsi que des symboles Hexagram |
| 4.1 | Modèle:Date | 97655 | Buginese, Glagolitic, Kharoshthi, New Tai Lue, Old Persian, Syloti Nagri et Tifinagh ont été ajoutés, et le copte a été désunifié du grec. Des chiffres grecs anciens et des symboles musicaux ont également été ajoutés. |
| 5.0 | Modèle:Date | 99024 | Balinais, cunéiforme, N'Ko, Phags-pa et phénicien ajoutés. |
| 5.1 | Modèle:Date | 100648 | Carian, Cham, Kayah Li, Lepcha, Lycian, Lydian, Ol Chiki, Rejang, Saurashtra, Sundanais et Vai ont été ajoutés, ainsi que des ensembles de symboles pour le disque Phaistos, les tuiles Mahjong et les tuiles Domino. Il y avait aussi des ajouts importants pour le birman, des ajouts de lettres et d'abréviations Scribal utilisées dans les manuscrits médiévaux, et l'ajout de Capital ẞ. |
| 5.2 | Modèle:Date | 107296 | Avestan, Bamum, hiéroglyphes égyptiens (l'ensemble Gardiner, comprenant 1071 caractères), araméen impérial, inscriptional pahlavi, inscriptional parthe, javanais, kaithi, lisu, meetei mayek, vieux sud-arabe, vieux turc, samaritain, tai tham et tai viet ajoutés. 4 149 idéogrammes unifiés CJK supplémentaires (CJK-C), ainsi qu'un Jamo étendu pour le vieux Hangul et des caractères pour le sanskrit védique. |
| 6.0 | Modèle:Date | 109384 | Batak, Brahmi, Mandaic, symboles de cartes à jouer, symboles de transport et de carte, symboles alchimiques, émoticônes et emojis. 222 idéogrammes unifiés CJC supplémentaires (CJK-D) ajoutés. |
| 6.1 | Modèle:Date | 110116 | Chakma, cursive méroïtique, hiéroglyphes méroïtiques, Miao, Sharada, Sora Sompeng et Takri. |
| 6.2 | janvier 2012 | 110117 | Le signe de la lire turque a été ajouté. |
| 6.3 | septembre 2013 | 110122 | 5 caractères de formatage bidirectionnel ont été ajoutés |
| 7.0 | Modèle:Date | 112956 | Bassa Vah , Albanais du Caucase , Duployan , Elbasan , Grantha , Khojki , Khudawadi , Linéaire A , Mahajani , Manichéen , Mende Kikakui , Modi , Mro , Nabatéen , Vieux Arabe du Nord , Vieux Permic , Pahawh Hmong , Palmyrène , Pau Cin Hau , Psautier Pahlavi , Siddham, Tirhuta, Warang Citi et Dingbats. |
| 8.0 | Modèle:Date | 120672 | Ahom, hiéroglyphes anatoliens, Hatran, Multani, vieux hongrois, SignWriting, 5 771 idéogrammes unifiés CJK, un ensemble de lettres minuscules pour Cherokee et cinq modificateurs de teint emoji. |
| 9.0 | Modèle:Date | 128172 | Adlam, Bhaiksuki, Marchen, Newa, Osage, Tangut et 72 emoji. |
| 10.0 | Modèle:Date | 136690 | Place Zanabazar, Soyombo, Masaram Gondi, Nüshu, hentaigana (hiragana non standard), 7 494 idéogrammes unifiés CJC, 56 emoji et symbole bitcoin. |
| 11.0 | Modèle:Date | 137374 | Dogra, lettres majuscules géorgiennes Mtavruli, Gunjala Gondi, Hanifi Rohingya, nombres indiens Siyaq, Makasar, Medefaidrin, anciens sogdiens et sogdiens, chiffres mayas, 5 idéogrammes unifiés CJK urgents, symboles pour xiangqi (échecs chinois) et classement par étoiles, et 145 emoji . |
| 12.0 | Modèle:Date | 137928 | Elymaic, Nandinagari, Nyiakeng Puachue Hmong, Wancho, ajouts d'écritures Miao pour plusieurs langues Miao et Yi de Chine, lettres minuscules hiragana et katakana pour l'écriture du japonais archaïque, fractions et symboles historiques tamouls, lettres lao pour le pali, lettres latines pour la translittération égyptologique et ougaritique , commandes de format hiéroglyphe et 61 emoji. |
| 12.1 | mai 2019 | 137929 | Ce caractère, ㋿, a été ajouté en tant que forme de ligature carrée de l'ère Reiwa |
| 13.0 | Modèle:Date | 143859 | Chorasmian, Dives Akuru, petite écriture khitane, yezidi, 4 969 idéogrammes unifiés CJK ajoutés (dont 4 939 dans Ext. G), ajouts d'écriture arabe utilisés pour écrire le haoussa, le wolof et d'autres langues en Afrique et autres ajouts utilisés pour écrire l'hindko et le pendjabi en Pakistan, ajouts Bopomofo utilisés pour le cantonais, symboles de licence Creative Commons, caractères graphiques pour la compatibilité avec le télétexte et les systèmes informatiques domestiques des années 1970 et 1980, et 55 emoji. |
| 14.0 | Modèle:Date | 144697 | Toto, Cypro-Minoan, Vithkuqi, Old Uyghur, Tangsa, ajouts d'écritures latines aux blocs SMP (Ext-F, Ext-G) pour une utilisation dans l'API étendue, ajouts d'écritures arabes pour une utilisation dans les langues à travers l'Afrique et en Iran, Pakistan, Malaisie , Indonésie, Java et Bosnie, et pour écrire des titres honorifiques, des ajouts à usage coranique, d'autres ajouts pour prendre en charge les langues en Amérique du Nord, aux Philippines, en Inde et en Mongolie, l'ajout du symbole monétaire kirghize som, la prise en charge de la notation musicale Znamenny et 37 émojis. |
| 15.0 | Modèle:Date | 149186 | Kawi et Mundari, plusieurs nouveaux personnages, dont 20 emojis, 4 192 idéogrammes CJC et des caractères de contrôle pour les hiéroglyphes égyptiens. |
Couches d'Unicode
Unicode est défini suivant un modèle en couches (Note technique Unicode no 17<ref>{{#invoke:Langue|indicationDeLangue}} Modèle:Langue.</ref>). 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 (Modèle:Langue)
La couche la plus élevée est la définition du jeu de caractères abstraits. Par exemple, Latin-1 a un jeu de Modèle:Nombre quand Unicode et l'Modèle:Nobr normalisent conjointement actuellement près de Modèle:Nombre dans un répertoire commun.
En outre, Unicode et l'ISO/CEO 10646 affectent une dénomination commune et normalisée à chacun de ces caractères. La liste des caractères abstraits avec leurs noms normalisés constituent la couche commune de présentation de la norme Modèle:Nobr et du standard Unicode. Par exemple, le caractère Ç est nommé « lettre majuscule latine c cédille ». Cette définition est totalement identique à celle de l'Modèle:Nobr 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 Modèle:Nobr est publiée en deux langues également normatives. Ainsi les noms en anglais et en français sont tous deux normalisés par l'ISO.
Dans les faits, toute extension du répertoire se fait aujourd'hui conjointement entre le groupe de travail responsable de l'Modèle:Nobr (JTC1/SC2/WG2, dont les membres votants sont uniquement des autorités de normalisation nationales des pays participants, ou leur représentant officiel), et le Comité technique Unicode UTC (dont les membres votants peuvent être n'importe quelle organisation privée ou d'intérêt public, ou même un gouvernement, qui a adhéré et paye une redevance annuelle permettant de participer à ces décisions).
Jeu de caractères codés (Modèle:Langue)
La normale ISO/CEI 10646 ajoute à la table précédente un numéro associé à chaque caractère abstrait du répertoire commun, lequel est repris dans le standard Unicode. Notons bien qu'il ne s'agit pas d'une représentation en mémoire, juste d'un nombre entier, appelé point de code.
L'espace de codage de ces nombres est divisé en Modèle:Nombre de Modèle:Nombre : ces zones sont appelées « plans de code ». Les plans de code sont eux-mêmes divisés en « colonnes de code » comprenant Modèle:Nombre, qui sont (autant que possible) l'unité minimale de réservation dans le répertoire pour des groupes de caractères (assignés ou à venir) souvent utilisés conjointement dans une même écriture ou ayant des propriétés de base communes).
Chaque point de code est noté « U+ » suivi(s) de Modèle:Unité/2 en hexadécimal :
- Modèle:Nombre pour le premier plan appelé plan multilingue de base (donc entre U+0000 et U+FFFF) ;
- Modèle:Nombre pour les Modèle:Nombre suivants (entre U+10000 et U+FFFFF) ;
- Modèle:Nombre pour le dernier plan (entre U+100000 et U+10FFFF).
Ainsi le caractère nommé « Lettre majuscule latine c cédille » (Ç) a le numéro U+00C7. Il appartient au premier plan.
En principe tous les points de code entre U+0000 et U+10FFFF sont disponibles, mais certaines plages sont perpétuellement réservées à des usages particuliers, notamment une zone d'indirection exclue afin de permettre le codage UTF-16 (Modèle:Cf. infra), les zones à usage privé, ainsi que quelques régions (dont les deux derniers points de code de chacun des plans de code, par exemple U+FFFE ou U+FFFF) contenant des « non-caractères » et dont l'usage est interdit dans un échange de données conforme. Les autres points de code sont soit déjà affectés à des caractères, soit réservés par l'ISO/CEI 10646 pour une normalisation future.
Zone à usage privé : l'ISO/CEI 10646 et Unicode ont assigné de nombreux points de code à des caractères valides, mais dont la sémantique est inconnue car d'usage privé (par exemple les deux derniers plans entre U+F0000 et U+10FFFF sont entièrement destinés à cet usage, hormis les deux points de code à la fin de chaque plan qui sont des non-caractères interdits dans un texte conforme).
Là encore, la standardisation du codage, c'est-à-dire l'affectation des points de codes aux caractères du répertoire commun est une décision conjointe partagée entre les normes Unicode et Modèle:Nobr. Tous les caractères du répertoire disposent d'un point de code unique (même si pour certaines langues ou pour Unicode certains caractères sont considérés comme équivalents, avec l'un d'eux désigné comme standard et recommandé et les autres présents pour des raisons de compatibilité ascendante, par exemple avec d'anciennes normes ou avec des standards encore fréquemment utilisés).
On peut noter que si le répertoire des caractères est extensible, il est limité par la borne supérieure de l'espace de codage : U+10FFFF. La grande majorité des points de code possibles n'est encore associée à aucun caractère particulier, mais peut l'être à tout moment.
Aussi ces points de code encore libres ne sont pas considérés comme non valides, mais représentent bien des caractères abstraits (non encore spécifiés, et réservés jusqu'à nouvel ordre). Ces caractères abstraits (de même que les caractères à usage privé) complètent le jeu de caractères codés du répertoire standardisé pour former un jeu unique, dit « jeu de caractères codés universel » (Modèle:Langue, 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'Modèle:Nobr et ceux d'Unicode (depuis la Modèle:Nobr uniquement).
Formalisme de codage des caractères (Modèle:Langue)
La couche suivante spécifie une représentation physique (en mémoire, sur disque…) de chacun des caractères abstraits : quelle unité de codage (Modèle:Langue), ou codet, va représenter un caractère ou plus exactement un point de code : octet, Modèle:Lien (mot de Modèle:Nombre) ou Modèle:Lien (mot de Modèle:Nombre).
Il peut exister (et il existe) plusieurs de ces formalismes. Un formalisme particulier doit préciser la taille de l'unité de codage et indiquer de quelle façon le nombre entier représentant un point de code est représenté en une suite d'unités de codage − et inversement, c'est-à-dire comment retrouver le point de code étant donné une suite d'unités de codage.
Mécanisme de sérialisation des caractères (Modèle:Langue)
Cette couche s'occupe de sérialiser les suites d'unités de codage définies par la couche précédente en suites d'octets. C'est ici que se choisit l'ordre des octets entre les ordres gros-boutien (octet le plus significatif d'abord) et petit-boutien (octet le moins significatif d'abord).
C'est également à cette étape qu'il est possible d'ajouter un indicateur d'ordre des octets (ou BOM, pour Modèle:Langue), qui permet d'indiquer en début de fichier ou de flot de données s'il est en gros-boutien ou en petit-boutien. Dans le monde Internet, on l'utilise rarement, en préférant un marquage explicite (« charset=UTF-16BE » en MIME, par exemple, pour indiquer un flot de données gros-boutien, où BE signifie Modèle:Langue).
Surcodage de transfert (Modèle:Langue)
À ce niveau peuvent intervenir les mécanismes de compression ou de chiffrement. Il peut aussi y avoir également des surcodages, notamment au sein des protocoles MIME et HTTP qui les utilisent presque partout, mais aussi pour le LDAP, qui spécifient par exemple que les chaînes Unicode doivent être codées en UTF-8 puis surcodées en Base64 (ou avec d'autres formats d'échappement) et comment indiquer ces options de surcodage au sein des données échangées par ces applications.
Ces compressions, chiffrements et surcodages, le plus souvent nécessaires et adaptés (et souvent standardisés) à divers protocoles pour la sécurisation et l'encapsulation correcte du texte codé et transporté (ou stocké), ne font partie ni standard Unicode, ni de la norme Modèle:Nobr.
Limite de l'octet
Pour s'affranchir des contraintes rigides des normes précédentes (une suite de bits, une représentation), Unicode sépare dorénavant d'une part la définition du jeu de caractères (liste des caractères par 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, et celui-ci peut donc varier à volonté. En pratique, UTF-8 est très utilisé dans les pays occidentaux.
Là où l'ASCII utilise Modèle:Nombre et Modèle:Nobr Modèle:Nombre (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 Modèle:Nombre d'un octet. La limite fut dans un premier temps fixée à Modèle:Nombre pour les premières versions d'Unicode, et à Modèle:Nombre pour les premières versions de la norme ISO/CEI 10646.
La limite actuelle est désormais placée entre Modèle:Unité/2 par point de code assigné aux caractères standardisés dans les deux normes, désormais mutuellement compatibles :
- Le groupe de travail international de l'ISO standardise 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 standardisé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 standardisé 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 Modèle:Nobr apparaît comme un sous-ensemble de la norme Unicode plus complète, mais 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, ainsi que consultable gratuitement sur Internet).
Modèle:Langue (UTF)
Unicode et Modèle:Nobr 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 Modèle:Nobr, qui au départ pouvait définir des points de code sur Modèle:Nombre. Depuis, la norme Modèle:Nobr 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 Modèle:Nombre plans).
Unicode a standardisé é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 code, 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 Modèle:Nombre de Modèle:Nombre, des points de code des Modèle:Nombre supplémentaires.
UTF-8
Modèle:Article détaillé L'UTF-8, spécifié dans le Modèle:RFC, est le plus commun pour les applications Unix et Internet. Son codage de taille variable lui permet d'être en moyenne moins coûteux en occupation mémoire (pour les langues à alphabet latin). Mais cela ralentit nettement les opérations où interviennent des extractions de sous-chaînes dans certains langages qui indexent des chaînes par des entiers (exemple = "815e caractère de la chaîne"), car il faut compter les caractères depuis le début de la chaîne pour savoir où se trouve le premier caractère à extraire.
L'UTF-8 assure aussi, et c'est son principal avantage, une compatibilité avec les manipulations simples de chaînes en ASCII dans les langages de programmation. Ainsi, les programmes écrits en C peuvent souvent fonctionner sans modification.
Initialement, l'UTF-8 pouvait coder n'importe quel point de code entre U+0000 et U+7FFFFFFF (donc jusqu'à Modèle:Nombre). Cet usage est déprécié et la norme Modèle:Nobr a été amendée pour ne plus supporter que les points de code valides des Modèle:Nombre 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 Modèle:Nombre supplémentaires. Aussi les séquences les plus longues en UTF-8 nécessitent au maximum Modèle:Unité, au lieu de 6 précédemment. De plus, UTF-8 a été amendé d'abord par Unicode puis par l'Modèle:Nobr pour ne plus accepter que la représentation la plus courte de chaque point de code (unicité du codage). Le fait de pouvoir représenter de plusieurs façons différentes un même caractère posait des problèmes de sécurité, car le pirate pouvait contourner par une écriture différente une forme "filtrée".
Son avantage sur l'UTF-16 (et l'UTF-32) est que les différences d'ordonnancement des octets composant un mot (Modèle:Langue) ne posent pas de problème dans un réseau de systèmes hétérogènes ; ainsi, cette transformation est utilisée aujourd'hui par la plupart des protocoles d'échange standardisés.
D'autre part, l'UTF-8 est totalement compatible pour la transmission de textes par des protocoles basés sur le jeu de caractères ASCII, ou peut être rendu compatible (au prix d'une transformation sur plusieurs octets des caractères non-ASCII) avec les protocoles d'échange supportant les jeux de caractères codés sur Modèle:Nombre (qu'ils soient basés sur Modèle:Nobr ou de nombreux autres jeux de caractères codés sur Modèle:Nombre 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 (Modèle:Unité pour les points de code assignés aux caractères ASCII–Modèle:Nobr, Modèle:Unité/2 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 Modèle:Nombre supplémentaires des codets qui précèdent). Cependant, cet encodage n'est pas conçu pour faciliter le traitement des chaînes de caractères : on lui préfère alors souvent l'UTF-16, parfois l'UTF-32 (gourmand en mémoire).
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 Modèle:Unité, 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 plateformes Modèle:Unité.
- 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<ref>{{#invoke:Langue|indicationDeLangue}} Modèle:LangueModèle:Pdf - Unicode, Inc., Modèle:P..</ref> ; 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, Modèle:Refnec. Sous la plateforme Java, la version « {{#invoke:Langue|indicationDeLangue}} Modified UTF-8 » est née en reprenant l'avantage de la portabilité « Modèle:Nombre » du CESU-8 et en y ajoutant la possibilité d’encoder U+0000 sous la séquence 0xC0 0x80 (normalement interdite en UTF-8<ref>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.</ref>) : en échangeant de la sorte avec les bibliothèques C natives de la plateforme supportée, la plateforme peut gérer facilement tous les textes Unicode valides ainsi que les fichiers de classes compilées (format alternatif portable, indépendant de l’Modèle:Langue et de la taille des mots).
UTF-16
Modèle:Article détaillé 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 Modèle:Unité. La version française de l'Modèle:Nobr nomme ces mots de Modèle:Unité des « seizets », mais la version internationale les décrit cependant bien comme de classiques mots de Modèle:Unité composés de deux octets, et soumis aux règles usuelles de boutisme.
C'est notamment le codage qu'utilise la plateforme Java en interne, ainsi que Windows pour ses API compatibles Unicode (avec le type wchar).
Certains cadres légaux, tels le Modèle:Nobr utilisé en Chine, peuvent exiger la prise en charge des plans supplémentaires, ceux-ci contenant notamment des caractères présents dans les noms propres.
| Haut \ Bas | 0xDC00 | 0xDC01 | ⋯ | 0xDFFF |
|---|---|---|---|---|
| 0xD800 | U+10000 | U+10001 | ⋯ | U+103FF |
| 0xD801 | U+10400 | U+10401 | ⋯ | U+107FF |
| ⋮ | ⋮ | ⋮ | ⋱ | ⋮ |
| 0xDBFF | U+10FC00 | U+10FC01 | ⋯ | U+10FFFF |
Les points de code des seize plans supplémentaires nécessitent une transformation sur deux mots de Modèle:Unité :
- on soustrait 0x10000 au point de code, ce qui laisse un nombre de Modèle:Unité dans l'intervalle de 0 à 0xFFFFF ;
- les Modèle:Nombre 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 Modèle:Nombre de poids faible (un nombre entre 0 et 0x3FF) sont additionnés à 0xDC00, et donnent la seconde unité de code dans la demi-zone basse (0xDC00 à 0xDFFF) ;
Il est possible de déterminer le début de la séquence de codage à partir d'un point quelconque d'un texte représenté en UTF-16 en effectuant au maximum une lecture supplémentaire, uniquement si ce codet est dans la demi-zone basse. Cette forme est plus économique et plus facile à traiter rapidement que l'UTF-8 pour la représentation de textes contenant peu de caractères ASCII (U+0000 à U+007F).
Comme la plupart des caractères couramment usités résident dans le plan de base, l'encodage des plans supplémentaires a longtemps été peu testé dans les logiciels, conduisant à des bogues ou des problèmes de sécurité même dans des logiciels largement diffusés, par exemple en supposant à tort qu'il soit sain de découper ou de tronquer une chaîne entre deux unités de code quelconque (ce qui n'est pas le cas avec UTF-16, pas plus qu'avec UTF-8, ni même avec tous les autres codages multi-octets dont les codages historiques d'avant Unicode/ISO/CEI 10646)<ref>Modèle:Lien web.</ref>.
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 Modèle:Unité. 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 Modèle:Nobr.
L'autre défaut d'UTF-16 est qu'un texte transformé avec lui et transmis avec l'un ou l'autre des deux schémas de codage contient un grand nombre d'octets nuls ou ayant une valeur en conflit avec les valeurs d'octets réservées par certains protocoles d'échange : le principal usage d'UTF-16 est dans le traitement en mémoire au sein des logiciels (également dans le stockage de métadonnées de certains systèmes de fichiers, et dans certaines bases de données où il peut être plus compact que l'UTF-8, notamment pour les textes asiatiques), le codage UTF-8 lui étant préféré pour les échanges sur les réseaux (et même dont la prise en charge est hautement recommandée voire maintenant exigée pour les protocoles du web de l'IETF, la prise en charge de l'UTF-16 et ses variantes dans ces protocoles restant facultative et en pratique très peu utilisée, d'autant que l'avantage relatif de compacité de l'UTF-16 disparaissant avec l'emploi fréquent de la compression de données, maintenant bien prise en charge dans de nombreux protocoles Internet).
UTF-32
Modèle:Article détaillé L'UTF-32 est utilisé lorsque la place mémoire n'est pas un problème et que l'on a besoin d'avoir accès à des caractères de manière directe et sans changement de taille (hiéroglyphes égyptiens).
L'avantage de cette transformation standardisée est que tous les codets ont la même taille. Il n'est donc pas nécessaire de lire des codets supplémentaires pour déterminer le début de la représentation d'un point de code.
Toutefois, ce format est particulièrement peu économique (y compris en mémoire) puisqu'il « gaspille » inutilement au moins un octet (toujours nul) par caractère. La taille en mémoire d'un texte joue négativement sur les performances puisque cela nécessite plus de lectures et écritures sur disque en cas de saturation de la mémoire vive, et que cela diminue aussi les performances du cache mémoire des processeurs.
Pour les textes écrits dans les langues modernes actuelles (hormis certains caractères rares du plan idéographique supplémentaire) et n'utilisant donc que les points de code du plan multilingue de base, cette transformation double la quantité mémoire nécessaire par rapport à l'UTF-16.
Comme l'UTF-16, l'UTF-32 possède plusieurs schémas de codage dépendant de l'ordonnancement des octets composant un entier de plus de Modèle:Nombre (deux schémas de codage de l'UTF-32 sont standardisés, UTF-32BE et UTF-32LE). Il est donc aussi nécessaire de préciser ce schéma de codage, ou de le déterminer en préfixant le texte par la représentation en UTF-32 du point de code U+FEFF. Comme l'UTF-16, la présence d'octets nuls dans les schémas de codage standardisés de l'UTF-32 le rend incompatible avec de nombreux protocoles d'échange entre systèmes hétérogènes.
Aussi ce format n'est utilisé le plus souvent que très localement pour certains traitements en tant que forme intermédiaire plus facile à manipuler, et on lui préfère souvent la transformation UTF-16 souvent plus performante pour traiter et stocker des quantités importantes de textes, la conversion entre les deux étant très simple à réaliser, et très peu coûteuse en termes de complexité de traitement.
En fait, de très nombreuses bibliothèques de traitement de textes sont écrites uniquement avec l'UTF-16 et sont plus performantes qu'en UTF-32, même lorsque les textes contiennent des caractères des plans supplémentaires (car ce cas de figure reste rare dans la très grande majorité des cas).
On notera toutefois que la transformation en UTF-32 utilise des codets sur Modèle:Nombre, dont de très nombreuses valeurs peuvent ne représenter aucun point de code valide (valeurs hors des deux intervalles représentant les points de code valides U+0000 à U+D7FF et U+E000 à U+10FFFF), donc aucun caractère valide ou réservé (toute information qui y serait contenue ne peut donc pas être du texte au sens d'Unicode). La transmission de textes utilisant ces valeurs invalides de codets dans un des schémas de codage standardisés de l'UTF-32 est interdite pour tout système conforme à Unicode (il faut utiliser plutôt les points de code à usage privé), puisqu'il sera impossible de les représenter dans une autre transformation UTF avec lesquelles les trois UTF standardisées sont bijectivement compatibles.
Norme chinoise GB 18030
Modèle:Article détaillé 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 prendre en charge l'intégralité du répertoire UCS par une transformation algorithmique complétant une large table de correspondance d'un codage à l'autre.
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 ê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 devanāgarī, le persan ou l'arabe, nécessitent un traitement complexe des ligatures : les graphèmes changent de forme en fonction de leur position ou de leurs voisins (voir Variante contextuelle et Lettre conjointe). La sélection du glyphe correct 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, une police Unicode doit être maniée avec prudence. Par exemple, une police comportant tous les glyphes existants ne suffit pas. Il faut également que le système d'affichage (le moteur de rendu) possède les mécanismes à même de traiter les ligatures, variantes contextuelles et formes conjointes propres à certaines langues. À l'inverse, une police qui ne représente qu'une partie des caractères mais sait les afficher correctement, mérite mieux le titre de « police Unicode ». Enfin, certaines contraintes techniques des formats de polices peuvent les empêcher de supporter la totalité du répertoire. En pratique, il est impossible (en 2009) de trouver une police de caractères unique supportant l'ensemble du 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 logicielle multiplateforme ICU permet de manipuler des données encodées avec Unicode. Un support d'Unicode spécifique à certaines plateformes est également intégré par les systèmes modernes (Java, Microsoft Windows, GNU/Linux, bibliothèques standards C/C++, Python, etc.).
Les types à utiliser pour stocker des variables Unicode, sont les suivants :
| Langage de programmation | Type pour un seul caractère | Type pour tout texte |
|---|---|---|
| C | char[4]Modèle:Note ou wchar_t[2]Modèle:Note
|
char[] ou wchar_t[]
|
| C++ | char[4]Modèle:Note ou wchar_t[2]Modèle:Note
|
char[] ou wchar_t[] ou std::string ou std::wstring
|
| Java | char[2] ou intModèle:Note
|
char[] ou String
|
| Bibliothèque ICU (pour C/C++ ou Java) | UChar
|
UChar[] ou String, UnicodeString
|
| JavaScript ou ECMAScript | charModèle:Note
|
string
|
| C# ou J# | char
|
string
|
| Delphi | char[4]Modèle:Note ou widechar[2]
|
stringModèle:Note ou widestring
|
| Python 2 | unicode
| |
| Python 3 | str
| |
| Go | rune (=int32)
|
string ou []byte
|
| Swift | Character
|
String
|
| Modèle:Références | ||
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 bibliothèques 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, étant donné le rôle important d'Unicode actuellement (Modèle:Nobr), on décrira ici les principaux blocs de caractères. Les noms français sont les noms officiels d'Modèle:Nobr, la norme internationale bilingue qui reprend les mêmes caractères qu'Unicode. Ils sont aussi officiels que les noms anglais.
L'ancien standard Modèle:Nobr est obsolète et incompatible avec la norme Modèle:Nobr et le standard Modèle:Nobr et toutes ses versions ultérieures (dont la version 2.0 et toutes les suivantes qui sont désormais synchronisées avec les éditions de la norme ISO/CEI 10646-1 révisée, pour leur répertoire commun ainsi que les formes de codage normalisées valides, la norme ISO/CEI ayant réduit son espace de codage à ses 17 premiers plans) ; 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 dans Unicode 1.1 pour s'aligner avec la norme ISO, et dont les anciens points de code ont depuis été assignés à d'autres blocs. La table ci-dessous est compatible avec Modèle:Nobr (toutes versions) et Modèle:Nobr (ou ultérieur).
N.b. La casse des noms de bloc n’est pas normative. « Latin de base » est donc équivalent à « LATIN DE BASE ».
Dans les tableaux suivants, tout nom de bloc ayant une note ramenant à un PDF officiel Unicode signifie que la page Wikipédia associée à ce bloc est inexistante ou erronée.
Modèle:Début de colonnes Langues écrites : Modèle:Début de bloc solidaire Alphabétique Modèle:Légende/Début Modèle:Légende Modèle:Légende Modèle:Légende Modèle:Légende Modèle:Légende Modèle:Légende/Fin Modèle:Fin de bloc solidaire Modèle:Début de bloc solidaire [L]ogographique, et [S]yllabique ou [A]lphabétique Modèle:Légende/Début Modèle:Légende Modèle:Légende Modèle:Légende Modèle:Légende Modèle:Légende/Fin Modèle:Fin de bloc solidaire Modèle:Début de bloc solidaire Consonantique (abjads sémitiques) Modèle:Légende/Début Modèle:Légende Modèle:Légende Modèle:Légende/Fin Modèle:Fin de bloc solidaire Modèle:Début de bloc solidaire Alphasyllabique (abugidas) Modèle:Légende/Début Modèle:Légende Modèle:Légende Modèle:Légende Modèle:Légende Modèle:Légende Modèle:Légende/Fin Modèle:Fin de bloc solidaire Modèle:Fin de colonnes
Plan multilingue de base (PMB, U+0000 à U+FFFF)
Plan multilingue complémentaire (PMC, U+10000 à U+1FFFF)
Plan sinographique complémentaire (PSC, U+20000 à U+2FFFF)
Plan sinographique ternaire (PST, U+30000 à U+3FFFF)
| Points de code | Nom du bloc en français | PDF officiel | En savoir plus | |
|---|---|---|---|---|
| Début | Fin | |||
| U+30000 | U+3134F | Sinogrammes unifiés CJC ― supplément G | Modèle:Lien web | voir Chinois, japonais, coréen et vietnamien, Sinogramme, Chinois écrit, Langues chinoises, Écritures du japonais, Japonais, Hanja, Coréen |
| U+31350 | U+3FFFD | Réservés | ―<ref>Modèle:Lien web</ref> | ― |
| U+3FFFE | U+3FFFF | Non-caractères | Modèle:Lien web | |
Plans complémentaires réservés (U+40000 à U+DFFFF)
Plan complémentaire spécialisé (PCS, U+E0000 à U+EFFFF)
| Points de code | Nom officiel du bloc | Commentaires | |
|---|---|---|---|
| Début | Fin | ||
| E0000 | E007F | Étiquettes | |
| E0080 | E00FF | Réservé<ref>http://unicode.org/charts/PDF/UE0080.pdf</ref> | - |
| E0100 | E01EF | Supplément de sélecteurs de variante | |
| E01F0 | EFFFF | Réservé<ref>http://unicode.org/charts/PDF/UE01F0.pdf</ref> [[Table des caractères Unicode/UE01F0|(Modèle:Nobr)]] [[Table des caractères Unicode/UE1000|(Modèle:Nobr)]] [[Table des caractères Unicode/UE2000|(Modèle:Nobr)]] [[Table des caractères Unicode/UE3000|(Modèle:Nobr)]] [[Table des caractères Unicode/UE4000|(Modèle:Nobr)]] [[Table des caractères Unicode/UE5000|(Modèle:Nobr)]] [[Table des caractères Unicode/UE6000|(Modèle:Nobr)]] [[Table des caractères Unicode/UE7000|(Modèle:Nobr)]] [[Table des caractères Unicode/UE8000|(Modèle:Nobr)]] [[Table des caractères Unicode/UE9000|(Modèle:Nobr)]] [[Table des caractères Unicode/UEA000|(Modèle:Nobr)]] [[Table des caractères Unicode/UEB000|(Modèle:Nobr)]] [[Table des caractères Unicode/UEC000|(Modèle:Nobr)]] [[Table des caractères Unicode/UED000|(Modèle:Nobr)]] [[Table des caractères Unicode/UEE000|(Modèle:Nobr)]] [[Table des caractères Unicode/UEF000|(Modèle:Nobr)]] [[Table des caractères Unicode/UEFFF0|(Modèle:Nobr)]] |
- |
Plans complémentaires à usage privé (U+F0000 à U+10FFFF)
| Points de code | Nom officiel du bloc | PDF officiel | Commentaires | |
|---|---|---|---|---|
| Début | Fin | |||
| U+F0000 | U+FFFFD | Zone supplémentaire A à usage privé Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr |
Modèle:Lien web | Plan 15. Aucun caractère officiellement défini. |
| U+FFFFE | U+FFFFF | Modèle:Nobr | Modèle:Lien web | |
| U+100000 | U+10FFFD | Zone supplémentaire B à usage privé Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr Modèle:Nobr |
Modèle:Lien web | Plan 16. Aucun caractère officiellement défini. |
| U+10FFFE | U+10FFFF | Modèle:Nobr | Modèle:Lien web | |
Les zones à usage privé ne contiennent pas les mêmes œils d'une police à l'autre et doivent donc être évités pour le codage de textes destinés aux échanges entre systèmes hétérogènes. Toutefois, ces points de codes à usage privé sont valides et peuvent être utilisés dans tout traitement automatisé conforme aux normes Unicode et Modèle:Nobr, y compris entre systèmes différents s'il existe un accord mutuel privé concernant leur usage.
En l'absence d'accord entre les deux parties, des systèmes utilisant ces caractères peuvent rejeter les textes les contenant, car les traitements qu'ils leur font subir pourraient ne pas fonctionner correctement ou causer des problèmes de sécurité ; les autres systèmes qui n'attribuent aucune fonction spéciale à ces caractères doivent en revanche les accepter comme valides et les conserver comme partie intégrante des textes, comme s'il s'agissait de symboles graphiques, même s'ils ne savent pas les afficher correctement.
Les non-caractères sont des points de code valides, mais ils ne sont pas (et ne seront jamais) assignés à des caractères standardisés. Leur usage dans le codage de textes transmis entre systèmes (même si identiques) est interdit, car il est impossible de les rendre compatibles avec les formes de transformation universelles standardisées (dont UTF-8, UTF-16, UTF-32) les schémas de codage correspondants, et les autres codages standardisés compatibles avec Unicode et Modèle:Nobr (BOCU-1, SCSU, différentes versions de la norme chinoise Modèle:NobrModèle:Etc.). Toutefois, certains systèmes les génèrent et les utilisent localement, mais pour un traitement strictement interne destiné à faciliter l'implémentation des algorithmes de traitement de textes utilisant les autres caractères standardisés.
Parmi ces derniers non-caractères figurent les points de code valides mais réservés aux demi-zones (privées ou non). Ces points de code ne peuvent pas être utilisés individuellement pour coder un caractère. Ils servent uniquement pour la forme de transformation universelle UTF-16 (et les schémas de codage correspondants) pour représenter sur deux codets (à Modèle:Nombre chacun) des points de code valides dans un des Modèle:Nombre complémentaires (certaines combinaisons de codets correspondent à des caractères valides de ces plans, standards ou privés, d'autres combinaisons peuvent ne représenter aucun caractère valide car elles correspondraient à des non-caractères de ces plans complémentaires, et sont donc interdites dans les textes conformes à la norme).
Les autres zones libres (non assignées à un bloc nommé standardisé, ou les points de code laissés libres et réservés dans les blocs nommés existants) sont réservées pour un usage ultérieur dans des versions futures d'Unicode et Modèle:Nobr, 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
Voir aussi
Liens externes
- The World’s Writing Systems, Les 294 systèmes d'écritures au monde connus et leur statut Unicode (131 non-encore encodés).
Références normatives
- Modèle:Lien web — page d’accueil du site officiel.
- Modèle:Lien web — lien permanent vers la dernière version publiée de la norme Unicode.
- Modèle:Lien web — collection de documents PDF.
- {{#invoke:Langue|indicationDeLangue}} Modèle:Lien web — collection de documents PDF.
- Modèle:Lien web — annexes normalisées, normes techniques et rapport techniques (dont certains pour d'anciennes versions d’Unicode).
- Modèle:Lien web — liste officielle des références utilisées dans la norme Unicode.
- Modèle:Lien web — algorithme d'ordonnancement normalisé Unicode (pour le tri, la reconnaissance ou la recherche de texte).
- Modèle:Lien web — lien permanent vers la dernière version publiée de la norme Unicode.
- {{#invoke:Langue|indicationDeLangue}} Modèle:Langue — standard de l’IETF (Modèle:Date-) ; remplace [[:rfc:2279|Modèle:Nobr]] (obsolète).
Références informatives
- {{#invoke:Langue|indicationDeLangue}} Traduction française officielle des normes Modèle:Nobr et Unicode.
- {{#invoke:Langue|indicationDeLangue}} Modèle:Nobr en pratique, par Patrick Andries, paru chez Dunod (Modèle:Date-) — ouvrage de référence.
- {{#invoke:Langue|indicationDeLangue}} Modèle:Langue — expérimental (Modèle:Date-)
- {{#invoke:Langue|indicationDeLangue}} Modèle:Langue — expérimental (Modèle:Date-) ; remplace RFC 1642 (obsolète)
- {{#invoke:Langue|indicationDeLangue}} Modèle:Langue — informatif (Modèle:Date-)
- {{#invoke:Langue|indicationDeLangue}} Modèle:Langue — informatif (Modèle:Date-)
- {{#invoke:Langue|indicationDeLangue}} Modèle:Langue — standard proposé ; remplace RFC 3490 et RFC 3491 (obsolètes), met à jour RFC 3492 Punycode
- {{#invoke:Langue|indicationDeLangue}} Unicode — The Movie Tous les Modèle:Nombre de Modèle:Nobr dans un seul film
Tables et données tierces de mise en œuvre ou d'utilisation
- {{#invoke:Langue|indicationDeLangue}} Modèle:Langue : inventaire de Modèle:Nombre (Modèle:Date-) et des caractères qu'elles comprennent.
- {{#invoke:Langue|indicationDeLangue}} Modèle:Langue, 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.
- {{#invoke:Langue|indicationDeLangue}} {{#invoke:Langue|indicationDeLangue}} Modèle:Langue, Wiki recensant et commentant tous les Modèle:Nombre d'Unicode en images.
- {{#invoke:Langue|indicationDeLangue}} CoeurLumiere.com, simple table des caractères Unicode de U+0000 à U+FFFF (attention, certains sont invalides en HTML et ne sont pas signalés).
Guides d'utilisation
- {{#invoke:Langue|indicationDeLangue}} Markus Kuhn, Modèle:Langue
- {{#invoke:Langue|indicationDeLangue}} Comment utiliser Unicode sur les systèmes libres GNU/Linux ou compatibles.
- {{#invoke:Langue|indicationDeLangue}} Modèle:Nobr du livre Fontes et codages.
- {{#invoke:Langue|indicationDeLangue}} La saisie et l'échange de caractères phonétiques avec Unicode, à l'usage des novices.
- {{#invoke:Langue|indicationDeLangue}} Exemple d'utilisation d'Unicode et tests.
- {{#invoke:Langue|indicationDeLangue}} Vos applications Web en Unicode, (article et tutoriel sur la mise en pratique d'Unicode avec PHP et MySQL ainsi que l'implémentation côté client dans les documents XML, HTML et CSS)
Discussions et articles
- {{#invoke:Langue|indicationDeLangue}} Unicode, écriture du monde ? (Modèle:Vol. (2003) de la revue Document numérique, Modèle:Nombre). Intérêt : points de vue critiques (typographes, informaticiens, égyptologuesModèle:Etc.) et entretien avec Ken Whistler, directeur technique du Consortium Unicode.
- {{#invoke:Langue|indicationDeLangue}} Otfried Cheong, UniHan (article sur les problèmes d'unification des sinogrammes avec UniHan dans Unicode)
