Pourquoi existe-t-il plusieurs codages Unicode?


41

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.


11
UTF-8 n'est pas identique à UTF-16. La liste s'allongera dès que nous rencontrerons d'autres systèmes solaires avec des planètes semblables à la Terre.
setzamora

1
@ Joset: Nous avons déjà Klingon. Nous avons la plupart des langages terrestres sur le BMP, avec un léger déversement dans les plaines 1,2. Si les conditions actuelles sont correctes et que seules 42 espèces sensibles dans la galaxie atteignent un point où elles peuvent utiliser les voyages dans l’espace (autoriser ainsi le premier contact), nous devrions pouvoir insérer tous les caractères dans toutes les langues dans UNICODE (en supposant que nous puissions les développer). de 21 à 22 bits pour permettre 64 plaines). Cela laisse même 10 bits d’espace tampon si nous voulons inclure les espèces primitives qui n’ont pas réussi le vol spatial.
Martin York

7
@ Kevin Hsu: UTF-7,8,16LE, 16BE, 32LE, 32BE. Donc, au moins 6 encodages réels existent. UTF-9 et UTF-18 sont des poissons d'avril.
MSalters

9
La bonne chose à propos des normes, c'est qu'il y en a tellement
Homde

1
Voir ce que Spolsky avait à dire sur Unicode et le codage .
MPelletier

Réponses:


29

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


8
+1 excellente réponse. Pour être vraiment honnête, c'est le seul qui réponde réellement à cette question. Toutes les autres réponses concernent (plus ou moins) la manière dont les octets sont disposés dans tous les codages Unicode différents.
Jacek Prucia

Historiquement, c'est une simple question de désaccord. Cependant, je ne vois pas l’utilité d’utiliser autre chose que le format UTF-8 d’aujourd’hui. Bien qu’il existe des scénarios théoriques dans lesquels le format UTF-16 consommerait moins d’espace, ce n’est pas une mince marge et ils sont rares. Les sites Web sont l’endroit le plus important pour lequel vous souhaitez économiser de l’espace, mais ils regorgent de codes HTML qui sont de loin les plus courts en utilisant UTF-8. Vous pouvez par exemple utiliser Shift JISpour rendre un site Web japonais plus petit que son équivalent UTF-8, mais cela ne fonctionne que parce qu'il s'agit d'un jeu de caractères spécifiquement pour le japonais.
aaaaaaaaaaaa

2
Pas vraiment vrai non plus. Comme les formats compressés ne sont réellement utilisés que pour le transport et le stockage. Dans une application, il est plus habituel d'utiliser UCS-2 ou UCS-4 car ils ont une largeur fixe, mais ils occupent 2 ou 4 octets par caractère. Les applications sont donc disposées à céder la place à la facilité d'utilisation.
Martin York

but it is less useful for European languages, and of little use for Asian languages- c'est juste faux. Par "utilité", voulez-vous dire compression? Eh bien, alors UTF-8 fournit une meilleure compression pour les langues européennes car dans chaque texte, il y a des espaces et des signes de ponctuation qui prennent un seul octet.
Nick Volynkin

37

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

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.


2
J'aime cette réponse aussi. A été écrit un semblable, mais celui-ci est clair. J'ajouterais également que UTF-8 est également utile dans la mesure où les chaînes ASCII sont automatiquement UTF-8.
Kevin Hsu

4
S'il vous plaît, c'est le plan multilingue de base , pas une plaine .
JSB

3
C'est une bonne réponse, mais je pense que cela soulève toujours la question "Pourquoi?", Bien que cette réponse aborde implicitement cela. Pour élaborer: UTF-32 est une approche plus directe (certains diraient plus facile) d’encoder des caractères Unicode, mais elle gaspille également beaucoup d’espace, chaque caractère occupant 4 octets. UTF-8 est beaucoup plus compact et rétrocompatible avec ASCII, mais ce n’est pas régulier: un caractère peut prendre entre 1 et 4 octets à encoder, ce qui rend le travail plus difficile. UTF-16 est une sorte d'approche hybride entre les deux, principalement avec les avantages et les inconvénients de chacun.
Mipadi

4
Il existe un compromis entre l'utilisation de la mémoire (UTF-8 étant préférable, car les caractères les plus courants sont codés sur un octet) et la vitesse de traitement (UTF-32, le mieux, car tous les caractères ont la même taille, ce qui permet certaines optimisations et permet d'obtenir des résultats parfaits. Alignement 32 bits en mémoire). Par conséquent, les protocoles réseau et les formats de fichiers utilisent couramment UTF-8 (pour économiser la bande passante / l'espace de stockage), tandis que les interpréteurs de scripts et les environnements d'exécution linguistiques peuvent préférer les formats UTF-16 ou UTF-32.
tdammers

2
@Marcel: Un "CodePoint" est un "CodePoint" et non un character(car un caractère peut être construit à partir de plusieurs "CodePoints"). Ne confondez pas les deux termes. Mais vous avez raison, les "points de code" ne font pas référence aux glyphes. Un glyphe est juste une représentation graphique d'un point de code. Une différence subtile mais importante.
Martin York

25

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.


@ jfs: Pourquoi utiliser l'Unicode, s'il existe toujours une douzaine d'encodages différents ou plus, qui sont tous différents sur le réseau de toute façon? Quel est l'intérêt d'avoir une cartographie globale en soi?
Matthew Scharley

10
@ Matthew Scharley: Vous regardez mal. UNICODE mappe tous les caractères de toutes les langues (y compris le klingon) vers un ID UNIQUE (point de code). Les codages sont simplement un moyen de compresser les points de code sur un disque ou un flux sur un réseau. UTF signifie "format de transport UNICODE". Vous devez toujours penser à un point de code UNICODE en tant que valeur 21 bits. L'avantage par rapport aux autres formats est que tous les caractères sont identifiés de manière unique et ne se chevauchent pas (contrairement à Latin-1, Latin-2, etc.).
Martin York

@ Matthew Scharley Pourquoi une cartographie mondiale? En fait, tout le monde avait sa propre cartographie au passé (vous vous souvenez de pages de code?). Je pense qu'un exemple stupide éclaircira les choses. Imaginez l'idée de l'amour. Comment allez-vous le représenter à quelqu'un? Donner des fleurs? Dis je t'aime"? Chacun a sa propre façon de l'exprimer. L'amour (qui est une idée abstraite) est comme les points de code. En l'exprimant, c'est comme les encodages. :)
JFS

4
Unicode est l'alphabet global. UTF-x est le moyen de transport utilisé par les ordinateurs, car il est difficile de faire passer le papier entre les fils.
Mel

1
@ Martin, Klingon n'a pas survécu. Ni le Tengwar ni le Cirith, utilisés pour écrire les langues elfiques de Tolkein.
TRiG

9

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.


1
Les différentes machines d'état JIS et EUC sont vraiment méchantes, et encore plus si vous travaillez à transformer entre elles. Unicode simplifie énormément cela. Le seul problème majeur avec Unicode est que vous avez obtenu à la pensée d'arrêt d'octets en tant que caractères, vous ASCII à l' aide de petit caractère setted vous chauvins!
Donal Fellows

6

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.

2
"Les nombres 0 à 127 représentent les mêmes caractères dans n'importe quelle page de code." - $57
Eh

@MSalters: vous avez absolument raison. EBCDIC est différent (et il existe d’autres EBCDIC). Je suppose que les jours de l'ordinateur central sont si longs derrière moi que je ne m'en souvenais pas ou que j'ai refoulé ces souvenirs trop durs et trop longs ... :-)
Marjan Venema

"Les nombres 0 à 127 représentent les mêmes caractères dans n'importe quelle page de code." Il existe en fait des codages, tels que BinarySignWriting, qui ne sont pas des sur-ensembles d'ASCII. En fait, BinarySignWriting n'inclut aucun caractère ASCII.
TRiG

@TRiG: C'est pourquoi j'ai modifié ma déclaration pour qu'elle traite spécifiquement des pages de code Ansi. J'avais déjà fait ça avant de te rafraîchir ...
Marjan Venema

Oui. Il y avait un commentaire supplémentaire et une mise à jour post faite pendant que j'écrivais mon commentaire. Pourtant, BinarySignWriting est intéressant.
TRiG

2

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.


2

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.


1

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.


Note: La différence avec un fichier zip, c'est qu'il y a un en-tête qui vous indique quelle compression est en vigueur. Avec les fichiers texte, nous devons encore deviner, n'est-ce pas?
Matthew Scharley

Il y a une séquence spéciale qui dit exactement cela. En raison de la compatibilité ascendante avec ASCII, il est facultatif.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.