Pourquoi «charset» signifie-t-il vraiment «encodage» dans l'usage courant?

Quelque chose qui m'a longtemps dérouté, c'est que tant de logiciels utilisent les termes «charset» et «encoding» comme synonymes.

Lorsque les gens se réfèrent à un "codage" unicode, ils signifient toujours un ensemble de règles pour représenter les caractères unicode comme une séquence d'octets - comme ASCII ou UTF-8. Cela semble raisonnable et intuitif; l'idée est que vous "codez" ces caractères sous forme d'octets en utilisant l'ensemble de règles spécifié.

Étant donné que ces ensembles de règles ne fournissent parfois que la possibilité de «coder» un sous-ensemble de tous les caractères unicode, vous pourriez imaginer qu'un «jeu de caractères» - abréviation de «jeu de caractères» - signifierait simplement un ensemble de caractères unicode - sans aucune considération pour la façon dont ces caractères sont encodés. Un codage impliquerait donc un jeu de caractères (un codage comme ASCII, qui n'a que des règles pour coder 128 caractères, serait associé au jeu de caractères de ces 128 caractères) mais un jeu de caractères n'a pas besoin d'impliquer un codage (par exemple, UTF-8, UTF -16 et UTF-32 sont tous des encodages différents mais peuvent encoder le même jeu de caractères).

Pourtant - et voici le nœud de ma question - l'utilisation réelle du mot "charset" ne correspond pas à ce que la construction du mot impliquerait. Il est presque toujours utilisé pour signifier "encodage".

Par exemple:

• L' charsetattribut en HTML est utilisé pour spécifier un encodage
• Charsets en Java sont des encodages
• charsets et character setsdans MySQL sont, encore une fois, des encodages

Quel âge a cette curieuse (ab) utilisation du langage, et comment cette définition contre-intuitive de «charset» est-elle née? Est - il provient peut - être d'une époque où il vraiment était , dans la pratique, un à un entre les codages utilisés et des ensembles de caractères ils pris en charge? Ou y avait-il une norme ou une spécification particulièrement influente qui dictait cette définition du mot?

Le concept de jeux de caractères est plus ancien que Unicode.

Avant Unicode, un jeu de caractères définissait un jeu de caractères et la façon dont chaque caractère était représenté sous forme de bits. La plupart des jeux de caractères ont mappé un caractère à un octet (ce qui permettait un ensemble de 256 caractères), certains mappés à deux octets et quelques-uns (comme ASCII) à seulement 7 bits. Différents jeux de caractères attribuaient souvent des valeurs différentes au même caractère, et il n'y avait pas de clé de traduction universelle entre les différents jeux de caractères utilisés.

Unicode était une tentative pour résoudre ce problème en unifiant tous les différents jeux de caractères dans un "surensemble" commun. À cette fin, Unicode a introduit quelques niveaux supplémentaires d'abstraction, par exemple le concept de codage de caractères comme quelque chose de distinct des valeurs de point de code. Cela a permis à Unicode de redéfinir les jeux de caractères pré-unicode en tant que codages de caractères unicode.

L'attribut charset en HTML (qui reflète le paramètre charset dans l'en-tête de type de contenu HTTP), par exemple, date d'avant l'adoption d'unicode, mais lorsqu'il a été décidé d'accepter unicode comme jeu de caractères universel d'Internet, l'attribut charset vient d'être redéfini pour spécifier l' encodage utilisé, mais le nom n'a pas été modifié pour permettre une compatibilité descendante.

Le terme «jeu de caractères» est bien sûr court pour «jeu de caractères», qui à son tour est un ancien terme utilisé pour un codage de caractères, qui peut être interprété comme a) un mappage entre des séquences d'octets et des caractères, b) un mappage entre des entiers (numéros de code) et caractères ou c) un mappage entre des caractères abstraits et des nombres entiers ou des séquences d'octets.

«Jeu de caractères» a été utilisé car il s'agit d'une expression courte et simple. Dans ce document, «ensemble» a un sens vague (car le concept entier est vague), mais il a souvent été mal interprété plus tard comme une collection («ensemble» au sens théorique défini), comme décrit dans le célèbre jeu de caractères de Dan Connelly (une fois) Considéré nuisible .

Ce qui importait alors le plus, c'était que l'identifiant charsetsoit utilisé dans MIME et dans HTTP. HTTP 1.0 alias RFC 1945 cite la définition MIME, «une méthode utilisée avec une ou plusieurs tables pour convertir une séquence d'octets en une séquence de caractères», puis commente la confusion: «Cette utilisation du terme« jeu de caractères »est plus communément appelé «encodage de caractères». Cependant, comme HTTP et MIME partagent le même registre, il est important que la terminologie soit également partagée. »

La RFC2045 a introduit un "jeu de caractères" dans MIME et à ce moment-là, il était déjà clair que tous les encodages ne faisaient pas correspondre un caractère à un octet. RFC2130 discute un peu plus de cette histoire.

Fondamentalement, "charset" était un terme plus populaire lorsque ces normes ont été écrites, il est plus succinct que "codage de caractères" ou "schéma de codage de texte", et moins ambigu que "codage".

Il y a au moins 2 encodages applicables au transfert de texte. L'encodage des caractères décrit comment les caractères (glyphes) sont encodés. Toutes les langues utilisent un sous-ensemble du jeu de caractères UCS, qui sont souvent codés sur une valeur de 8 bits. Les jeux de caractères normalisés ont des codages de caractères standard et les termes sont généralement utilisés de manière interchangeable.

L'encodage de transfert décrit comment le texte est transféré et est généralement indépendant de l'encodage de caractères. La plupart des codages de transfert ne sont pas transparents et modifient la séquence d'octets en cours de transfert. Le codage de transfert 8 bits est transparent pour les codages 8 bits. Le codage de transfert 7 bits ne peut transférer que des jeux de caractères 7 bits tels que ASCII

ASCII utilise 95 caractères imprimables et quelques caractères supplémentaires pour le contrôle du chariot (saut de ligne, saut de page, retour chariot, retour arrière et tabulations) codés en 7 bits. Il existe des caractères de contrôle supplémentaires utilisant les valeurs restantes. ASCII est un sous-ensemble approprié des jeux de caractères UCS ainsi que de nombreux jeux de caractères 8 bits. ISO-8859-1 est également un sous-ensemble approprié du jeu de caractères UCS, mais ces caractères ont un codage différent en UTF-8, qui utilise plusieurs octets pour des valeurs de caractères supérieures à 127.

Les mainframes IBM utilisent (d) l'EBCDID qui utilisait un codage 8 bits différent. Il existe des tables de traduction qui mappent les caractères imprimables entre les codages de caractères ASCII et ECBDIC. ECBDIC a un jeu de caractères plus grand que ASCII car il a des signes de ponctuation non disponibles en ASCII. Cela peut empêcher la transformation aller-retour complète entre ces deux codages, si le codage initial est ECBDIC.

Ces encodages n'étaient pas suffisants pour les langues avec des caractères non couverts par les caractères imprimables ASCII. Microsoft et d'autres ont utilisé des extensions 8 bits pour le jeu de caractères ASCII et ont codé des caractères supplémentaires avec des valeurs supérieures à 127. Une seule extension n'était pas suffisante pour toutes les langues car ces extensions n'ont ajouté que 96 caractères au jeu de caractères. Cela a entraîné l'utilisation de plusieurs jeux de caractères (jeux de caractères) pour différentes langues avec un codage de caractères 8 bits différent. Ces jeux de caractères incluent les caractères requis pour cette langue ou cette famille de langues. Les caractères supplémentaires peuvent être codés en différentes valeurs dans différents jeux de caractères. Les utilisateurs anglais sont plus susceptibles de le remarquer avec une ponctuation étendue (guillemets gauche et droit et tirets) qui n'apparaissent pas correctement si le mauvais jeu de caractères est utilisé.

Pour les codages à octet unique, seuls les caractères du jeu de caractères peuvent être codés. Certaines langues nécessitent des encodages multi-octets pour couvrir leur jeu de caractères. Le jeu de caractères Unicode (UCS) nécessite des codages multi-octets pour les caractères en dehors du jeu de caractères ASCII. Ce jeu de caractères est un sur-ensemble de tous les encodages spécifiques à la langue. UTF-8 est un encodage compact du jeu de caractères UCS. ASCII ne nécessite aucun octet supplémentaire et la plupart (tous?) Des caractères de langue européenne peuvent être codés sur un ou deux octets. Le jeu de caractères UCS-2 complet peut être codé en un à trois octets. Tous les caractères du jeu de caractères UCS actuel peuvent être codés sur un à quatre octets.

FWIW, IIRC, Back in the Commodore 64 jours, un jeu de caractères était une fonction de {0, ... 255} à l'ensemble de toutes les images uxv en noir et blanc où u et v étaient peut-être 8 et 12. Donc "changer votre jeu de caractères "signifiait utiliser la commande POKE dans le langage BASIC pour modifier les emplacements de mémoire désignés pour contenir ces images. Par exemple, le code ASCII 65 signifiait A et l'image d'un A serait stockée à partir de l'adresse mémoire a * 65 + b pour certains b et je suppose que a = u * v.