Unicode

Un article de Wikipédia, l'encyclopédie libre
Aller à la navigation Aller à la recherche

Unicode est une norme de technologie de l'information pour l' encodage , la représentation et la gestion cohérents du texte exprimé dans la plupart des systèmes d'écriture du monde . La norme est maintenue par le Consortium Unicode et, en mars 2020 , elle comptait un total de 143859 caractères, avec Unicode 13.0 (ces caractères se composent de 143696 caractères graphiques et 163 caractères de format) couvrant 154 scripts modernes et historiques , ainsi que plusieurs jeux de symboles et emoji . Le répertoire de caractères de la norme Unicode est synchronisé avec ISO / CEI 10646, chacun étant code à code identique à l'autre.

La norme Unicode se compose d'un ensemble de graphiques de code pour la référence visuelle, d'une méthode de codage et d'un ensemble de codages de caractères standard , d'un ensemble de fichiers de données de référence et d'un certain nombre d'éléments connexes, tels que les propriétés des caractères, les règles de normalisation , la décomposition, le classement , rendu et ordre d'affichage du texte bidirectionnel (pour l'affichage correct du texte contenant à la fois des scripts de droite à gauche , tels que l' arabe et l' hébreu , et des scripts de gauche à droite). [1]

Le succès d'Unicode dans l'unification des jeux de caractères a conduit à son utilisation répandue et prédominante dans l' internationalisation et la localisation de logiciels informatiques . La norme a été mise en œuvre dans de nombreuses technologies récentes, notamment les systèmes d'exploitation modernes , XML , Java (et d'autres langages de programmation ) et .NET Framework .

Unicode peut être implémenté par différents encodages de caractères. La norme Unicode définit les formats de transformation Unicode (UTF) UTF-8 , UTF-16 et UTF-32 , ainsi que plusieurs autres encodages. Les encodages les plus couramment utilisés sont UTF-8, UTF-16 et UCS -2 (un précurseur de UTF-16 sans prise en charge complète d'Unicode); GB18030 est normalisé en Chine et implémente entièrement Unicode, bien qu'il ne s'agisse pas d'une norme Unicode officielle.

UTF-8, le codage dominant sur le World Wide Web (utilisé dans plus de 95% des sites Web à partir de 2020 , et jusqu'à 100% pour certaines langues) [2] utilise un octet [note 1] pour les 128 premiers points de code , et jusqu'à 4 octets pour les autres caractères. [3] Les 128 premiers points de code Unicode représentent les caractères ASCII , ce qui signifie que tout texte ASCII est également un texte UTF-8.

UCS-2 utilise deux octets (16  bits ) pour chaque caractère, mais ne peut coder que les 65 536 premiers points de code , le soi-disant plan multilingue de base (BMP). Avec 1 112 064 points de code Unicode possibles correspondant à des caractères (voir ci - dessous ) sur 17 plans, et avec plus de 143 000 points de code définis à partir de la version 13.0, UCS-2 ne peut représenter que moins de la moitié de tous les caractères Unicode encodés. Par conséquent, UCS-2 est obsolète, bien que toujours largement utilisé dans les logiciels. UTF-16 étend UCS-2, en utilisant le même codage 16 bits que UCS-2 pour le plan multilingue de base, et un codage 4 octets pour les autres plans. Tant qu'il ne contient aucun point de code dans la plage réservée U + D800 – U + DFFF, [clarification nécessaire ]un texte UCS-2 est un texte UTF-16 valide.

UTF-32 (également appelé UCS-4) utilise quatre octets pour coder un point de code donné, mais pas nécessairement un caractère perçu par l'utilisateur donné (en gros, un graphème ), car un caractère perçu par l'utilisateur peut être représenté par un graphème cluster (une séquence de plusieurs points de code). [4] Comme UCS-2, le nombre d'octets par point de code est fixe, ce qui facilite l'indexation des caractères; mais contrairement à UCS-2, UTF-32 est capable d'encoder tous les points de code Unicode. Cependant, étant donné que chaque caractère utilise quatre octets, UTF-32 prend beaucoup plus d'espace que les autres encodages et n'est pas largement utilisé. Des exemples d'UTF-32 étant également de longueur variable (comme tous les autres encodages), tandis que dans un sens différent incluent: " Devanagari kshiest codé par 4 points de code [..] Les emojis de drapeau sont également des grappes de graphèmes et composés de deux caractères de point de code - par exemple, le drapeau du Japon " [5] et toutes les" séquences de caractères combinant sont des graphèmes, mais il existe d'autres séquences de des points de code qui le sont aussi; par exemple \ r \ n est un. " [6] [7] [8] [9]

Origine et développement [ modifier ]

Unicode a pour objectif explicite de transcender les limites des encodages de caractères traditionnels, tels que ceux définis par la norme ISO / CEI 8859 , qui sont largement utilisés dans divers pays du monde mais restent largement incompatibles les uns avec les autres. De nombreux encodages de caractères traditionnels partagent un problème commun en ce qu'ils permettent un traitement informatique bilingue (utilisant généralement des caractères latins et le script local), mais pas un traitement informatique multilingue (traitement informatique de scripts arbitraires mélangés les uns aux autres).

Unicode, dans l'intention, encode les caractères sous-jacents ( graphèmes et unités de type graphème) plutôt que les variantes de glyphes (rendus) pour ces caractères. Dans le cas des caractères chinois , cela conduit parfois à des controverses sur la distinction du caractère sous-jacent de ses variantes de glyphes (voir l' unification des Han ).

Dans le traitement de texte, Unicode joue le rôle de fournir un point de code unique - un nombre , pas un glyphe - pour chaque caractère. En d'autres termes, Unicode représente un caractère de manière abstraite et laisse le rendu visuel (taille, forme, police ou style) à d'autres logiciels, tels qu'un navigateur Web ou un traitement de texte . Ce simple objectif devient cependant compliqué à cause des concessions faites par les concepteurs d'Unicode dans l'espoir d'encourager une adoption plus rapide d'Unicode.

Les 256 premiers points de code ont été rendus identiques au contenu de l' ISO / CEI 8859-1 afin de rendre trivial la conversion du texte occidental existant. De nombreux caractères essentiellement identiques ont été encodés plusieurs fois à différents points de code pour préserver les distinctions utilisées par les encodages hérités et par conséquent, permettre la conversion de ces encodages en Unicode (et inversement) sans perdre aucune information. Par exemple, la section " formes pleine largeur " des points de code comprend un double complet de l'alphabet latin car les polices chinoises, japonaises et coréennes ( CJK ) contiennent deux versions de ces lettres, "pleine largeur" ​​correspondant à la largeur des caractères CJK, et largeur normale. Pour d'autres exemples, consultez les caractères en double dans Unicode .

Histoire [ modifier ]

Sur la base des expériences avec le Xerox Character Code Standard (XCCS) depuis 1980, [10] les origines d'Unicode remontent à 1987, lorsque Joe Becker de Xerox avec Lee Collins et Mark Davis d' Apple , a commencé à étudier les aspects pratiques de la création d'un jeu de caractères universel . [11] Avec l'entrée supplémentaire de Peter Fenwick et Dave Opstad, [10] Joe Becker a publié un projet de proposition pour un "système de codage de caractère de texte international / multilingue en août 1988, provisoirement appelé Unicode". Il a expliqué que "[l] e nom 'Unicode' est destiné à suggérer un codage unique, unifié et universel". [dix]

Dans ce document, intitulé Unicode 88 , Becker décrit un modèle de caractères 16 bits : [10]

Unicode est destiné à répondre au besoin d'un encodage de texte mondial fonctionnel et fiable. Unicode pourrait être grossièrement décrit comme un "ASCII à corps large" qui a été étendu à 16 bits pour englober les caractères de toutes les langues vivantes du monde. Dans une conception correctement conçue, 16 bits par caractère sont plus que suffisants à cet effet.

Sa conception originale de 16 bits était basée sur l'hypothèse que seuls les scripts et les caractères en usage moderne auraient besoin d'être encodés: [10]

Unicode donne une priorité plus élevée à assurer l'utilité pour l'avenir qu'à la préservation des antiquités passées. Unicode vise en premier lieu les caractères publiés dans le texte moderne (par exemple dans l'union de tous les journaux et magazines imprimés dans le monde en 1988), dont le nombre est sans doute bien inférieur à 2 14 = 16 384. Au-delà de ces caractères à usage moderne, tous les autres peuvent être définis comme obsolètes ou rares; ce sont de meilleurs candidats pour l'enregistrement à usage privé que pour encombrer la liste publique d'Unicodes généralement utiles.

Au début de 1989, le groupe de travail Unicode s'est élargi pour inclure Ken Whistler et Mike Kernaghan de Metaphor, Karen Smith-Yoshimura et Joan Aliprand de RLG et Glenn Wright de Sun Microsystems , et en 1990, Michel Suignard et Asmus Freytag de Microsoft et Rick McGowan de NeXT a rejoint le groupe. À la fin de 1990, la plupart des travaux de mappage des normes de codage de caractères existantes étaient terminés et un projet de révision finale d'Unicode était prêt.

Le Consortium Unicode a été incorporé en Californie le 3 janvier 1991, [12] et en octobre 1991, le premier volume de la norme Unicode a été publié. Le deuxième volume, couvrant les idéogrammes han, a été publié en juin 1992.

En 1996, un mécanisme de caractères de substitution a été implémenté dans Unicode 2.0, de sorte qu'Unicode n'était plus limité à 16 bits. Cela a augmenté l'espace de code Unicode à plus d'un million de points de code, ce qui a permis le codage de nombreux scripts historiques (par exemple, les hiéroglyphes égyptiens ) et des milliers de caractères rarement utilisés ou obsolètes qui n'avaient pas été anticipés comme nécessitant un codage. Parmi les caractères non destinés à l'origine à Unicode se trouvent des caractères Kanji ou chinois rarement utilisés, dont beaucoup font partie des noms de personnes et de lieux, ce qui les rend rarement utilisés, mais beaucoup plus essentiels que ce qui était envisagé dans l'architecture originale d'Unicode. [13]

La spécification Microsoft TrueType version 1.0 de 1992 a utilisé le nom Apple Unicode au lieu d' Unicode pour l'ID de plate-forme dans la table de dénomination.

Consortium Unicode [ edit ]

Le Consortium Unicode est une organisation à but non lucratif qui coordonne le développement d'Unicode. Les membres à part entière comprennent la plupart des principales sociétés de logiciels et de matériel informatique intéressées par les normes de traitement de texte, notamment Adobe , Apple , Facebook , Google , IBM , Microsoft , Netflix et SAP SE . [14]

Au fil des ans, plusieurs pays ou agences gouvernementales ont été membres du Consortium Unicode. Actuellement, seul le Ministère des dotations et des affaires religieuses (Oman) est membre à part entière avec droit de vote. [14]

Le Consortium a pour objectif ambitieux de remplacer à terme les schémas de codage de caractères existants par Unicode et ses schémas UTF (Unicode Transformation Format) standard, car de nombreux schémas existants sont limités en taille et en portée et sont incompatibles avec les environnements multilingues .

Scripts couverts [ modifier ]

De nombreuses applications modernes peuvent rendre un sous-ensemble substantiel des nombreux scripts en Unicode , comme le montre cette capture d'écran de l' application OpenOffice.org .

Unicode couvre presque tous les scripts ( systèmes d'écriture ) actuellement utilisés. [15] [ échec de la vérification ] [16]

Un total de 154 scripts sont inclus dans la dernière version d'Unicode (couvrant les alphabets , abugidas et syllabaires ), bien qu'il existe encore des scripts qui ne sont pas encore encodés, en particulier ceux principalement utilisés dans des contextes historiques, liturgiques et académiques. D'autres ajouts de caractères aux scripts déjà codés, ainsi que des symboles, en particulier pour les mathématiques et la musique (sous forme de notes et de symboles rythmiques), se produisent également.

Le Comité de la feuille de route Unicode ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran [17] ) tient à jour la liste des scripts qui sont des candidats ou des candidats potentiels pour l’encodage et leurs attributions de blocs de code provisoires sur la page Feuille de route Unicode du site Web du consortium Unicode . Pour certains scripts de la feuille de route, tels que le petit script Jurchen et Khitan , des propositions d'encodage ont été faites et ils progressent tout au long du processus d'approbation. Pour d'autres scripts, tels que Mayan (en plus des nombres) et Rongorongo, aucune proposition n'a encore été faite et ils attendent un accord sur le répertoire des personnages et d'autres détails de la part des communautés d'utilisateurs concernées.

Certains scripts modernes inventés qui n'ont pas encore été inclus dans Unicode (par exemple, Tengwar ) ou qui ne sont pas admissibles à l'inclusion dans Unicode en raison d'un manque d'utilisation dans le monde réel (par exemple, Klingon ) sont répertoriés dans le registre Unicode ConScript , avec mais les affectations de codes des zones à usage privé largement utilisées .

Il existe également une initiative de police médiévale Unicode axée sur les caractères latins médiévaux spéciaux. Une partie de ces propositions a déjà été incluse dans Unicode.

La Script Encoding Initiative , un projet dirigé par Deborah Anderson à l' Université de Californie à Berkeley a été fondée en 2002 dans le but de financer des propositions de scripts non encore encodés dans la norme. Le projet est devenu une source majeure d'ajouts proposés à la norme ces dernières années. [18]

Versions [ modifier ]

Unicode est développé en collaboration avec l' Organisation internationale de normalisation et partage le répertoire de caractères avec ISO / CEI 10646 : le jeu de caractères universel. Unicode et ISO / CEI 10646 fonctionnent de manière équivalente en tant que codages de caractères, mais la norme Unicode contient beaucoup plus d'informations pour les implémenteurs, couvrant - en profondeur - des sujets tels que le codage au niveau du bit, le classement et le rendu. La norme Unicode énumère une multitude de propriétés de caractère, y compris celles nécessaires pour prendre en charge le texte bidirectionnel . Les deux normes utilisent une terminologie légèrement différente.

Le Consortium Unicode a publié pour la première fois The Unicode Standard en 1991 ( version 1.0 ), et a publié régulièrement de nouvelles versions depuis lors.

La dernière version , et donc la seule valide, est la version 13.0 . Il a été publié en mars 2020 et est entièrement publié sur le site Web du consortium.

En avril 2020, la version 14.0 prévue a été reportée de six mois entre sa sortie initiale de mars 2021 en raison de la pandémie COVID-19 et septembre 2021, [19] Elle ajoutera au moins 5 nouveaux scripts, ainsi que 37 nouveaux personnages emoji . [20]

En tant que publication de livre formelle et complète (y compris les graphiques de code), la dernière version était la version 5.0 (2006). Depuis la version 5.2, la spécification de base de la norme a été publiée sous forme de livre de poche imprimé à la demande. [21] Le texte complet de chaque version de la norme, y compris la spécification de base, les annexes standard et les tableaux de codes, est disponible gratuitement au format PDF sur le site Web Unicode.

Jusqu'à présent, les versions majeures et mineures suivantes de la norme Unicode ont été publiées. Les versions de mise à jour, qui n'incluent aucune modification du répertoire de caractères, sont indiquées par le troisième chiffre (par exemple, «version 4.0.1») et sont omises dans le tableau ci-dessous. [22]

  1. ^ Le nombre de caractères indiqués pour chaque version d'Unicode est le nombre total de caractères graphiques etformat (c.exception des caractères à usage privé , les caractères de contrôle , non - caractères et des points de code de substitution ).

Architecture et terminologie [ modifier ]

La norme Unicode définit un espace de code, [54] un ensemble de valeurs numériques allant de 0 à 10FFFF 16 , [55] appelé points de code [56] et noté U + 0000 à U + 10FFFF ("U +" plus la valeur du point de code en hexadécimal , précédé de zéros non significatifs pour aboutir à un minimum de quatre chiffres, par exemple U + 00F7 pour le signe de division, ÷, contre U + 13254 pour le hiéroglyphe égyptien désignant un abri de roseaux ou un mur sinueux ( ) [57 ] ), respectivement. Parmi ces 2 16 + 2 20les points de code définis, les points de code de U + D800 à U + DFFF, qui sont utilisés pour coder des paires de substitution en UTF-16 , sont réservés par la norme et ne peuvent pas être utilisés pour coder des caractères valides, ce qui donne un total net de 2 16 - 2 11 + 2 20 = 1.112.064 points de code possibles correspondant à des caractères Unicode valides. Tous ces points de code ne correspondent pas nécessairement à des caractères visibles; plusieurs, par exemple, sont affectés à des codes de contrôle tels que le retour chariot .

Avions de code et blocs [ modifier ]

L'espace de code Unicode est divisé en dix-sept plans , numérotés de 0 à 16:

Tous les points de code dans le BMP sont accessibles en tant qu'unité de code unique en codage UTF-16 et peuvent être codés en un, deux ou trois octets en UTF-8 . Les points de code dans les plans 1 à 16 ( plans supplémentaires ) sont accessibles en tant que paires de substitution en UTF-16 et codés en quatre octets en UTF-8.

Dans chaque plan, les caractères sont alloués dans des blocs nommés de caractères associés. Bien que les blocs aient une taille arbitraire, ils sont toujours un multiple de 16 points de code et souvent un multiple de 128 points de code. Les caractères requis pour un script donné peuvent être répartis sur plusieurs blocs différents.

Propriété générale Catégorie [ edit ]

Chaque point de code a une seule propriété de catégorie générale . Les principales catégories sont indiquées: Lettre, Marque, Nombre, Ponctuation, Symbole, Séparateur et Autre. Au sein de ces catégories, il y a des subdivisions. Dans la plupart des cas, d'autres propriétés doivent être utilisées pour spécifier suffisamment les caractéristiques d'un point de code. Les catégories générales possibles sont:

Les points de code de la plage U + D800 – U + DBFF (1 024 points de code) sont appelés points de code de substitution élevée, et les points de code de la plage U + DC00 – U + DFFF (1 024 points de code) sont appelés points de code de substitution faible. les points de code. Un point de code de substitution élevée suivi d'un point de code de substitution faible forme une paire de substitution en UTF-16 pour représenter des points de code supérieurs à U + FFFF. Sinon, ces points de code ne peuvent pas être utilisés (cette règle est souvent ignorée dans la pratique, surtout lorsque vous n'utilisez pas UTF-16).

Il est garanti qu'un petit ensemble de points de code ne sera jamais utilisé pour coder des caractères, bien que les applications puissent utiliser ces points de code en interne si elles le souhaitent. Il y a soixante-six de ces non- caractères : U + FDD0 – U + FDEF et tout point de code se terminant par la valeur FFFE ou FFFF (c'est-à-dire, U + FFFE, U + FFFF, U + 1FFFE, U + 1FFFF, ... U + 10FFFE, U + 10FFFF). L'ensemble des non-caractères est stable et aucun nouveau non-caractère ne sera jamais défini. [58] Comme les substituts, la règle selon laquelle ceux-ci ne peuvent pas être utilisés est souvent ignorée, bien que l'opération de la marque d'ordre d'octet suppose que U + FFFE ne sera jamais le premier point de code dans un texte.

En excluant les substituts et les non-caractères, il reste 1 111 998 points de code utilisables.

Les points de code à usage privé sont considérés comme des caractères attribués, mais ils n'ont aucune interprétation spécifiée par la norme Unicode [59], de sorte que tout échange de ces caractères nécessite un accord entre l'expéditeur et le destinataire sur leur interprétation. Il existe trois zones à usage privé dans l'espace de code Unicode:

  • Zone d'utilisation privée: U + E000 – U + F8FF (6 400 caractères),
  • Zone d'utilisation privée supplémentaire-A: U + F0000 – U + FFFFD (65 534 caractères),
  • Zone d'utilisation privée supplémentaire-B: U + 100000 – U + 10FFFD (65 534 caractères).

Les caractères graphiques sont des caractères définis par Unicode pour avoir une sémantique particulière, et soit ont une forme de glyphe visible , soit représentent un espace visible. Depuis Unicode 13.0, il y a 143 696 caractères graphiques.

Les caractères de format sont des caractères qui n'ont pas d'apparence visible, mais qui peuvent avoir un effet sur l'apparence ou le comportement des caractères voisins. Par exemple, U + 200C ZERO WIDTH NON-JOINER et U + 200D ZERO WIDTH JOINER peuvent être utilisés pour modifier le comportement de mise en forme par défaut des caractères adjacents (par exemple, pour inhiber les ligatures ou demander la formation de ligatures). Il y a 163 caractères de format dans Unicode 13.0.

Soixante-cinq points de code (U + 0000 – U + 001F et U + 007F – U + 009F) sont réservés comme codes de commande et correspondent aux codes de commande C0 et C1 définis dans l' ISO / CEI 6429 . U + 0009 (Tab), U + 000A (Line Feed) et U + 000D (Carriage Return) sont largement utilisés dans les textes codés Unicode. Dans la pratique, les points de code C1 sont souvent mal traduits ( mojibake ) en tant que caractères Windows-1252 hérités utilisés par certains textes anglais et d'Europe occidentale.

Les caractères graphiques, les caractères de format, les caractères de code de contrôle et les caractères à usage privé sont connus collectivement comme des caractères attribués . Les points de code réservés sont les points de code qui sont disponibles pour une utilisation, mais qui ne sont pas encore attribués. Depuis Unicode 13.0, 830 606 points de code sont réservés.

Résumé des caractères [ modifier ]

L'ensemble des caractères graphiques et de format définis par Unicode ne correspond pas directement au répertoire de caractères abstraits qui est représentable sous Unicode. Unicode code les caractères en associant un caractère abstrait à un point de code particulier. [60] Cependant, tous les caractères abstraits ne sont pas codés comme un seul caractère Unicode, et certains caractères abstraits peuvent être représentés en Unicode par une séquence de deux caractères ou plus. Par exemple, une lettre minuscule latine «i» avec un ogonek , un point au - dessus et un accent aigu , qui est obligatoire en lituanien, est représenté par la séquence de caractères U + 012F, U + 0307, ​​U + 0301. Unicode gère une liste de séquences de caractères nommées de manière unique pour les caractères abstraits qui ne sont pas directement encodés en Unicode. [61]

Tous les caractères graphiques, de format et à usage privé ont un nom unique et immuable par lequel ils peuvent être identifiés. Cette immuabilité est garantie depuis la version Unicode 2.0 par la politique de stabilité des noms. [58] Dans les cas où le nom est gravement défectueux et trompeur, ou comporte une grave erreur typographique, un alias formel peut être défini et les candidatures sont encouragées à utiliser l'alias formel à la place du nom officiel du caractère. Par exemple, U + A015YI SYLLABLE WU a l'alias formel YI SYLLABLE ITERATION MARK , et U + FE18PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRA KC ET ( sic ) a l'alias formel FORMULAIRE DE PRESENTATION POUR FREINS LENTILLES VERTICAUX DROITS BLANC CK ET . [62]

Prémontés par rapport à caractères composites [ modifier ]

Unicode inclut un mécanisme de modification des caractères qui étend considérablement le répertoire de glyphes pris en charge. Cela couvre l'utilisation de la combinaison de signes diacritiques qui peuvent être ajoutés après le caractère de base par l'utilisateur. Plusieurs signes diacritiques de combinaison peuvent être appliqués simultanément au même caractère. Unicode contient également des versions précomposées de la plupart des combinaisons lettre / diacritique en utilisation normale. Celles-ci simplifient la conversion vers et à partir des encodages hérités et permettent aux applications d'utiliser Unicode comme format de texte interne sans avoir à implémenter la combinaison de caractères. Par exemple, é peut être représenté en Unicode par U + 0065 ( LETTRE MINUSCULE LATINE E ) suivi de U + 0301 ( COMBINAISON D'ACCENT AIGU), mais il peut également être représenté par le caractère précomposé U + 00E9 ( LETTRE MINUSCULE LATINE E AVEC AIGU ). Ainsi, dans de nombreux cas, les utilisateurs ont plusieurs façons d'encoder le même caractère. Pour faire face à cela, Unicode fournit le mécanisme d' équivalence canonique .

Un exemple de cela se produit avec le Hangul , l'alphabet coréen. Unicode fournit un mécanisme pour composer des syllabes Hangul avec leurs sous-composants individuels, connus sous le nom de Hangul Jamo . Cependant, il fournit également 11 172 combinaisons de syllabes précomposées à partir du jamo le plus courant.

Les caractères CJK ont actuellement des codes uniquement pour leur forme précomposée. Pourtant, la plupart de ces caractères comprennent des éléments plus simples (appelés radicaux ), donc en principe Unicode aurait pu les décomposer comme il l'a fait avec Hangul. Cela aurait considérablement réduit le nombre de points de code requis, tout en permettant l'affichage de pratiquement tous les caractères imaginables (ce qui pourrait éliminer certains des problèmes causés par l' unification Han ). Une idée similaire est utilisée par certaines méthodes d'entrée , telles que Cangjie et Wubi . Cependant, les tentatives de le faire pour le codage des caractères ont échoué sur le fait que les caractères chinois ne se décomposent pas aussi simplement ou aussi régulièrement que le Hangul.

Un ensemble de radicaux a été fourni en Unicode 3.0 (radicaux CJK entre U + 2E80 et U + 2EFF, radicaux KangXi en U + 2F00 à U + 2FDF et caractères de description idéographique de U + 2FF0 à U + 2FFB), mais le standard Unicode (ch.12.2 d'Unicode 5.2) met en garde contre l'utilisation de séquences de description idéographique comme représentation alternative pour les caractères précédemment encodés:

Ce processus est différent d'un encodage formel d'un idéogramme. Il n'y a pas de description canonique des idéogrammes non codés; il n'y a pas de sémantique assigné aux idéogrammes décrits; il n'y a pas d'équivalence définie pour les idéogrammes décrits. Conceptuellement, les descriptions idéographiques s'apparentent davantage à l'expression anglaise "un 'e' avec un accent aigu dessus" qu'à la séquence de caractères <U + 0065, U + 0301>.

Ligatures [ modifier ]

De nombreux scripts, y compris l' arabe et le devanāgarī , ont des règles orthographiques spéciales qui exigent que certaines combinaisons de formes de lettres soient combinées dans des formes de ligatures spéciales . Les règles régissant la formation des ligatures peuvent être assez complexes, nécessitant des technologies spéciales de mise en forme de script telles que ACE (Arabic Calligraphic Engine by DecoType dans les années 1980 et utilisé pour générer tous les exemples arabes dans les éditions imprimées du standard Unicode), qui en est devenu la preuve. de concept pour OpenType (par Adobe et Microsoft), Graphite (par SIL International ) ou AAT (par Apple).

Des instructions sont également intégrées dans les polices pour indiquer au système d'exploitationcomment produire correctement différentes séquences de caractères. Une solution simple au placement de la combinaison de marques ou de signes diacritiques consiste à attribuer aux marques une largeur de zéro et à placer le glyphe lui-même à gauche ou à droite du relèvement latéral gauche (en fonction de la direction du script avec lequel ils sont destinés à être utilisés). Une marque gérée de cette façon apparaîtra sur le caractère qui la précède, mais n'ajustera pas sa position par rapport à la largeur ou à la hauteur du glyphe de base; il peut être visuellement gênant et il peut chevaucher certains glyphes. L'empilement réel est impossible, mais peut être approximé dans des cas limités (par exemple, les voyelles et les marques de ton thaïlandaises combinant le haut peuvent simplement être à des hauteurs différentes pour commencer). En général, cette approche n'est efficace que dans les polices à espacement fixe, mais peut être utilisée comme méthode de rendu de secours lorsque des méthodes plus complexes échouent.

Sous - ensembles standardisés [ modifier ]

Plusieurs sous-ensembles d'Unicode sont standardisés: Microsoft Windows depuis Windows NT 4.0 prend en charge WGL-4 avec 657 caractères, qui est considéré comme prenant en charge toutes les langues européennes contemporaines utilisant l'écriture latine, grecque ou cyrillique. D'autres sous-ensembles normalisés d'Unicode comprennent les sous-ensembles européens multilingues: [63]

MES-1 (scripts latins uniquement, 335 caractères), MES-2 (caractères latins, grecs et cyrilliques 1062) [64] et MES-3A et MES-3B (deux sous-ensembles plus grands, non représentés ici). Notez que MES-2 inclut tous les caractères de MES-1 et WGL-4.

Un logiciel de rendu qui ne peut pas traiter un caractère Unicode de manière appropriée l'affiche souvent sous la forme d'un rectangle ouvert, ou du «caractère de remplacement » Unicode (U + FFFD, ), pour indiquer la position du caractère non reconnu. Certains systèmes ont tenté de fournir plus d'informations sur ces caractères. Apple dernière , la police Resort affiche un glyphe de remplacement indiquant la plage Unicode du caractère, et le SIL International de la police Unicode Fallback affiche une boîte montrant la valeur scalaire hexadécimale du caractère.

Cartographie et encodages [ modifier ]

Plusieurs mécanismes ont été spécifiés pour stocker une série de points de code sous la forme d'une série d'octets.

Unicode définit deux méthodes de mappage: les codages UTF ( Unicode Transformation Format ) et les codages UCS ( Universal Coded Character Set ). Un codage mappe (éventuellement un sous-ensemble de) la plage de code Unicode pointe vers des séquences de valeurs dans une plage de taille fixe, appelées unités de code . Tous les codages UTF mappent des points de code vers une séquence d'octets unique. [65] Les nombres dans les noms des codages indiquent le nombre de bits par unité de code (pour les codages UTF) ou le nombre d'octets par unité de code (pour les codages UCS et UTF-1). UTF-8 et UTF-16 sont les encodages les plus couramment utilisés. UCS-2 est un sous-ensemble obsolète de UTF-16; UCS-4 et UTF-32 sont fonctionnellement équivalents.

Les encodages UTF incluent:

  • UTF-1 , un ancien prédécesseur de l'UTF-8, maximise la compatibilité avec ISO 2022 , qui ne fait plus partie de la norme Unicode
  • UTF-7 , un encodage 7 bits obsolète parfois utilisé dans les e-mails (ne fait pas partie du standard Unicode , mais uniquement documenté comme un RFC informatif , c'est-à-dire pas sur Internet Standards Track)
  • UTF-8 , utilise un à quatre octets pour chaque point de code, maximise la compatibilité avec ASCII
  • UTF-EBCDIC , similaire à UTF-8 mais conçu pour être compatible avec EBCDIC (ne fait pas partie de la norme Unicode )
  • UTF-16 , utilise une ou deux unités de code 16 bits par point de code, ne peut pas encoder de substituts
  • UTF-32 , utilise une unité de code 32 bits par point de code

UTF-8 utilise un à quatre octets par point de code et, étant compact pour les scripts latins et compatible ASCII, il fournit le codage standard de facto pour l'échange de texte Unicode. Il est utilisé par FreeBSD et les distributions Linux les plus récentes en remplacement direct des encodages hérités dans la gestion générale du texte.

Les codages UCS-2 et UTF-16 spécifient la marque d'ordre d'octet Unicode (BOM) à utiliser au début des fichiers texte, qui peut être utilisée pour la détection de l'ordre des octets (ou la détection de l' endianité des octets ). La nomenclature, point de code U + FEFF, a la propriété importante de non-ambiguïté lors de la réorganisation des octets, quel que soit le codage Unicode utilisé; U + FFFE (le résultat de l'échange d'octets U + FEFF) n'équivaut pas à un caractère légal, et U + FEFF à d'autres endroits, autres que le début du texte, transmet l'espace de non-coupure de largeur zéro (un caractère avec aucun aspect et aucun effet autre que la prévention de la formation de ligatures ).

Le même caractère converti en UTF-8 devient la séquence d'octets EF BB BF. La norme Unicode permet que la nomenclature «puisse servir de signature pour le texte encodé en UTF-8 où le jeu de caractères n'est pas marqué». [66] Certains développeurs de logiciels l'ont adopté pour d'autres encodages, y compris UTF-8, dans une tentative de distinguer UTF-8 des pages de codes locales à 8 bits . Cependant RFC 3629 , la norme UTF-8, recommande que les marques d'ordre des octets soient interdites dans les protocoles utilisant UTF-8, mais discute des cas où cela peut ne pas être possible. En outre, la grande restriction sur les modèles possibles en UTF-8 (par exemple, il ne peut y avoir aucun octet avec le jeu de bits haut) signifie qu'il devrait être possible de distinguer UTF-8 des autres codages de caractères sans se fier à la nomenclature.

En UTF-32 et UCS-4, une unité de code 32 bits sert de représentation assez directe du point de code de n'importe quel caractère (bien que l'endianité, qui varie selon les plates-formes, affecte la façon dont l'unité de code se manifeste comme une séquence d'octets). Dans les autres codages, chaque point de code peut être représenté par un nombre variable d'unités de code. UTF-32 est largement utilisé comme représentation interne du texte dans les programmes (par opposition au texte stocké ou transmis), car chaque système d'exploitation Unix qui utilise les compilateurs gcc pour générer des logiciels l'utilise comme codage standard à « caractères larges ». Certains langages de programmation, tels que Seed7 , utilisent UTF-32 comme représentation interne pour les chaînes et les caractères. Versions récentes de PythonLe langage de programmation (commençant par 2.2) peut également être configuré pour utiliser UTF-32 comme représentation des chaînes Unicode, diffusant efficacement un tel codage dans un logiciel codé de haut niveau .

Punycode , une autre forme de codage, permet le codage des chaînes Unicode dans le jeu de caractères limité pris en charge par le système de noms de domaine (DNS) basé sur ASCII . Le codage est utilisé dans le cadre d' IDNA , qui est un système permettant l'utilisation de noms de domaine internationalisés dans tous les scripts pris en charge par Unicode. Les propositions antérieures et désormais historiques incluent UTF-5 et UTF-6 .

GB18030 est une autre forme d'encodage pour Unicode, de la Standardization Administration of China . C'est le jeu de caractères officiel de la République populaire de Chine (RPC). BOCU-1 et SCSU sont des schémas de compression Unicode. La RFC du poisson d'avril de 2005 spécifiait deux codages UTF parodiques , UTF-9 et UTF-18 .

Adoption [ modifier ]

Systèmes d' exploitation [ modifier ]

Unicode est devenu le schéma dominant pour le traitement interne et le stockage de texte. Bien qu'une grande partie du texte soit encore stockée dans des encodages hérités, Unicode est utilisé presque exclusivement pour créer de nouveaux systèmes de traitement de l'information. Les premiers utilisateurs avaient tendance à utiliser UCS-2 (le précurseur à largeur fixe de deux octets de UTF-16) et sont ensuite passés à UTF-16 (la norme actuelle à largeur variable), car c'était la façon la moins perturbatrice d'ajouter la prise en charge de non -Caractères BMP. Le système de ce type le plus connu est Windows NT (et ses descendants, Windows 2000 , Windows XP , Windows Vista , Windows 7 , Windows 8 et Windows 10), qui utilise UTF-16 comme seul encodage de caractères interne. Les environnements de bytecode Java et .NET , macOS et KDE l' utilisent également pour la représentation interne. La prise en charge partielle d'Unicode peut être installée sur Windows 9x via Microsoft Layer pour Unicode .

UTF-8 (développé à l'origine pour Plan 9 ) [67] est devenu le principal encodage de stockage sur la plupart des systèmes d' exploitation de type Unix (bien que d'autres soient également utilisés par certaines bibliothèques) car il remplace relativement facilement les jeux de caractères ASCII étendus traditionnels . UTF-8 est également le codage Unicode le plus couramment utilisé dans les documents HTML sur le World Wide Web .

Les moteurs de rendu de texte multilingues qui utilisent Unicode incluent Uniscribe et DirectWrite pour Microsoft Windows, ATSUI et Core Text pour macOS, et Pango pour GTK + et le bureau GNOME .

Méthodes d' entrée [ modifier ]

Étant donné que les dispositions de clavier ne peuvent pas avoir de combinaisons de touches simples pour tous les caractères, plusieurs systèmes d'exploitation proposent des méthodes de saisie alternatives qui permettent d'accéder à l'ensemble du répertoire.

L'ISO / CEI 14755 , [68], qui standardise les méthodes de saisie des caractères Unicode à partir de leurs points de code, spécifie plusieurs méthodes. Il existe la méthode de base , où une séquence de début est suivie de la représentation hexadécimale du point de code et de la séquence de fin . Il existe également une méthode de saisie de sélection d'écran spécifiée, où les caractères sont répertoriés dans un tableau dans un écran, comme avec un programme de carte de caractères.

Les outils en ligne pour trouver le point de code pour un caractère connu incluent Unicode Lookup [69] par Jonathan Hedley et Shapecatcher [70] par Benjamin Milde. Dans Unicode Lookup, on entre une clé de recherche (par exemple "fractions"), et une liste des caractères correspondants avec leurs points de code est renvoyée. Dans Shapecatcher, basé sur le contexte Shape , on dessine le caractère dans une boîte et une liste de caractères se rapprochant du dessin, avec leurs points de code, est renvoyée.

Email [ modifier ]

MIME définit deux mécanismes différents pour encoder les caractères non ASCII dans les e - mails , selon que les caractères sont dans les en-têtes d'e-mails (tels que «Objet:»), ou dans le corps du texte du message; dans les deux cas, le jeu de caractères d'origine est identifié ainsi qu'un codage de transfert. Pour la transmission par e-mail d'Unicode, le jeu de caractères UTF-8 et le codage de transfert Base64 ou imprimable Quoted sont recommandés, selon que la majeure partie du message est constituée de caractères ASCII . Les détails des deux mécanismes différents sont spécifiés dans les normes MIME et sont généralement cachés aux utilisateurs de logiciels de messagerie.

L'adoption d'Unicode dans les e-mails a été très lente. Certains textes d'Asie de l'Est sont encore encodés dans des encodages tels que ISO-2022 , et certains appareils, tels que les téléphones portables, ne peuvent toujours pas gérer correctement les données Unicode. Le soutien s’est toutefois amélioré. De nombreux fournisseurs de messagerie gratuits tels que Yahoo , Google ( Gmail ) et Microsoft ( Outlook.com ) le prennent en charge.

Web [ modifier ]

Toutes les recommandations du W3C utilisent Unicode comme jeu de caractères de document depuis HTML 4.0. Les navigateurs Web prennent en charge Unicode, en particulier UTF-8, depuis de nombreuses années. Il y avait des problèmes d'affichage résultant principalement de problèmes liés aux polices ; par exemple, la version 6 et plus ancienne de Microsoft Internet Explorer n'a pas rendu de nombreux points de code à moins qu'il ne soit explicitement indiqué d'utiliser une police qui les contient. [71]

Bien que les règles de syntaxe puissent affecter l'ordre dans lequel les caractères sont autorisés à apparaître, les documents XML (y compris XHTML ), par définition, [72] comprennent des caractères de la plupart des points de code Unicode, à l'exception de:

  • la plupart des codes de contrôle C0 ,
  • les points de code D800 à DFFF non attribués de manière permanente,
  • FFFE ou FFFF.

Les caractères HTML se manifestent directement sous forme d' octets selon le codage du document, si le codage les prend en charge, ou les utilisateurs peuvent les écrire sous forme de références de caractères numériques en fonction du point de code Unicode du caractère. Par exemple, les références &#916;, &#1049;, &#1511;, &#1605;, &#3671;, &#12354;, &#21494;, &#33865;et &#47568;(ou les mêmes valeurs numériques exprimées en hexadécimal, avec &#xcomme préfixe) devrait afficher sur tous les navigateurs comme Δ, Й, ק, م, 7,あ,叶,葉et 말.

Lors de la spécification d' URI , par exemple en tant qu'URL dans les requêtes HTTP , les caractères non ASCII doivent être codés en pourcentage .

Polices [ modifier ]

Unicode n'est en principe pas concerné par les polices en soi , les considérant comme des choix d'implémentation. [73] Tout caractère donné peut avoir de nombreux allographes , des formes de lettres grasses, italiques et de base les plus courantes aux styles décoratifs complexes. Une police est «compatible Unicode» si les glyphes de la police sont accessibles à l'aide de points de code définis dans la norme Unicode. [74] La norme ne spécifie pas un nombre minimum de caractères qui doivent être inclus dans la police; certaines polices ont un répertoire assez restreint.

Les polices gratuites et commerciales basées sur Unicode sont largement disponibles, puisque TrueType et OpenType prennent en charge Unicode. Ces formats de police mappent les points de code Unicode aux glyphes, mais la police TrueType est limitée à 65 535 glyphes.

Des milliers de polices existent sur le marché, mais moins d'une douzaine de polices - parfois décrites comme des polices «pan-Unicode» - tentent de prendre en charge la majorité du répertoire de caractères Unicode. Au lieu de cela, les polices Unicode se concentrent généralement sur la prise en charge uniquement de l'ASCII de base et de scripts ou ensembles de caractères ou de symboles particuliers. Plusieurs raisons justifient cette approche: les applications et les documents ont rarement besoin de restituer les caractères de plus d'un ou deux systèmes d'écriture; les polices ont tendance à exiger des ressources dans les environnements informatiques; et les systèmes d'exploitation et les applications font preuve d'une intelligence croissante en ce qui concerne l'obtention d'informations sur les glyphes à partir de fichiers de polices séparés selon les besoins, c'est-à-dire la substitution de polices. En outre, la conception d'un ensemble cohérent d'instructions de rendu pour des dizaines de milliers de glyphes constitue une tâche monumentale; une telle entreprise dépasse le stade des rendements décroissants pour la plupart des polices.

Les nouvelles lignes [ modifier ]

Unicode résout partiellement le problème de nouvelle ligne qui se produit lors de la tentative de lecture d'un fichier texte sur différentes plates-formes. Unicode définit un grand nombre de caractères que les applications conformes doivent reconnaître comme terminateurs de ligne.

En termes de nouvelle ligne, Unicode a introduit le SEPARATEUR DE LIGNE U + 2028 et le SEPARATEUR DE PARAGRAPHE U + 2029 . Il s'agissait d'une tentative de fournir une solution Unicode pour coder les paragraphes et les lignes sémantiquement, remplaçant potentiellement toutes les différentes solutions de plate-forme. Ce faisant, Unicode fournit un moyen de contourner les solutions dépendantes de la plate-forme historique. Néanmoins, peu de solutions Unicode, voire aucune, ont adopté ces séparateurs de ligne et de paragraphe Unicode comme seuls caractères de fin de ligne canoniques. Cependant, une approche courante pour résoudre ce problème consiste à normaliser les nouvelles lignes. Ceci est réalisé avec le système de texte Cocoa sous Mac OS X et également avec les recommandations XML et HTML du W3C. Dans cette approche, chaque caractère de nouvelle ligne possible est converti en interne en une nouvelle ligne commune (ce qui n'a pas vraiment d'importance puisqu'il s'agit d'une opération interne juste pour le rendu). En d'autres termes, le système de texte peut traiter correctement le caractère comme une nouvelle ligne,quel que soit le codage réel de l'entrée.

Problèmes [ modifier ]

Critiques philosophiques et l' exhaustivité [ edit ]

L'unification des Han (l'identification des formes dans les langues d'Asie de l' Est que l'on peut traiter comme des variations stylistiques du même caractère historique) est devenue l'un des aspects les plus controversés d'Unicode, malgré la présence d'une majorité d'experts des trois régions dans le Groupe de recherche idéographique (IRG), qui conseille le Consortium et l'ISO sur les ajouts au répertoire et sur l'unification des Han. [75]

Unicode a été critiqué pour ne pas avoir codé séparément les formes anciennes et alternatives de kanji qui, selon les critiques, compliquent le traitement des noms japonais anciens et rares. Cela est souvent dû au fait qu'Unicode encode des caractères plutôt que des glyphes (les représentations visuelles du caractère de base qui varient souvent d'une langue à l'autre). L'unification des glyphes conduit à la perception que les langues elles-mêmes, et pas seulement la représentation de caractère de base, sont fusionnées. [76] [ clarification nécessaire ]Il y a eu plusieurs tentatives pour créer des encodages alternatifs qui préservent les différences stylistiques entre les caractères chinois, japonais et coréens en opposition à la politique Unicode d'unification des Han. Un exemple est TRON (bien qu'il ne soit pas largement adopté au Japon, certains utilisateurs doivent gérer le texte japonais historique et le favoriser).

Bien que le répertoire de moins de 21000 caractères Han dans la première version d'Unicode était en grande partie limité aux caractères d'usage moderne courant, Unicode comprend désormais plus de 92000 caractères Han, et le travail se poursuit pour ajouter des milliers d'autres caractères historiques et dialectaux utilisés en Chine, Japon, Corée, Taïwan et Vietnam.

La technologie de police moderne fournit un moyen de résoudre le problème pratique de la nécessité de représenter un caractère Han unifié en termes d'une collection de représentations de glyphes alternatives, sous la forme de séquences de variation Unicode . Par exemple, les tables typographiques avancées d' OpenType permettent de sélectionner l'une des nombreuses autres représentations de glyphes lors de l'exécution du processus de mappage de caractères à glyphes. Dans ce cas, des informations peuvent être fournies en texte brut pour désigner la forme de caractère alternative à sélectionner.

Différents caractères cyrilliques affichés avec et sans italique

Si la différence entre les glyphes appropriés pour deux caractères dans le même script ne diffère que par l'italique, Unicode les a généralement unifiés, comme on peut le voir dans la comparaison entre les caractères russes (étiquetés standard) et serbes à droite, ce qui signifie que les différences sont affiché grâce à la technologie de police intelligente ou à la modification manuelle des polices.

Mise en correspondance des jeux de caractères existants [ modifier ]

Unicode a été conçu pour fournir une conversion de format aller-retour de code point par point de code vers et à partir de tout encodage de caractères préexistant, de sorte que les fichiers texte des anciens jeux de caractères puissent être convertis en Unicode, puis revenir et récupérer le même fichier, sans recourir à une interprétation dépendante du contexte. Cela signifie que des architectures héritées incohérentes, telles que la combinaison de signes diacritiques et de caractères précomposés , existent toutes deux en Unicode, ce qui donne plus d'une méthode de représentation d'un texte. Ceci est le plus prononcé dans les trois formes de codage différentes pour le Hangul coréen. Depuis la version 3.0, les caractères précomposés pouvant être représentés par une séquence de combinaison de caractères déjà existants ne peuvent plus être ajoutés à la norme afin de préserver l'interopérabilité entre les logiciels utilisant différentes versions d'Unicode.

Des mappages injectifs doivent être fournis entre les caractères des jeux de caractères hérités existants et les caractères Unicode pour faciliter la conversion en Unicode et permettre l'interopérabilité avec les logiciels hérités. Le manque de cohérence dans divers mappages entre les encodages japonais antérieurs tels que Shift-JIS ou EUC-JP et Unicode a conduit à des incohérences de conversion de format aller-retour , en particulier le mappage du caractère JIS X 0208 '~' (1-33, WAVE DASH) , largement utilisé dans les données de base de données héritées, soit U + FF5EFULLWIDTH TILDE (sous Microsoft Windows ) ou U + 301CWAVE DASH (autres fournisseurs). [77]

Certains programmeurs informatiques japonais se sont opposés à Unicode car il les oblige à séparer l'utilisation de U + 005C \ REVERSE SOLIDUS (barre oblique inverse) et U + 00A5 ¥ YEN SIGN , qui a été mappé à 0x5C dans JIS X 0201, et il existe de nombreux codes hérités. avec cet usage. [78] (Cet encodage remplace également le tilde '~' 0x7E par macron '¯', maintenant 0xAF.) La séparation de ces caractères existe dans l' ISO 8859-1 , bien avant Unicode.

Scripts Indic [ modifier ]

Les scripts indiens tels que Tamil et Devanagari ne reçoivent chacun que 128 points de code, correspondant à la norme ISCII . Le rendu correct du texte Unicode Indic nécessite la transformation des caractères d'ordre logique stockés en ordre visuel et la formation de ligatures (aka conjonctives) à partir de composants. Certains chercheurs locaux ont plaidé en faveur de l'attribution de points de code Unicode à ces ligatures, ce qui va à l'encontre de la pratique pour d'autres systèmes d'écriture, bien que Unicode contienne des ligatures arabes et autres à des fins de compatibilité descendante uniquement. [79] [80] [81]L'encodage de toute nouvelle ligature en Unicode ne se produira pas, en partie parce que l'ensemble de ligatures dépend de la police et qu'Unicode est un encodage indépendant des variations de police. Le même genre de problème s'est posé pour l' écriture tibétaine en 2003 lorsque l' Administration de la normalisation de Chine a proposé de coder 956 syllabes tibétaines précomposées, [82] mais celles-ci ont été rejetées pour codage par le comité ISO compétent ( ISO / CEI JTC 1 / SC 2 ). [83]

Le support de l' alphabet thaïlandais a été critiqué pour son ordre des caractères thaïlandais. Les voyelles เ, แ, โ, ใ, ไ qui sont écrites à gauche de la consonne précédente sont dans l'ordre visuel au lieu de l'ordre phonétique, contrairement aux représentations Unicode d'autres scripts indiens. Cette complication est due au fait qu'Unicode a hérité du Thai Industrial Standard 620 , qui fonctionnait de la même manière, et était la manière dont le thaï avait toujours été écrit sur les claviers. Ce problème de classement complique légèrement le processus de classement Unicode, nécessitant des recherches de table pour réorganiser les caractères thaïlandais pour le classement. [76] Même si Unicode avait adopté le codage selon l'ordre parlé, il serait toujours problématique d'assembler les mots dans l'ordre du dictionnaire. Par exemple, le mot แสดง [sa dɛːŋ] "performer" commence par un groupe de consonnes "สด" (avec une voyelle inhérente pour la consonne "ส"), la voyelle แ -, dans l'ordre parlé viendrait après le ด, mais dans un dictionnaire, le mot est collationné comme il est écrit, avec la voyelle suivant le ส.

Les caractères composés [ modifier ]

Les caractères avec des signes diacritiques peuvent généralement être représentés soit comme un seul caractère précomposé, soit comme une séquence décomposée d'une lettre de base plus une ou plusieurs marques non espacées. Par exemple, ḗ (e précomposé avec macron et aigu ci-dessus) et ḗ (e suivi de la combinaison macron ci-dessus et combinant aigu ci-dessus) doivent être rendus de manière identique, tous deux apparaissant comme un e avec un macron et un accent aigu , mais en pratique, leur l'apparence peut varier en fonction du moteur de rendu et des polices utilisés pour afficher les caractères. De même, les points faibles , comme requis dans la romanisation d' Indic , seront souvent placés de manière incorrecte. [ citation nécessaire ]. Les caractères Unicode qui correspondent à des glyphes précomposés peuvent être utilisés dans de nombreux cas, évitant ainsi le problème, mais là où aucun caractère précomposé n'a été encodé, le problème peut souvent être résolu en utilisant une police Unicode spécialisée telle que Charis SIL qui utilise Graphite , OpenType ou Technologies AAT pour des fonctionnalités de rendu avancées.

Anomalies [ modifier ]

Le standard Unicode a imposé des règles destinées à garantir la stabilité. [84] Selon la rigueur d'une règle, une modification peut être interdite ou autorisée. Par exemple, un "nom" donné à un point de code ne peut pas et ne changera pas. Mais une propriété "script" est plus flexible, selon les propres règles d'Unicode. Dans la version 2.0, Unicode a changé de nombreux "noms" de points de code depuis la version 1. Au même moment, Unicode a déclaré qu'à partir de ce moment, un nom attribué à un point de code ne changera plus jamais. Cela implique que lorsque des erreurs sont publiées, ces erreurs ne peuvent pas être corrigées, même si elles sont insignifiantes (comme cela s'est produit dans un cas avec l'orthographe BRAKCET pour BRACKETdans un nom de personnage). En 2006, une liste d'anomalies dans les noms de caractères a été publiée pour la première fois et, en avril 2017, 94 caractères présentaient des problèmes identifiés, [85] par exemple:

  • U + 2118 SCRIPT CAPITAL P : Ceci est une petite lettre. Le capital est U + 1D4AB 𝒫 SCRIPT MATHÉMATIQUE MAJUSCULE P [86]
  • U + 034F ͏ COMBINING GRAPHEME JOINER : Ne joint pas les graphèmes. [85]
  • U + A015 YI SYLLABLE WU : Ce n'est pas une syllabe Yi, mais une marque d'itération Yi.
  • U + FE18 FORMULAIRE DE PRESENTATION POUR PLAQUE DE FREIN VERTICAL DROIT BLANC : le support est mal orthographié. [87]

Les fautes d'orthographe sont résolues à l'aide de noms d'alias et d'abréviations Unicode .

Voir aussi [ modifier ]

  • Comparaison des encodages Unicode
  • Symboles culturels, politiques et religieux en Unicode
  • Composants internationaux pour Unicode (ICU), maintenant ICU- TC une partie d'Unicode
  • Liste des codes binaires
  • Liste des caractères Unicode
  • Liste des références d'entités de caractères XML et HTML
  • Polices Unicode open-source
  • Normes liées à Unicode
  • Symboles Unicode
  • Jeu de caractères codés universels
  • Lotus Multi-Byte Character Set (LMBCS), un développement parallèle avec des intentions similaires

Notes [ modifier ]

  1. ^ Le Consortium Unicode utilise le terme ambigu octet; L' Organisation internationale de normalisation (ISO), la Commission électrotechnique internationale (CEI) et l' Internet Engineering Task Force (IETF) utilisent le terme octet plus spécifiquedans les documents actuels liés à Unicode.

Références [ modifier ]

  1. ^ "Le Standard Unicode: Une Introduction Technique" . Récupéré le 16/03/2010 .
  2. ^ "Enquête d'utilisation des encodages de caractères ventilés par Classement" . w3techs.com . Récupéré le 09/06/2020 .
  3. ^ "Conformité" (PDF) . Le standard Unicode . Mars 2020 . Récupéré le 15/03/2020 .
  4. ^ "UAX # 29: Segmentation de texte Unicode §3 Limites de grappe de graphème" . unicode.org . 2020-02-19 . Récupéré le 27 juin 2020 .
  5. ^ "Unicode - une brève introduction (avancée) • JavaScript pour les programmeurs impatients" . explorejs.com . Récupéré 14/06/2020 .
  6. ^ "Introduction à Unicode" . mathias.gaunard.com . Récupéré 14/06/2020 .
  7. ^ "Chaînes et caractères - Le langage de programmation Swift (Swift 5.2)" . docs.swift.org . Récupéré 14/06/2020 .
  8. ^ "Brisant Nos Hypothèses Latin-1 - Dans la Poursuite de la Paresse" . manishearth.github.io . Récupéré 14/06/2020 . Unicode ne voulait pas s'occuper de l'ajout de nouveaux drapeaux à chaque fois qu'un nouveau pays ou territoire apparaît. Il n'a pas non à entrer dans l'entreprise délicate de déterminer ce qu'un pays est , par exemple , lorsque le traitement des territoires contestés. [..] Sur certains systèmes chinois, par exemple, le drapeau de Taiwan (🇹🇼) peut ne pas s'afficher.
  9. ^ "Arrêtons d'attribuer un sens aux points de code - à la poursuite de la paresse" . manishearth.github.io . Récupéré 14/06/2020 . Les gens commencent à dire que les points de code signifient quelque chose et que l'indexation ou le découpage O (1) aux limites des points de code est une opération utile.
  10. ^ A b c d e Becker, Joseph D. (10/09/1998) [29/08/1988]. «Unicode 88» (PDF) . unicode.org (éd. réimpression du 10e anniversaire). Consortium Unicode . Archivé (PDF) de l'original le 25/11/2016 . Récupéré 25/10/2016 . En 1978, la proposition initiale d'un ensemble de «panneaux universels» a été faite par Bob Belleville chez Xerox PARC . De nombreuses personnes ont contribué à l'élaboration d'une nouvelle conception d'encodage. À partir de 1980, ces efforts ont évolué vers la norme Xerox Character Code Standard. (XCCS) par le présent auteur, un codage multilingue qui a été maintenu par Xerox en tant que norme interne de l'entreprise depuis 1982, grâce aux efforts d'Ed Smura, Ron Pellar et d'autres.
    Unicode est le résultat de huit années d'expérience de travail avec XCCS. Ses différences fondamentales avec XCCS ont été proposées par Peter Fenwick et Dave Opstad (codes purs à 16 bits) et par Lee Collins (unification de caractères idéographiques). Unicode conserve les nombreuses fonctionnalités de XCCS dont l'utilité a été prouvée au fil des ans dans une ligne internationale de produits de systèmes de communication multilingues.
  11. ^ "Récapitulatif récapitulatif" . Récupéré le 15/03/2010 .
  12. ^ Histoire de la sortie d'Unicode et des dates de publication sur unicode.org. Récupéré le 28 février 2017.
  13. ^ Searle, Stephen J. "Unicode Revisité" . Récupéré 18/01/2013 .
  14. ^ un b "Les Membres du Consortium Unicode" . Récupéré 04/01/2019 .
  15. ^ "Chartes de code de caractère" . Récupéré le 17/03/2010 .
  16. ^ "FAQ Unicode" . Récupéré 02/04/2020 .
  17. ^ "Feuille de route vers le BMP" . Consortium Unicode . Récupéré 30/07/2018 .
  18. ^ "À propos de l'Initiative de codage de script" . Le Consortium Unicode . Récupéré 04/06/2012 .
  19. ^ "Unicode 14.0 Retardé pendant 6 Mois" . Récupéré 05/05/2020 .
  20. ^ "Unicode 14.0.0" . www.unicode.org . Récupéré le 10 février 2021 .
  21. ^ "Unicode 6.1 Broché Disponible" . annonces_at_unicode.org . Récupéré 30/05/2012 .
  22. ^ "Versions énumérées de la norme Unicode" . Récupéré 21/06/2016 .
  23. ^ a b c
    • "Unicode version 1.0" . 1991.
    • "1.0.0 / UnicodeData.txt (reconstruit)" . 2004 . Récupéré le 16/03/2010 .
  24. ^ un b "Données Unicode 1.0.1" . Récupéré le 16/03/2010 .
  25. ^ un b
    • «Unicode version 1.1» .
    • «Données Unicode 1995» . Récupéré le 16/03/2010 .
  26. ^ un b
    • "Unicode version 2.0.0" .
    • «Données Unicode-2.0.14» . Récupéré le 16/03/2010 .
  27. ^ un b
    • "Unicode version 2.1.0" .
    • «Données Unicode-2.1.2» . Récupéré le 16/03/2010 .
  28. ^ "Données Unicode-3.0.0" . Récupéré le 16/03/2010 .
  29. ^ "Unicode Data-3.1.0" . Récupéré le 16/03/2010 .
  30. ^ "Unicode Data-3.2.0" . Récupéré le 16/03/2010 .
  31. ^ "Données Unicode-4.0.0" . Récupéré le 16/03/2010 .
  32. ^ "Données Unicode-4.1.0" . Récupéré le 16/03/2010 .
  33. ^ "Données Unicode 5.0.0" . Récupéré le 17/03/2010 .
  34. ^ "Données Unicode 5.1.0" . Récupéré le 17/03/2010 .
  35. ^ "Données Unicode 5.2.0" . Récupéré le 17/03/2010 .
  36. ^ "Données Unicode 6.0.0" . Récupéré le 11/10/2010 .
  37. ^ "Données Unicode 6.1.0" . Récupéré 31/01/2012 .
  38. ^ "Données Unicode 6.2.0" . Récupéré le 26/09/2012 .
  39. ^ "Données Unicode 6.3.0" . Récupéré 30/09/2013 .
  40. ^ "Données Unicode 7.0.0" . Récupéré 15/06/2014 .
  41. ^ "Unicode 8.0.0" . Consortium Unicode . Récupéré 17/06/2015 .
  42. ^ "Données Unicode 8.0.0" . Récupéré 17/06/2015 .
  43. ^ "Unicode 9.0.0" . Consortium Unicode . Récupéré 21/06/2016 .
  44. ^ "Données Unicode 9.0.0" . Récupéré 21/06/2016 .
  45. ^ Lobao, Martim (07/06/2016). "Ce sont les deux Emoji qui n'ont pas été approuvés pour Unicode 9 mais que Google a ajouté à Android de toute façon" . Police Android . Récupéré le 04/09/2016 .
  46. ^ "Unicode 10.0.0" . Consortium Unicode . Récupéré 20/06/2017 .
  47. ^ "Le Standard Unicode, Version 11.0.0 Annexe C" (PDF) . Consortium Unicode . Récupéré 11/06/2018 .
  48. ^ "Annonçant Le Standard Unicode, Version 11.0" . blog.unicode.org . Récupéré le 06/06/2018 .
  49. ^ "Le Standard Unicode, Version 12.0.0 Annexe C" (PDF) . Consortium Unicode . Récupéré le 05/03/2019 .
  50. ^ "Annonçant Le Standard Unicode, Version 12.0" . blog.unicode.org . Récupéré le 05/03/2019 .
  51. ^ "Unicode Version 12.1 a publié à l'appui de l'ère Reiwa" . blog.unicode.org . Récupéré le 07/05/2019 .
  52. ^ un b
    • "Unicode 13.0.0" .
    • "Annonce de la norme Unicode, version 13.0" . blog.unicode.org . Récupéré le 11/03/2020 .
  53. ^ "Le Standard Unicode, Version 13.0 - Annexe C de Spécification de Base" (PDF) . Consortium Unicode . Récupéré le 11/03/2020 .
  54. ^ "Glossaire des termes Unicode" . Récupéré le 16/03/2010 .
  55. ^ "3.4 Caractères et encodage". La norme Unicode, version 13.0 (PDF) . 2019. p. 19.
  56. ^ "2.4 Points de code et caractères". La norme Unicode version 12.0 - Spécification de base (PDF) . 2019. p. 29.
  57. ^ "Annexe A: Conventions de notation" (PDF) . Le standard Unicode . Consortium Unicode. Mars 2020. Conformément à la puce relative à Unicode dans MOS: ALLCAPS , les noms Unicode formels ne sont pas utilisés dans ce paragraphe.
  58. ^ un b "Politique de Stabilité de Codage de Caractère Unicode" . Récupéré le 16/03/2010 .
  59. ^ "Propriétés" (PDF) . Récupéré le 15/03/2020 .
  60. ^ "Modèle d'encodage de caractères Unicode" . Récupéré le 16/03/2010 .
  61. ^ "Les Séquences Nommées Unicode" . Récupéré le 16/03/2010 .
  62. ^ "Alias ​​de nom Unicode" . Récupéré le 16/03/2010 .
  63. ^ CWA 13873: 2000 - Sous-ensembles européens multilingues dans ISO / CEI 10646-1 Accord d'atelier CEN 13873
  64. ^ Raison d'être du jeu de caractères européen multilingue 2 (MES-2) , Markus Kuhn , 1998
  65. ^ "UTF-8, UTF-16, UTF-32 et BOM" . FAQ Unicode.org . Récupéré le 12/12/2016 .
  66. ^ La norme Unicode, version 6.2 . Le Consortium Unicode. 2013. p. 561. ISBN 978-1-936213-08-5.
  67. ^ Pike, Rob (30/04/2003). "Histoire UTF-8" .
  68. ^ "ISO / CEI JTC1 / SC 18 / WG 9 N" (PDF) . Récupéré 04/06/2012 .
  69. ^ Hedley, Jonathan (2009). "Recherche Unicode" .
  70. ^ Milde, Benjamin (2011). "Reconnaissance de caractères Unicode" .
  71. ^ Bois, Alan. "Configuration de Windows Internet Explorer 5, 5.5 et 6 pour le support multilingue et Unicode" . Alan Wood . Récupéré 04/06/2012 .
  72. ^ "Langage de balisage extensible (XML) 1.1 (deuxième édition)" . Récupéré 01/11/2013 .
  73. ^ Bigelow, Charles; Holmes, Kris (septembre 1993). "La conception d'une police Unicode" (PDF) . Publication électronique . VOL. 6 (3), 289-305: 292.
  74. ^ "Polices et claviers" . Consortium Unicode. 28/06/2017 . Récupéré 13/10/2019 .
  75. ^ Une brève histoire des codes de caractères , Steven J. Searle, écrit à l'origine en 1999 , dernière mise à jour en 2004
  76. ^ a b La vie secrète d'Unicode: Un coup d'oeil au ventre mou d'Unicode , Suzanne Topping, 1er mai 2001 (Internet Archive)
  77. ^ Contribution de l'AFII sur WAVE DASH , "Une table de caractères spécifique au fournisseur Unicode pour le japonais" . web.archive.org . 2011-04-22. Archivé de l'original le 22 avril 2011.
  78. ^ Problème ISO 646- * , Section 4.4.3.5 de l' introduction à I18n , Tomohiro KUBOTA, 2001
  79. ^ "Formulaires Arabe de Présentation" (PDF) . Récupéré le 20/03/2010 .
  80. ^ "Formulaires de présentation arabe-B" (PDF) . Récupéré le 20/03/2010 .
  81. ^ "Formulaires de présentation alphabétiques" (PDF) . Récupéré le 20/03/2010 .
  82. ^ Chine (2002-12-02). "Proposition sur l'encodage des caractères tibétains BrdaRten pour ISO / CEI 10646 en BMP" (PDF) .
  83. ^ VS Umamaheswaran (07/11/2003). «Résolutions de la réunion 44 du GT 2» (PDF) . Résolution M44.20.
  84. ^ Politique de stabilité Unicode
  85. ^ un b "Note Technique Unicode # 27: Anomalies Connues dans les Noms de Caractères Unicode" . unicode.org . 10/04/2017.
  86. ^ Graphique Unicode: "en fait cela a la forme d'un p calligraphique minuscule, malgré son nom"
  87. ^ "Une faute d'orthographe de BRACKET dans le nom du personnage est un défaut connu"

Pour en savoir plus [ modifier ]

  • The Unicode Standard, Version 3.0 , The Unicode Consortium, Addison-Wesley Longman, Inc., avril 2000. ISBN 0-201-61633-5 
  • The Unicode Standard, Version 4.0 , The Unicode Consortium, Addison-Wesley Professional, 27 août 2003. ISBN 0-321-18578-1 
  • The Unicode Standard, version 5.0, cinquième édition , The Unicode Consortium , Addison-Wesley Professional, 27 octobre 2006. ISBN 0-321-48091-0 
  • Julie D. Allen. La norme Unicode, version 6.0 , le consortium Unicode , Mountain View, 2011, ISBN 9781936213016 , ( [1] ). 
  • Le manuel complet de typographie , James Felici, Adobe Press; 1ère édition, 2002. ISBN 0-321-12730-7 
  • Unicode: A Primer , Tony Graham, M&T books, 2000. ISBN 0-7645-4625-2 . 
  • Unicode démystifié: Guide pratique du programmeur sur la norme d'encodage , Richard Gillam, Addison-Wesley Professional; 1ère édition, 2002. ISBN 0-201-70052-2 
  • Unicode expliqué , Jukka K. Korpela, O'Reilly; 1ère édition, 2006. ISBN 0-596-10121-X 
  • Yannis Haralambous; Martin Dürst (2019). "Unicode d'un point de vue linguistique". Dans Haralambous, Yannis (éd.). Proceedings of Graphemics in the 21st Century, Brest 2018 . Brest: Editions Fluxus. pp. 167–183. ISBN 978-2-9570549-1-6.

Liens externes [ modifier ]

  • Site officiel · Site technique officiel  
  • Unicode chez Curlie
  • Ressources Unicode d'Alan Wood  - contient des listes de traitements de texte avec capacité Unicode; les polices et les caractères sont regroupés par type; les caractères sont présentés dans des listes et non dans des grilles.
  • Police de secours Unicode BMP  - affiche la valeur Unicode de tout caractère d'un document, y compris dans la zone d'utilisation privée, plutôt que le glyphe lui-même.