Tout le monde connaît l'encodage UTF-8, qui domine depuis longtemps l'espace Internet et est utilisé depuis de nombreuses années. Il semblerait que tout soit connu sur elle, et il n'y a rien d'intéressant à dire à ce sujet. Si vous lisez des ressources populaires telles que Wikipedia, alors il n'y a vraiment rien d'inhabituel là-dedans, sauf que la version anglaise mentionne brièvement une histoire étrange sur la façon dont elle a été "esquissée sur une serviette dans un restaurant".
En fait, l'invention de cet encodage ne peut pas être si banale, ne serait-ce que parce que Ken Thompson, une personne légendaire, a participé à sa création. Il a travaillé avec Dennis Ritchie, a été l'un des créateurs d'UNIX, a contribué au développement de C (a inventé son prédécesseur - B), et plus tard, tout en travaillant chez Google, a participé à la création du langage Go.
Avant de vous - la traduction de plusieurs lettres dans lesquelles les développeurs rappellent l'histoire de la création de l'encodage.
Personnages:
ken (at) entrisphere.com - Ken Thompson
Ken Thompson (à gauche) avec Dennis Ritchie
"Rob 'Commander' Pike" - Robert Pike , un programmeur canadien qui a travaillé sur UTF-8 avec Ken Thompson
mkuhn (at) acm.org - Markus Kuhn , informaticien allemand
henry (at) spsystems.net - Henry Spurser , auteur de l'une des implémentations RegExp
Russ Cox < rsc@plan9.bell-labs.com > - Russ Cox , employé de Bell Labs qui a travaillé sur le Plan 9
Greger système Leijonhufvud < greger@friherr.com> - Un des membres du personnel de X / Open
Plan 9 - Le système d'exploitation, qui a été le premier à utiliser le codage UTF-8 pour assurer le multilinguisme.
UTF-8 - Encodage de caractères Unicode
Correspondance 2003
Ci-dessous se trouve la correspondance entre les créateurs de l'encodage, Robert et Ken, que Robert Pike a commencé, se plaignant que leur contribution à la création de l'UTF-8 a été injustement oubliée. Robert demande à l'une de ses anciennes connaissances de fouiller dans les archives du serveur de messagerie et d'y trouver des preuves de leur participation. (environ par.)
Subject: UTF-8 history From: "Rob 'Commander' Pike" <r (at) google.com> Date: Wed, 30 Apr 2003 22:32:32 -0700 (Thu 06:32 BST) To: mkuhn (at) acm.org, henry (at) spsystems.net Cc: ken (at) entrisphere.com
En regardant les conversations sur les origines de l'UTF-8, je vois la même histoire se répéter encore et encore.
Mauvaise version:
- UTF-8 a été développé par IBM.
- Il a été mis en œuvre dans le Plan 9 (un système d'exploitation développé par Bell Laboratories)
Ce n'est pas vrai. J'ai vu de mes propres yeux comment l'UTF-8 a été inventé sur une serviette un soir de septembre 1992 dans un restaurant du New Jersey.
C'est arrivé de cette manière. Nous avons utilisé l'original ISO 10646 UTF pour prendre en charge les caractères 16 bits dans le plan 9, ce que nous détestions, et nous étions prêts à expédier le plan 9 lorsque des gars m'ont appelé tard dans la nuit, je pense qu'ils venaient d'IBM. Je me souviens de les avoir rencontrés lors de la réunion du comité X / Open à Austin. Ils voulaient que Ken et moi voyions leur projet FSS / UTF.
(, ..) . Bell Labs , Plan 9 — , , , . , .Nous avons compris pourquoi ils voulaient changer le design et avons décidé que c'était une bonne opportunité d'utiliser notre expérience pour développer un nouveau standard et amener les gars de X / Open à le promouvoir. Il fallait leur en parler, et ils se sont mis d'accord à la condition que nous nous en occupions rapidement.
Unicode , , , , , .
(. .)
Ensuite, nous sommes allés manger un morceau, et pendant le dîner, Ken a trié le paquet de beats, et quand nous sommes revenus, ils ont appelé les gars de X / Open et leur ont expliqué notre idée. Nous avons envoyé notre croquis par courrier, et ils ont répondu que c'était mieux que le leur (mais je me souviens exactement qu'ils ne nous avaient pas montré leur version), et ont demandé quand nous pourrions l'implémenter.
L'une des options pour délimiter les caractères était une barre oblique, mais cela pouvait semer la confusion dans le système de fichiers, cela pourrait l'interpréter comme une séquence d'échappement.Il me semble que c'est arrivé mercredi soir. Nous avons promis que nous lancerions le système d'ici lundi, alors que je pense qu'ils ont prévu une réunion importante. Ce soir-là, Ken a écrit le code encodeur / décodeur, et j'ai commencé à m'occuper de C et des bibliothèques graphiques. Le lendemain, le code était prêt et nous avons commencé à convertir les fichiers texte du système. Vendredi, le plan 9 était déjà opérationnel sur le soi-disant UTF-8.
(environ par.)
Et plus tard, l'histoire a été un peu réécrite.
Pourquoi n'avons-nous pas simplement utilisé leur FSS / UTF?
Autant que je me souvienne, lors de ce premier appel téléphonique, j'ai chanté à Desiderata mes besoins en matière d'encodage, et FSS / UTF n'avait pas au moins une chose - la possibilité de synchroniser un flux d'octets pris au milieu du flux en utilisant aussi peu caractères que possible pour la synchronisation (voir ci-dessus, à propos de la définition des limites des caractères.
les a chanté Desiderat
.
, 1971 , : «Desiderata» , , : «». , « » « ». ( .)
, 1971 , : «Desiderata» , , : «». , « » « ». ( .)
Puisqu'il n'y avait aucune solution nulle part, nous étions libres de le faire comme nous le voulions.
Je pense que "l'histoire a été inventée par IBM et implémentée dans Plan 9" a ses origines dans la documentation RFC 2279. Nous étions si heureux quand UTF-8 a pris racine que nous n'avons raconté l'histoire à personne.
Aucun de nous ne travaille plus chez Bell Labs, mais je suis sûr qu'il existe une archive de courriels qui peut corroborer notre histoire, et je peux demander à quelqu'un de creuser dedans.
Donc tout le mérite revient aux gars de X / Open et IBM pour avoir rendu cela possible et poussé l'encodage, mais Ken l'a développé, et je l'ai aidé avec ça, peu importe ce que disent les livres d'histoire.
-Rob
Date: Sat, 07 Jun 2003 18:44:05 -0700 From: "Rob `Commander' Pike" <r@google.com> To: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> cc: henry@spsystems.net, ken@entrisphere.com, Greger Leijonhufvud <greger@friherr.com> Subject: Re: UTF-8 history
J'ai demandé à Russ Cox de fouiller dans les archives. Je joins son message. Je pense que vous conviendrez que cela confirme l'histoire que j'ai publiée plus tôt. L'e-mail que nous avons envoyé à X / Open (je pense que Ken a édité et diffusé ce document) comprend un nouveau "desideratum numéro 6" sur la détection des limites de caractères.
Nous ne saurons plus quel impact la solution originale de X / Open a eu sur nous. Bien qu'ils soient différents, ils ont des caractéristiques communes. Je ne me souviens pas l'avoir regardé en détail, c'était il y a trop longtemps (dans la dernière lettre, il dit que X / Open ne leur a pas montré leur implémentation. Approx. Lane) . Mais je me souviens très bien comment Ken a écrit des croquis sur une serviette et a ensuite souhaité que nous l'ayons gardé.
-Rob
From: Russ Cox <rsc@plan9.bell-labs.com> To: r@google.com Subject: utf digging Date-Sent: Saturday, June 07, 2003 7:46 PM -0400
Le fichier des bootes utilisateur a
/sys/src/libc/port/rune.c
été modifié par division-heavy le 4 septembre 1992. La version dans la décharge a une heure de 19:51:55. Le lendemain, un commentaire y a été ajouté, mais sinon, il n'a pas changé jusqu'au 14 novembre 1996, date à laquelle il a
runelen
été accéléré en vérifiant explicitement la valeur
rune
au lieu d'utiliser la valeur de retour
runetochar
. Le dernier changement a eu lieu le 26 mai 2001 lorsqu'il a été ajouté
runenlen
. (Rune est une structure qui contient une valeur Unicode. Runelen et runetochar sont des fonctions qui fonctionnent avec ce type de données. Approx. Trans.)
Plusieurs lettres de vos boîtes aux lettres ont été générées par la capture de ligne utf.
Le premier concerne un fichier
utf.c
qui est une copie
wctomb
et
mbtowc
(fonctions de conversion de caractères. Approx. Per.) Qui gère le codage UTF-8 complet de 6 octets, 32 bits.
runes.
Avec la logique de contrôle de flux, il semble assez moche. Je suppose que ce code provient de ce premier e-mail.
Dans
/usr/ken/utf/xutf
j'ai trouvé une copie de ce qui semble être la source de cette méthode de codage non auto-synchronisante, avec le schéma UTF-8 ajouté à la fin de l'e-mail (commence par "Nous définissons 7 types
byte
").
La version de la lettre ci-dessous, datée du 2 septembre 23h44:10, est la première. Après plusieurs modifications, le matin du 8 septembre, la deuxième version est sortie. Les journaux du serveur de messagerie montrent comment la deuxième version de la lettre est envoyée et, après un certain temps, revient à Ken:
helix: Sep 8 03:22:13: ken: upas/sendmail: remote inet!xopen.co.uk!xojig >From ken Tue Sep 8 03:22:07 EDT 1992 (xojig@xopen.co.uk) 6833 helix: Sep 8 03:22:13: ken: upas/sendmail: delivered rob From ken Tue Sep 8 03:22:07 EDT 1992 6833 helix: Sep 8 03:22:16: ken: upas/sendmail: remote pyxis!andrew From ken Tue Sep 8 03:22:07 EDT 1992 (andrew) 6833 helix: Sep 8 03:22:19: ken: upas/sendmail: remote coma!dmr From ken Tue Sep 8 03:22:07 EDT 1992 (dmr) 6833 helix: Sep 8 03:25:52: ken: upas/sendmail: delivered rob From ken Tue Sep 8 03:24:58 EDT 1992 141 helix: Sep 8 03:36:13: ken: upas/sendmail: delivered ken From ken Tue Sep 8 03:36:12 EDT 1992 6833
Bonne chance.
Fichiers de l'archive de messagerie
Vient ensuite un fichier avec la correspondance du vidage du serveur de messagerie, que Russ Cox a joint au sien, en réponse à la demande de Robert de plonger dans l'histoire. Ceci est la "première version". (environ.)
>From ken Fri Sep 4 03:37:39 EDT 1992
Voici notre suggestion pour modifier FSS-UTF. C'est à peu près la même chose que dans le précédent. Je m'excuse auprès de l'auteur.
Le code a été testé dans une certaine mesure et devrait être en assez bon état. Nous avons repensé le code de Plan 9 pour utiliser cet encodage, et nous allons publier la distribution et sélectionner les utilisateurs universitaires pour les tests initiaux.
Format de transformation du jeu de caractères universel sécurisé du système de fichiers (FSS-UTF)
La norme ISO / CEI 10646 (Unicode) étant établie en tant que norme internationale et l'attente d'une adoption généralisée de ce jeu de caractères codés universels (UCS), les systèmes d'exploitation historiquement basés sur ASCII doivent développer des moyens de représenter et de gérer un grand nombre de caractères qui peut encoder avec le nouveau standard. UCS a plusieurs problèmes qui doivent être résolus dans les systèmes d'exploitation historiquement établis et l'environnement de programmation en C.
(Le texte ci-dessous mentionne plusieurs fois des «systèmes d'exploitation historiques». Apparemment dans le contexte de «travailler historiquement avec l'encodage ASCII». a omis cette épithète, ou l'a remplacée par «existant», etc., voie approximative)
Le plus gros problème est le schéma de codage utilisé dans UCS. À savoir, l'intégration de la norme UCS avec les langages de programmation, les systèmes d'exploitation et les utilitaires existants. Les problèmes dans les langages de programmation et les systèmes d'exploitation sont traités dans tous les secteurs, mais nous sommes toujours confrontés à la gestion des UCS par les systèmes d'exploitation et les utilitaires.
Parmi les problèmes liés à la gestion de l'UCS dans les systèmes d'exploitation, le principal est la présentation des données dans le système de fichiers. Le concept sous-jacent est de prendre en charge les systèmes d'exploitation existants dans lesquels l'investissement a été effectué et en même temps de profiter du grand nombre de caractères fournis par UCS.
UCS permet d'encoder du texte multilingue à l'aide d'un seul jeu de caractères. Mais UCS et UTF ne protègent pas les octets nuls (la fin des lignes dans certaines langues. Approx. Per.) Et / ou une barre oblique en ASCII /, ce qui rend le codage incompatible avec Unix. La proposition suivante fournit un format de transformation UCS compatible Unix, de sorte que les systèmes Unix puissent prendre en charge le texte multilingue dans un seul encodage.
Ce format de conversion d'encodage est destiné à l'encodage des fichiers en tant qu'étape intermédiaire vers la prise en charge complète de l'UCS. Cependant, étant donné que presque toutes les implémentations Unis sont confrontées aux mêmes problèmes de prise en charge UCS, cette proposition est destinée à fournir une compatibilité d'encodage générale à ce stade.
But / objectif
Sur la base de l'hypothèse, nous obtenons que si presque tous les problèmes de traitement et de stockage de l'UCS dans les systèmes de fichiers OS sont connus, nous devons utiliser un tel format de conversion UCS qui fonctionnera sans violer la structure du système d'exploitation. L'objectif est que le processus de conversion de format puisse être utilisé pour encoder le fichier.
Critères de format de conversion
Les instructions suivantes doivent être suivies lors de la définition du format de conversion UCS:
- Compatibilité avec les systèmes de fichiers existants.
Il est interdit d'utiliser un octet nul et une barre oblique dans le nom du fichier. - .
ASCII. UCS, ASCII, ASCII. - UCS .
- .
- , , .
- , (. ..).
FSS-UTF
Le format de transformation UCS proposé encode les valeurs UCS dans une plage en
[0,0x7fffffff]
utilisant plusieurs octets par caractère et des longueurs de 1, 2, 3, 4, 5 et 6 octets. Dans tous les cas de codage avec plus d'un octet, l'octet de tête détermine le nombre d'octets utilisés, le bit le plus significatif étant défini dans chaque octet. Chaque octet qui ne commence pas par 10XXXXXX est le début d'une séquence de caractères UCS.
Un moyen facile de se souvenir du format: le nombre de plus hauts dans le premier octet signifie le nombre d'octets dans un caractère multi-octets.
Bits Hex Min Hex Max Byte Sequence in Binary 1 7 00000000 0000007f 0vvvvvvv 2 11 00000080 000007FF 110vvvvv 10vvvvvv 3 16 00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv 4 21 00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv 5 26 00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 6 31 04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
La valeur du caractère UCD codé sur plusieurs octets est une concaténation de v-bits. Si plusieurs méthodes de codage sont possibles, par exemple UCS 0, la plus courte est considérée comme acceptable.
Vous trouverez ci-dessous des exemples d'implémentations de fonctions C standard
wcstombs()
et
mbstowcs()
qui démontrent des algorithmes pour la conversion du format UCS au format de conversion et la conversion du format de conversion au format UCS. Des exemples d'implémentations incluent la vérification des erreurs, dont certaines peuvent ne pas être nécessaires pour la cohérence:
typedef
struct
{
int cmask;
int cval;
int shift;
long lmask;
long lval;
} Tab;
static
Tab tab[] =
{
0x80, 0x00, 0*6, 0x7F, 0, /* 1 byte sequence */
0xE0, 0xC0, 1*6, 0x7FF, 0x80, /* 2 byte sequence */
0xF0, 0xE0, 2*6, 0xFFFF, 0x800, /* 3 byte sequence */
0xF8, 0xF0, 3*6, 0x1FFFFF, 0x10000, /* 4 byte sequence */
0xFC, 0xF8, 4*6, 0x3FFFFFF, 0x200000, /* 5 byte sequence */
0xFE, 0xFC, 5*6, 0x7FFFFFFF, 0x4000000, /* 6 byte sequence */
0, /* end of table */
};
int
mbtowc(wchar_t *p, char *s, size_t n)
{
long l;
int c0, c, nc;
Tab *t;
if(s == 0)
return 0;
nc = 0;
if(n <= nc)
return -1;
c0 = *s & 0xff;
l = c0;
for(t=tab; t->cmask; t++) {
nc++;
if((c0 & t->cmask) == t->cval) {
l &= t->lmask;
if(l < t->lval)
return -1;
*p = l;
return nc;
}
if(n <= nc)
return -1;
s++;
c = (*s ^ 0x80) & 0xFF;
if(c & 0xC0)
return -1;
l = (l<<6) | c;
}
return -1;
}
int
wctomb(char *s, wchar_t wc)
{
long l;
int c, nc;
Tab *t;
if(s == 0)
return 0;
l = wc;
nc = 0;
for(t=tab; t->cmask; t++) {
nc++;
if(l <= t->lmask) {
c = t->shift;
*s = t->cval | (l>>c);
while(c > 0) {
c -= 6;
s++;
*s = 0x80 | ((l>>c) & 0x3F);
}
return nc;
}
}
return -1;
}
>From ken Tue Sep 8 03:24:58 EDT 1992
Je l'ai envoyée par la poste, mais la lettre est entrée dans un trou noir, donc je n'ai pas reçu ma copie. Cette adresse Internet devait être dans le coma.
Deuxième version de la lettre, avec des révisions
Ensuite, une copie de la lettre est jointe, qui est décrite ci-dessus comme: "Après plusieurs corrections, le matin du 8 septembre, la deuxième version est sortie." La partie répétitive est cachée sous le spoiler. (environ trad.)
>From ken Tue Sep 8 03:42:43 EDT 1992
J'ai finalement eu ma copie.
--- /usr/ken/utf/xutf from dump of Sep 2 1992 ---
Texte masqué
ISO/IEC 10646 (Unicode) (UCS), , ASCII, , . UCS , C.
, UCS. UCS , . , UCS .
, UCS , . , , , , UCS.
UCS . UCS UTF ( . . .) / ASCII /, Unix. UCS, Unix, , , Unix- .
, UCS. , Unis UCS, .
, UCS , UCS, . , .
, , UCS:
UCS UCS
1, 2, 3, 4, 5, 6 . , . , 10XXXXXX, UCS.
: .
UCD — v-. , UCS 0, .
C
, UCS UCS. , :
File System Safe Universal Character Set Transformation Format (FSS-UTF)
ISO/IEC 10646 (Unicode) (UCS), , ASCII, , . UCS , C.
, UCS. UCS , . , UCS .
, UCS , . , , , , UCS.
UCS . UCS UTF ( . . .) / ASCII /, Unix. UCS, Unix, , , Unix- .
, UCS. , Unis UCS, .
/
, UCS , UCS, . , .
, , UCS:
- .
. - .
ASCII. UCS, ASCII, ASCII. - UCS .
- .
- , , .
- , (. ..).
FSS-UTF
UCS UCS
[0,0x7fffffff]
1, 2, 3, 4, 5, 6 . , . , 10XXXXXX, UCS.
: .
Bits Hex Min Hex Max Byte Sequence in Binary 1 7 00000000 0000007f 0vvvvvvv 2 11 00000080 000007FF 110vvvvv 10vvvvvv 3 16 00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv 4 21 00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv 5 26 00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 6 31 04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
UCD — v-. , UCS 0, .
C
wcstombs()
mbstowcs()
, UCS UCS. , :
typedef
struct
{
int cmask;
int cval;
int shift;
long lmask;
long lval;
} Tab;
static
Tab tab[] =
{
0x80, 0x00, 0*6, 0x7F, 0, /* 1 byte sequence */
0xE0, 0xC0, 1*6, 0x7FF, 0x80, /* 2 byte sequence */
0xF0, 0xE0, 2*6, 0xFFFF, 0x800, /* 3 byte sequence */
0xF8, 0xF0, 3*6, 0x1FFFFF, 0x10000, /* 4 byte sequence */
0xFC, 0xF8, 4*6, 0x3FFFFFF, 0x200000, /* 5 byte sequence */
0xFE, 0xFC, 5*6, 0x7FFFFFFF, 0x4000000, /* 6 byte sequence */
0, /* end of table */
};
int
mbtowc(wchar_t *p, char *s, size_t n)
{
long l;
int c0, c, nc;
Tab *t;
if(s == 0)
return 0;
nc = 0;
if(n <= nc)
return -1;
c0 = *s & 0xff;
l = c0;
for(t=tab; t->cmask; t++) {
nc++;
if((c0 & t->cmask) == t->cval) {
l &= t->lmask;
if(l < t->lval)
return -1;
*p = l;
return nc;
}
if(n <= nc)
return -1;
s++;
c = (*s ^ 0x80) & 0xFF;
if(c & 0xC0)
return -1;
l = (l<<6) | c;
}
return -1;
}
int
wctomb(char *s, wchar_t wc)
{
long l;
int c, nc;
Tab *t;
if(s == 0)
return 0;
l = wc;
nc = 0;
for(t=tab; t->cmask; t++) {
nc++;
if(l <= t->lmask) {
c = t->shift;
*s = t->cval | (l>>c);
while(c > 0) {
c -= 6;
s++;
*s = 0x80 | ((l>>c) & 0x3F);
}
return nc;
}
}
return -1;
}
int mbtowc(wchar_t *p, const char *s, size_t n) { unsigned char *uc; /* so that all bytes are nonnegative */ if ((uc = (unsigned char *)s) == 0) return 0; /* no shift states */ if (n == 0) return -1; if ((*p = uc[0]) < 0x80) return uc[0] != '\0'; /* return 0 for '\0', else 1 */ if (uc[0] < 0xc0) { if (n < 2) return -1; if (uc[1] < 0x80) goto bad; *p &= 0x3f; *p <<= 7; *p |= uc[1] & 0x7f; *p += OFF1; return 2; } if (uc[0] < 0xe0) { if (n < 3) return -1; if (uc[1] < 0x80 || uc[2] < 0x80) goto bad; *p &= 0x1f; *p <<= 14; *p |= (uc[1] & 0x7f) << 7; *p |= uc[2] & 0x7f; *p += OFF2; return 3; } if (uc[0] < 0xf0) { if (n < 4) return -1; if (uc[1] < 0x80 || uc[2] < 0x80 || uc[3] < 0x80) goto bad; *p &= 0x0f; *p <<= 21; *p |= (uc[1] & 0x7f) << 14; *p |= (uc[2] & 0x7f) << 7; *p |= uc[3] & 0x7f; *p += OFF3; return 4; } if (uc[0] < 0xf8) { if (n < 5) return -1; if (uc[1] < 0x80 || uc[2] < 0x80 || uc[3] < 0x80 || uc[4] < 0x80) goto bad; *p &= 0x07; *p <<= 28; *p |= (uc[1] & 0x7f) << 21; *p |= (uc[2] & 0x7f) << 14; *p |= (uc[3] & 0x7f) << 7; *p |= uc[4] & 0x7f; if (((*p += OFF4) & ~(wchar_t)0x7fffffff) == 0) return 5; } bad:; errno = EILSEQ; return -1; }
Nous définissons 7 types d'octets:
T0 0xxxxxxx 7 free bits Tx 10xxxxxx 6 free bits T1 110xxxxx 5 free bits T2 1110xxxx 4 free bits T3 11110xxx 3 free bits T4 111110xx 2 free bits T5 111111xx 2 free bits
Le codage ressemble à ceci:
>From hex Thru hex Sequence Bits 00000000 0000007f T0 7 00000080 000007FF T1 Tx 11 00000800 0000FFFF T2 Tx Tx 16 00010000 001FFFFF T3 Tx Tx Tx 21 00200000 03FFFFFF T4 Tx Tx Tx Tx 26 04000000 FFFFFFFF T5 Tx Tx Tx Tx Tx 32
Quelques notes:
- Deux octets peuvent encoder une puissance de 2 ^ 11 caractères, mais seuls 2 ^ 11-2 ^ 7 seront utilisés. Les codes compris entre 0 et 7F seront considérés comme invalides. Je pense que c'est mieux que d'ajouter un tas de constantes «magiques» sans réel avantage. Cette remarque s'applique à toutes les séquences plus longues.
- Les séquences de 4, 5 et 6 octets existent uniquement pour des raisons politiques. Je préférerais les supprimer.
- La séquence de 6 octets s'étend sur 32 bits, la proposition FSS-UTF n'en couvre que 31.
- Toutes les séquences sont synchronisées avec n'importe quel octet qui n'est pas
Tx.
***
Cette courte correspondance a tout remis à sa place. Bien que cette «serviette légendaire» n'ait pas survécu, il y avait suffisamment d'extraits des archives du serveur de messagerie pour que la communauté reconnaisse leurs mérites. Wikipédia a ajouté les noms de Ken et Robert et un fait amusant sur une serviette dans un restaurant, et sur Internet, cette histoire est diffusée et discutée "telle quelle", sous la forme d'un texte simple contenant plusieurs lettres et une partie d'une décharge du serveur de courrier.
Le système d'exploitation Plan 9 a longtemps été oublié, personne ne se souvient de ce pour quoi il a été écrit et pourquoi il était «numéro neuf», et UTF-8, près de trente ans plus tard, est toujours d'actualité et ne va pas prendre sa retraite.
Il semblerait que ce ne soit qu'un encodage, mais même une histoire aussi simple peut être divertissante si vous vous y penchez un peu. À l'aube du développement de la technologie, il était impossible de prédire ce qui allait tourner et entrer dans l'histoire, et ce qui serait oublié.
Source des archives
