Pourquoi existe-t-il plusieurs codages Unicode?

Je pensais que l'Unicode était conçu pour contourner le problème des nombreux codages différents en raison d'un espace d'adresses réduit (8 bits) dans la plupart des tentatives précédentes (ASCII, etc.).

Pourquoi existe-t-il tant d'encodages Unicode? Même plusieurs versions du (essentiellement) même, comme UTF-8, UTF-16, etc.

Parce que les gens ne veulent pas dépenser 21 bits pour chaque caractère. Sur tous les systèmes modernes, cela signifierait essentiellement d’utiliser trois octets par caractère, soit trois fois plus que ce à quoi les gens étaient habitués. Ils ne souhaitaient donc pas du tout adopter Unicode. Des compromis ont dû être trouvés: par exemple, UTF-8 convient parfaitement au texte anglais, car les anciens fichiers ASCII ne doivent pas du tout être convertis, mais ils sont moins utiles pour les langues européennes et peu utiles pour les langues asiatiques.

Donc, fondamentalement, oui, nous aurions pu définir un codage universel unique ainsi qu'un tableau de caractères universel unique, mais le marché ne l'aurait pas accepté.

Unicode est un caractère de 21 bits codant de manière unique les "points de code", chacun des points de code étant représenté par un glyphe (une représentation graphique).

• 16 bits utilisés pour identifier un point de code dans un plan (la plupart des points de code sont sur le plan 0).
• 5 bits pour identifier l'avion.

Les encodages supportés sont:

• UTF-8 (pour coder chaque point en utilisant des valeurs de 8 bits)
• UTF-16 (pour coder chaque point en utilisant des valeurs de 16 bits)
• UTF-32 (pour coder chaque point en utilisant des valeurs de 32 bits)

Mais quel que soit le codage utilisé lors du décodage, ils sont tous reliés à un point de code spécifique qui a la même signification (c'est pourquoi il est cool).

• 'A' (U + 65)
  UTF-32 => 0x00000041 UTF-16 => 0x0041 UTF-8 => 0x41
• LATIN PETITE LIGATURE OE '(U + 0153)
  UTF-32 => 0x00000153 UTF-16 => 0x0153 UTF-8 => 0xC5 0x93
• Non affecté (U + 11153)
  UTF-32 => 0x00011153 UTF-16 => 0xD804 0xDD53 UTF-8 => 0xF0 0x91 0x85 0x93

UTF-8

C'est un format de taille variable. Où chaque point de code est représenté par 1 à 4 octets.

UTF-16

C'est un format de taille variable. Les points de code du "Plan multilingue de base" (BMP ou Plan 0) peuvent être représentés par une seule valeur de 16 bits. Les points de code sur d'autres plans sont représentés par une paire de substitution (2 valeurs de 16 bits).

UTF-32

C'est un format de taille fixe. Tous les points de code sont représentés par une seule valeur de 32 bits.

Je pense qu'il est utile de séparer les 2 idées:

1. Unicode - mappage de caractères du monde entier en points de code.
2. Encodage - mappage des points de code en modèles de bits (UTF-8, UTF-16, etc.).

Les codages UTF-8, UTF-16 et autres présentent chacun des avantages et des inconvénients. Mieux vaut consulter Wikipedia à ce sujet.

UTF-7, UTF-8, UTF-16 et UTF-32 sont simplement des formats de transformation algorithmiques du même codage (points de code) de caractères. Ce sont des encodages d'un système de codification de caractères.

Il est également plus facile, d’un point de vue algorithmique, de naviguer en avant et en arrière que la plupart des systèmes précédents pour traiter des jeux de caractères supérieurs à 256 caractères.

Ceci est très différent de la codification des glyphes généralement par pays et parfois par vendeur. En japonais seulement, il y avait une tonne de variations de JIS seul, sans oublier EUC-JP et la transformation de JIS orientée page de code que les machines DOS / Windows utilisaient, appelée Shift-JIS. (Dans une certaine mesure, il y avait des transformations algorithmiques de ceux-ci, mais elles n'étaient pas particulièrement simples et il y avait des différences de caractères spécifiques au fournisseur qui étaient disponibles. Multipliez cela par quelques centaines de pays et l'évolution progressive de systèmes de polices plus sophistiqués (post greenscreen époque) et vous avez eu un vrai cauchemar.

Pourquoi auriez-vous besoin de ces formes de transformation d'Unicode? Étant donné que de nombreux systèmes hérités supposaient des séquences de caractères 7 bits de la plage ASCII, il vous fallait donc une solution propre 7 bits pour transmettre des données en toute sécurité via ces systèmes. Vous avez donc besoin de l'UTF-7. Ensuite, il existait des systèmes plus modernes capables de gérer les jeux de caractères 8 bits, mais les valeurs nulles avaient généralement une signification particulière. UTF-16 ne leur convenait donc pas. 2 octets pouvaient coder la totalité du plan multilingue de base d'Unicode lors de sa première incarnation. UCS-2 semblait donc une approche raisonnable pour les systèmes qui allaient être "pleinement conscients de l'existence d'Unicode" (comme Windows NT et la machine virtuelle Java). alors les extensions au-delà nécessitaient des caractères supplémentaires, ce qui a entraîné la transformation algorithmique des codages réservés par le standard Unicode sur une valeur de 21 bits. Des paires de substitution sont nées; cela a nécessité UTF-16. Si vous aviez des applications dans lesquelles la cohérence de la largeur des caractères importait plus que l'efficacité du stockage, UTF-32 (anciennement UCS-4) était une option.

UTF-16 est la seule chose qui soit complexe à gérer, et qui est facilement atténuée par le petit nombre de caractères affectés par cette transformation et par le fait que les séquences principales de 16 bits se trouvent bien dans une plage totalement distincte de la fin. Séquences 16 bits. C'est aussi beaucoup plus facile que d'essayer d'avancer et de revenir en arrière dans de nombreux codages de début d'Asie de l'Est, où il fallait soit une machine à états (JIS et EUC) pour gérer les séquences d'échappement, soit potentiellement reculer de plusieurs caractères jusqu'à ce que vous trouviez quelque chose qui était garanti. être uniquement un octet principal (Shift-JIS). UTF-16 présentait également certains avantages sur les systèmes capables de gérer efficacement les séquences 16 bits.

Sauf si vous devez vivre à travers des dizaines (voire des centaines) de codages différents, ou si vous devez construire des systèmes prenant en charge plusieurs langues dans des codages différents, parfois même dans le même document (comme WorldScript dans les versions antérieures de MacO), vous pourriez penser des formats de transformation unicode comme complexité inutile. Mais il s’agit d’une réduction spectaculaire de la complexité par rapport aux solutions de remplacement antérieures, et chaque format résout une contrainte technique réelle. Ils sont également vraiment convertibles entre eux, ne nécessitant aucune table de consultation complexe.

Unicode n'a pas été conçu pour contourner le problème des nombreux codages.

Unicode a été conçu pour contourner toute la question d'un nombre représentant différentes choses en fonction de la page de code utilisée. Les chiffres 0 à 127 représentent les mêmes caractères dans toutes les pages de codes Ansi. C'est ce que l'on appelle également le graphique ASCII ou le jeu de caractères. Dans les pages de code Ansi, qui autorisent 256 caractères, les chiffres 128 à 255 représentent différents caractères dans différentes pages de code.

Par exemple

• Le nombre $ 57 représente un W majuscule dans toutes les pages de code, mais
• Le numéro $ EC représente le symbole d'inifinité dans la page de code 437 (US), mais une "LETTRE LATINE LATINE N CEDILLA" dans la page de code 775 (Baltique).
• Le Cent Sign porte le numéro $ 9B dans la page de code 437, mais le numéro 96 dans la page de code 775.

Ce que Unicode a fait, c’est tout chamboulé. En Unicode, il n'y a pas de "réutilisation". Chaque numéro représente un seul caractère unique. Le nombre $ 00A2 en Unicode est le signe cent et le signe cent n'apparaît nulle part ailleurs dans la définition Unicode.

Pourquoi existe-t-il tant d'encodages Unicode? Même plusieurs versions du (essentiellement) même, comme UTF-8, UTF-16, etc.

Il n'y a pas plusieurs versions du même encodage. Il existe plusieurs codages de la même carte de définition de caractères Unicode et ceux-ci ont été "inventés" pour répondre aux besoins de stockage pour différentes utilisations des différents plans linguistiques existant dans Unicode.

Unicode définit (ou a l'espace à définir) 4.294.967.295 caractères uniques. Si vous souhaitez les mapper vers un stockage sur disque / mémoire sans effectuer de conversions algorithmiques, vous avez besoin de 4 octets par caractère. Si vous avez besoin de stocker des textes contenant des caractères de tous les plans linguaux, alors UTF-32 (qui est fondamentalement un encodage de stockage simple 1 caractère - 4 octets de la définition Unicode) est probablement ce dont vous avez besoin.

Mais rares sont les textes qui utilisent des personnages de tous les plans linguaux. Et puis utiliser 4 octets par caractère semble un gros gaspillage. Surtout lorsque vous prenez en compte le fait que la plupart des langues sur Terre sont définies dans ce que l'on appelle le plan multilingue de base (BMP): les premiers 65 536 numéros de la définition Unicode.

Et c’est là que l’UTF-16 est entré en jeu. Si vous n’utilisez que des caractères du BMP, l’UTF-16 le stockera très efficacement en utilisant seulement deux octets par caractère. Il utilisera uniquement plus d'octets pour les caractères extérieurs au BMP. La distinction entre UTF-16LE (Little Endian) et UTF-16BE (Big Endian) n’a en réalité qu’une relation avec la façon dont les nombres sont représentés dans la mémoire de l’ordinateur (la structure des octets A0signifie hex $ A0 ou $ 0A).

Si votre texte utilise encore moins de caractères différents, comme la plupart des textes dans les langues d'Europe occidentale, vous souhaiterez limiter encore davantage les exigences de stockage de vos textes. D'où UTF-8, qui utilise un seul octet pour stocker les caractères présents dans le diagramme ASCII (les 128 premiers chiffres) et une sélection parmi les caractères Ansi (les 128 derniers numéros des différentes pages de code). Il utilisera uniquement plus d'octets pour les caractères en dehors de cet ensemble de "caractères les plus utilisés".

Donc, pour récapituler:

• Unicode est un mappage des caractères dans toutes les langues de la Terre (et certains Klingons en plus), puis de certains (mathématiques, musicaux, etc.) en un nombre unique.
• Les codages sont des algorithmes définis pour stocker des textes en utilisant les numéros de cette carte de caractères unique aussi efficacement que possible dans l'espace, étant donné "l'utilisation moyenne" des caractères dans les textes.

Unicode définit la carte entre les chiffres et les caractères. Toutefois, lorsque vous envoyez un numéro à un destinataire, vous devez toujours définir comment représenter ce numéro. C'est ce que UTF est pour. Il définit comment représenter un nombre dans un flux d'octets.

La logique derrière UTF-32 est simple: il s'agit de la représentation la plus simple des points de code Unicode. Alors pourquoi tout ne se trouve pas dans UTF-32? Deux raisons principales:

L'un est la taille . UTF-32 nécessite 4 octets pour chaque caractère. Pour un texte n'utilisant que des caractères du texte multilingue de base, l'espace est deux fois plus grand que le format UTF-16. Pour le texte anglais, c'est 4 fois plus d'espace qu'US-ASCII.

La plus grande raison est la compatibilité ascendante . Chaque codage Unicode autre que le format UTF-32 "non codé" a été conçu pour assurer la compatibilité avec les versions antérieures.

• UTF-8: Compatibilité ascendante avec US-ASCII.
• UTF-16: Compatibilité ascendante avec UCS-2 (Unicode 16 bits avant qu'il ne soit étendu au-delà du format BMP).
• UTF-7: Compatibilité ascendante avec des serveurs de messagerie non nettoyés en 8 bits.
• GB18030: Compatibilité ascendante avec les encodages GB2312 et GBK pour le chinois.
• UTF-EBCDIC: Compatibilité ascendante avec le sous-ensemble Basic Latin d’EBCDIC.

Je pensais que Unicode était conçu pour contourner toute la question d'avoir beaucoup de codages différents

C'était et ça l'a fait. Il est beaucoup plus facile de convertir entre UTF-8, -16 et -32 que de traiter avec l'ancien système de centaines de codages de caractères différents pour différentes langues et différents systèmes d'exploitation.

Vous savez qu'un fichier zip peut compresser un fichier pour qu'il soit beaucoup plus petit (en particulier un texte), puis le décompresser en une copie identique du fichier d'origine.

L'algorithme de compression contient en fait plusieurs algorithmes avec différentes caractéristiques: stocké (pas de compression), rétréci, réduit (méthodes 1 à 4), implodé, en jetons, décompressé, Deflate64, BZIP2, LZMA (EFS), WavPack, PPMd, où il pourrait théoriquement tous les essayer et choisir le meilleur résultat mais généralement juste aller avec Deflated.

UTF fonctionne à peu près de la même manière. Il existe plusieurs algorithmes de codage ayant chacun des caractéristiques différentes, mais vous choisissez généralement UTF-8 car il est largement pris en charge, contrairement aux autres variantes UTF. utiliser sur la plupart des plates-formes informatiques modernes qui utilisent généralement une extension ASCII de 8 bits.