UTF-8, Le désormais standard du web.

98,9% des pages web utilisent UTF-8. Chaque emoji que tu envoies, chaque caractère accentué que tu lis, chaque site en japonais, en arabe ou en cyrillique que tu visites, tout ça repose sur UTF-8. C'est le langage invisible d'Internet, le standard qui permet à un développeur français de collaborer avec un collègue russe sans que les accents ne se transforment en hiéroglyphes incompréhensibles.

Alors, combien de temps il a fallu pour concevoir un standard aussi crucial ? Des années de comités internationaux ? Des dizaines de réunions de standardisation ? Des centaines de pages de spécifications ?

Non. Une soirée. Plus précisément, un dîner dans un restaurant du New Jersey, deux génies de l'informatique, un napperon en papier, et un stylo.

Remontons quelques années en arrière pour comprendre le chaos dans lequel vivait l'informatique pré-UTF-8.

Dans les années 80-90, envoyer un simple email avec des accents d'un ordinateur français à un ordinateur russe relevait de la loterie. Tu écrivais "café" et ton correspondant recevait "cafÚ". Tu envoyais une phrase en cyrillique, elle arrivait en caractères grecs. Le phénomène avait même un nom poétique en japonais : mojibake, littéralement "transformation de caractères".

Le problème ? Chaque région du monde avait inventé son propre système pour encoder les caractères. ASCII (créé en 1963) gérait les 128 caractères de base de l'anglais. Parfait pour "Hello World", catastrophique pour "Bonjour le monde". Pour les autres langues, c'était la jungle. ISO-8859-1 pour l'Europe de l'Ouest, ISO-8859-5 pour le cyrillique, ISO-8859-7 pour le grec, sans parler des dizaines de "code pages" Windows qui ajoutaient encore plus de confusion.

Le résultat ? Le même octet, la valeur 224 par exemple, pouvait représenter à (a accent grave), α (alpha grec), ou Я (Ya cyrillique) selon l'encodage utilisé. Les développeurs passaient leur temps à jouer aux devinettes : "Est-ce que ce fichier est en Latin-1 ou en Windows-1252 ? Et pourquoi mes guillemets se sont transformés en symboles bizarre ?"

Unicode arrive en scène au début des années 90 avec une promesse séduisante. Un seul tableau géant contenant tous les caractères de toutes les langues du monde. Génial sur le papier. Sauf que leur première solution technique, appelée UCS-2 (puis UTF-16), était un désastre pratique.

L'idée d'UTF-16 ? Utiliser systématiquement 2 octets (16 bits) pour chaque caractère au lieu d'un seul. Le problème ? Ça doublait instantanément la taille de tous les fichiers texte anglais. Plus grave encore, ça cassait tout. Tous les outils Unix (grep, sed, cat, ls...) reposaient sur un principe simple, le texte est une suite d'octets où le zéro (0x00) marque la fin d'une chaîne. Avec UTF-16, le simple mot "Hello" s'écrivait H\0e\0l\0l\0o\0 , des zéros partout. Résultat ? Tous les programmes plantaient, pensant que chaque lettre était la fin du fichier.

En 1992, le monde de l'informatique était donc coincé. Soit garder le chaos des encodages multiples, soit adopter UTF-16 et tout réécrire de zéro. Aucune solution n'était acceptable.

C'est dans ce contexte qu'un coup de téléphone change tout.

Pour comprendre la suite, il faut savoir qui étaient Ken Thompson et Rob Pike en septembre 1992.

Ken Thompson, c'est tout simplement l'un des titans de l'histoire de l'informatique. Né à la Nouvelle-Orléans en 1943, il entre aux Bell Labs en 1966. Trois ans plus tard, avec Dennis Ritchie, il crée Unix. Oui, The Unix, le système d'exploitation qui est l'ancêtre de Linux, macOS, Android, et d'à peu près tout ce qui fait tourner Internet aujourd'hui. Pour ça, il reçoit le prix Turing en 1983 (l'équivalent du Nobel en informatique), puis la National Medal of Technology en 1998, puis le Japan Prize en 2011. Entre-temps, il crée le langage B (l'ancêtre du C), développe Belle (le premier ordinateur champion du monde d'échecs), et plus tard, chez Google, co-crée le langage Go.

Ken Thompson, c'est le genre de personne qui invente des choses fondamentales presque par accident, avec un pragmatisme déconcertant. Sa philosophie ? "UNIX is a first-person kind of operating system. It has no more than it needs." Pas de fioritures, juste l'essentiel, élégant.

Rob Pike, lui, c'est le polymathe. Canadien, arrivé à Bell Labs dans les années 80, il crée le premier système de fenêtrage pour Unix en 1981. Il co-écrit avec Brian Kernighan le livre de référence "The Unix Programming Environment". Mais ce qui le rend unique, c'est qu'en dehors de l'informatique, Rob Pike est... médaillé d'argent olympique de tir à l'arc aux Jeux de 1980. Il a même participé à des émissions télé avec Penn & Teller pour faire des démonstrations. Plus tard, il créera Plan 9 (un système d'exploitation expérimental), Inferno, et évidemment Go avec Thompson.

En 1992, ces deux génies travaillent ensemble sur Plan 9 from Bell Space, un système d'exploitation expérimental qui explore des idées avancées pour l'époque. Le projet est "close to shipping", sur le point de sortir pour des universités partenaires. Et ils ont un problème, comment gérer proprement tous les caractères du monde dans Plan 9 ?

Ils ont donc déjà réfléchi au problème Unicode. Ils connaissent UTF-16. Et ils savent que c'est bancal.

Mercredi 2 septembre 1992, fin d'après-midi. Rob Pike reçoit un appel de représentants d'IBM et du consortium X/Open, basés à Austin, Texas. Ces derniers travaillent sur une nouvelle proposition d'encodage Unicode appelée FSS-UTF (File System Safe UTF), conçue par Dave Prosser. Ils veulent l'avis de Pike et Thompson.

Pike regarde rapidement la spec. Le problème lui saute aux yeux presque immédiatement. FSS-UTF n'est pas auto-synchronisant. Concrètement, si tu reçois un flux de texte et que tu arrives au milieu (par exemple, tu ouvres un fichier à la moitié, ou tu te connectes à un stream en cours), tu ne peux pas savoir où commencent et finissent les caractères. Tu es perdu. Pour Pike, qui a passé des années à penser les systèmes Unix où les outils lisent et manipulent des flux texte à la volée, c'est rédhibitoire.

Il appelle Thompson. Ils discutent. Et décident d'aller dîner pour en parler tranquillement.

Le soir du 2 septembre 1992, dans un diner du New Jersey (dont personne ne connaît plus le nom, malheureusement), Ken Thompson sort un stylo et commence à griffonner sur le napperon en papier posé sur la table.

Il dessine le système de "bit-packing", ou comment organiser les bits pour que chaque séquence de caractères soit reconnaissable. Il esquisse les règles. Un octet commence par certains bits pour indiquer combien d'octets suivent. Tout caractère ASCII classique (0-127) reste un seul octet, identique. Pas de byte nul. Pas de slash. Compatible avec les noms de fichiers Unix.

Pike regarde, pose des questions, valide des choix. Thompson ajuste. En quelques heures, sur ce napperon, le design d'UTF-8 prend forme.

Des années plus tard, Pike écrira dans un email : "I very clearly remember Ken writing on the placemat and wished we had kept it!" (Je me souviens très clairement de Ken écrivant sur le napperon et j'aurais tellement voulu qu'on le garde !).

Oui, le napperon a été jeté. Cette serviette en papier qui contenait le brouillon du standard utilisé par 98,9% du web mondial a fini à la poubelle d'un diner du New Jersey. Quelque part, un historien de l'informatique pleure.

Le même soir, en rentrant, Ken Thompson se met au code. À 23h44, le premier fichier /usr/ken/utf/xutf apparaît dans les archives de Plan 9 (timestamp découvert bien plus tard par Russ Cox, un ingénieur Google).

Jeudi 3 septembre : Thompson écrit le code de "packing" et "unpacking", les fonctions qui convertissent les caractères Unicode en séquences UTF-8 et inversement. Pike, de son côté, attaque les bibliothèques C et les bibliothèques graphiques de Plan 9 pour qu'elles utilisent UTF-8.

La nuit du jeudi au vendredi se passe en coding.

Vendredi 4 septembre, 3h37 du matin : Ken envoie un email à Rob. Le sujet ? "you might want to look at /usr/ken/utf/utf.c and see if you can make it prettier." Traduction : "J'ai fini ma partie, maintenant arrange ça pour que ce soit propre."

Vendredi 4 septembre, dans la journée : Tout est terminé. Plan 9 fonctionne entièrement en UTF-8. Tous les fichiers texte convertis. Toutes les bibliothèques mises à jour. Un système d'exploitation complet, internationalisé, en moins de trois jours de travail.

Lundi 7 septembre : Le consortium X/Open vote. La proposition de Thompson et Pike est adoptée.

Mardi 8 septembre, 3h22 du matin : Ken Thompson envoie l'email d'annonce officiel au consortium : "We have converted Plan 9 to use this encoding and are about to issue a distribution to an initial set of university users." (Nous avons converti Plan 9 pour utiliser cet encodage et nous sommes sur le point de le distribuer à des universités partenaires.)

Six jours. Du mercredi soir au mardi matin. Un problème identifié, une solution conçue sur un napperon, un système d'exploitation entièrement converti.

C'est l'histoire d'un des standards les plus fondamentaux d'Internet.

Techniquement, qu'est-ce qui rend UTF-8 si brillant ?

Thompson et Pike ont posé six contraintes dans leur proposition originale :

Le point 6, c'est la clé. C'est exactement ce qui manquait à FSS-UTF et c'est ce que Pike avait immédiatement identifié comme problématique.

En pratique, ça donne quoi ? Prenons l'exemple du caractère € (euro) :

Si tu arrives au milieu de la séquence (disons au deuxième octet 10000010), tu vois immédiatement que c'est un octet de continuation. Tu recules jusqu'à trouver un octet qui commence par autre chose que 10, et hop, tu es re-synchronisé.

Résultat concret ? Tous les outils Unix fonctionnent sans modification. grep, sed, cat, sort , tout continue de marcher. Tu peux chercher "café" dans un fichier UTF-8 avec un simple grep café fichier.txt, et ça fonctionne. Essaie de faire pareil avec UTF-16, bon courage.

Mais inventer un standard génial, c'est une chose. Le faire adopter par le monde entier, c'en est une autre.

Janvier 1993 : Pike et Thompson présentent UTF-8 à la conférence USENIX à San Diego. La communauté Unix adore. Plan 9 sort officiellement avec UTF-8 par défaut.

1998 : L'IETF (Internet Engineering Task Force) adopte officiellement UTF-8 dans la RFC 2277. HTML 4.0 recommande UTF-8 comme encodage préféré.

Mais il y a un ÉNORME problème : Microsoft.

Quand Windows NT a été développé au début des années 90, UTF-8 n'existait pas encore. Microsoft a basé toute son API sur... UTF-16. Toutes les fonctions Windows (CreateFile, WriteFile, etc.) prennent des chaînes en UTF-16. Pire, Microsoft utilisait le terme "Unicode" comme synonyme d'UTF-16, créant une confusion monstre.

Pendant des années, il était impossible d'utiliser UTF-8 proprement avec les fonctions standard de Windows. Tu devais convertir manuellement UTF-8 en UTF-16 pour chaque appel système, puis reconvertir dans l'autre sens. C'était l'enfer.

Pendant ce temps, le web bascule progressivement :

Et Microsoft ? Il leur a fallu 27 ans pour admettre l'évidence.

2019 : La documentation officielle de Microsoft écrit enfin noir sur blanc : "UTF-16 [...] is a unique burden that Windows places on code" (UTF-16 est un fardeau unique que Windows impose au code). SQL Server 2019 intègre enfin le support natif d'UTF-8 et annonce 35% de performances en plus par rapport à UTF-16.

Mieux vaut tard que jamais.

Pendant des années, l'invention d'UTF-8 a été attribuée à tort à... IBM. Ou à X/Open. Ou à Dave Prosser. Rarement à Ken Thompson et Rob Pike.

Pourquoi ? Parce que la présentation à USENIX était sous le nom d'X/Open. Parce que les premiers documents officiels mentionnaient IBM. Et surtout, parce que Thompson et Pike ne se sont pas battus pour corriger.

En 2003, plus de 10 ans après les faits, Rob Pike écrit finalement un email public pour remettre les pendules à l'heure. Pas par ego, mais parce que trop de gens demandaient. Dans cet email, il raconte toute l'histoire : le dîner, le napperon, les six jours. Et il conclut avec une phrase magnifique :

"We were so happy that UTF-8 was catching on that we didn't care about the credit."

Ils étaient tellement heureux que ça marchait qu'ils se fichaient d'être crédités.

C'est ça, l'esprit Bell Labs des années 90. Pas de personal branding, pas de marketing agressif. Juste : "Est-ce que ça résout le problème ? Est-ce que c'est élégant ? Est-ce que ça marche ?" Si oui, le reste n'a pas d'importance.

La prochaine fois que tu envoies un emoji dans Slack, que tu lis un article en japonais, que tu copie-colles du code avec des caractères cyrilliques, que tu debug une API qui renvoie du texte avec des accents, pense à ce napperon de restaurant.

Ce bout de papier jeté à la poubelle contenait la solution à un problème qui paralysait l'informatique mondiale. Il a été griffonné en quelques heures par deux types qui buvaient un café dans un diner du New Jersey. Pas de PowerPoint. Pas de comité de validation. Pas de roadmap sur trois ans.

Juste un problème bien posé, deux esprits exceptionnellement préparés, et la liberté d'expérimenter.

les meilleures solutions ne sortent pas toujours des processus formels. Parfois, elles naissent d'une conversation informelle, d'un coup de téléphone inattendu, d'un dîner entre collègues. Ce qui compte, ce n'est pas le cadre, c'est la profondeur de compréhension du problème et l'audace de proposer quelque chose de radicalement simple.

Thompson et Pike auraient pu dire : "UTF-16 est le standard Unicode officiel, on va l'utiliser." Ils auraient pu se plier aux contraintes existantes. Mais ils ont fait ce que font les vrais ingénieurs, ils ont remis tout à plat, identifié les vrais problèmes (pas de synchronisation, incompatibilité Unix), et conçu une solution qui les résolvait élégamment.

Aujourd'hui, 98,9% du web parle UTF-8. Chaque emoji, chaque caractère accentué, chaque idéogramme chinois passe par l'encodage dessiné sur ce napperon perdu.

Et quelque part, dans un diner du New Jersey, un serveur a probablement jeté à la poubelle l'artefact le plus important de l'histoire moderne du web.

Rob Pike l'a dit lui-même : "I wished we had kept it."

Nous aussi, Rob. Nous aussi.