Standards

Les ordinateurs ne stockent pas des lettres ; ils stockent des nombres. Un encodage de caractères est simplement l'accord sur quel nombre signifie quel caractère, afin que l'octet enregistré par un programme soit relu comme la même lettre par un autre. Quand cet accord tient, le texte fonctionne tout simplement ; quand il se brise, le résultat est ce désordre charabia familier qui afflige l'informatique depuis ses tout débuts.

Lorsqu'un document est écrit avec un encodage et lu avec un autre, vous obtenez du mojibake — les accents brouillés, les carrés mystérieux et les points d'interrogation que tout le monde a vus à un moment ou un autre. Un « café » devient « café », un guillemet courbe se transforme en une suite de symboles, et une page entière dans une autre langue peut se dissoudre en charabia. La cause sous-jacente est toujours la même : le rédacteur et le lecteur étaient en désaccord sur quel nombre représente quel caractère.

De l'ASCII à un patchwork d'encodages

Les racines du problème résident dans les encodages limités des débuts de l'informatique. ASCII, l'un des schémas fondateurs, ne couvrait que l'anglais — les lettres latines de base, les chiffres et une poignée de symboles — car il utilisait une petite plage de nombres. C'était suffisant pour les débuts de l'informatique américaine mais ne laissait aucune place aux lettres accentuées, et encore moins aux écritures de la plupart des langues du monde.

Ce qui a suivi a été une mosaïque d'encodages 8 bits incompatibles, chacun comprimant un ensemble différent de caractères additionnels dans le même espace limité. Un encodage couvrait les accents d'Europe occidentale, un autre le cyrillique, un autre le grec, et ainsi de suite, le même nombre signifiant des caractères différents dans chacun. Un document n'avait de sens que si l'on savait exactement lequel de ces encodages il utilisait, et se tromper produisait du mojibake — une situation fragile et sujette aux erreurs.

Comment Unicode a réglé le problème de fond

Unicode a résolu le problème sous-jacent à sa racine. Plutôt que de découper un petit espace de nombres, il attribue à chaque caractère de chaque écriture — latin, cyrillique, arabe, chinois, emoji et bien plus — son propre point de code unique. Unicode est le catalogue universel : une identité unique et convenue pour chaque caractère que l'humanité écrit, supprimant l'ambiguïté qui a condamné l'ancienne mosaïque d'encodages.

Il vaut la peine de séparer deux idées faciles à confondre, car la distinction est la clé pour comprendre le sujet. Unicode définit les points de code — les nombres abstraits attribués aux caractères — mais il ne dit pas par lui-même comment ces nombres sont transformés en octets sur le disque ou sur le réseau. Cette seconde tâche, faire correspondre les points de code à des octets réels, est le rôle d'un encodage, et UTF-8 est l'encodage qui le fait.

Pourquoi UTF-8 a conquis le web

UTF-8 l'a emporté sur les alternatives pour plusieurs raisons concrètes. Il est rétrocompatible avec ASCII, donc tout texte en anglais simple est déjà du UTF-8 valide sans aucun changement. Il est économe en espace pour le texte courant, utilisant un seul octet pour les caractères les plus fréquents et davantage seulement lorsque c'est nécessaire. Et il peut représenter chaque caractère Unicode, de sorte qu'un seul encodage suffit enfin pour toutes les langues à la fois.

Ces propriétés combinées ont fait d'UTF-8 le réglage par défaut écrasant du web moderne, et le standard HTML recommande de le déclarer explicitement. La convention est de placer une déclaration <meta charset="utf-8"> près du haut de chaque document, ce qui indique au navigateur sans ambiguïté comment interpréter les octets qui suivent. Le déclarer supprime toute conjecture et empêche le navigateur de se rabattre sur une hypothèse erronée.

Là où les bugs se glissent encore

Sauter cette déclaration, ou laisser les couches se contredire, est exactement là où les problèmes se glissent encore aujourd'hui. Si un fichier est enregistré dans un encodage mais servi avec un en-tête en revendiquant un autre, ou rendu sans aucune déclaration du tout, un navigateur peut deviner de manière incorrecte et réintroduire le mojibake même qu'Unicode était censé éliminer. Les erreurs sont presque toujours une discordance entre les couches, et non un défaut d'UTF-8 lui-même.

Le conseil pratique est donc d'une simplicité rassurante : enregistrez vos fichiers en UTF-8, servez-les en UTF-8, et déclarez UTF-8. Faites en sorte que ces trois éléments s'accordent et toute une catégorie de bugs d'encodage frustrants et difficiles à tracer disparaît tout simplement. UTF-8 l'a emporté précisément parce qu'il fait du bon comportement le réglage par défaut facile, et aligner toute votre chaîne derrière lui est l'un des gains de fiabilité les moins coûteux du développement web.