UTF-8

UTF-8 (Unicode Transformation Format, 8 bits) est un encodage à largeur variable pour les caractères Unicode. Chaque point de code est encodé sur 1 à 4 octets selon sa valeur : les caractères ASCII (U+0000 à U+007F) prennent un octet ; les extensions latines courantes et le grec/cyrillique deux ; les idéogrammes CJK trois ; les emoji et scripts rares quatre.

Conçu par Ken Thompson et Rob Pike en 1992, principalement pour Plan 9. Propriétés clés :

• Compatible ASCII. Le texte pur ASCII est du UTF-8 valide octet par octet.
• Auto-synchronisant. Si un flux est corrompu en milieu de caractère, le décodeur peut trouver la frontière du caractère suivant sans revenir en arrière.
• Pas de problème d’ordre des octets. Les octets sont traités de gauche à droite ; il n’y a pas de distinction gros-boutiste vs petit-boutiste.
• Compact pour les scripts latins, moins compact qu’UTF-16 pour le contenu à dominante CJK (3 octets par caractère contre 2).

UTF-8 est l’encodage dominant sur le web — plus de 98 % des pages en 2024. C’est le défaut pour HTML5, JSON (où la spécification RFC 8259 impose en réalité UTF-8), et pratiquement chaque protocole moderne. Les anciens encodages (Windows-1252, ISO-8859-1, Shift-JIS) survivent dans les systèmes patrimoniaux mais devraient être convertis à l’entrée de toute pile moderne.

La controverse du BOM (Byte Order Mark) : UTF-16 et UTF-32 utilisent un BOM de 2 ou 4 octets au début d’un fichier pour déclarer l’ordre des octets, mais UTF-8 n’a pas d’ordre à marquer. Les outils Microsoft préfixent systématiquement un BOM UTF-8 de 3 octets (EF BB BF) de toute façon, tandis que les outils Unix ne le font généralement pas. Résultat : les scripts shell enregistrés depuis Notepad se cassent, les imports CSV affichent des caractères parasites dans la première cellule, et les analyseurs YAML/JSON rejettent le fichier. La norme Unicode tolère mais n’exige pas un BOM UTF-8 ; la recommandation moderne est “ne pas en ajouter un.” Si vous recevez un fichier avec un BOM, supprimez-le à la lecture.

Longueur de chaîne vs longueur d’octet — le piège toujours pertinent : dans la plupart des langages, "hello".length renvoie 5 (caractères) mais Buffer.byteLength("hello", "utf8") renvoie 5 (octets — égaux pour l’ASCII). Pour "café", la longueur en caractères est 4 mais la longueur en octets est 5 (le é vaut 2 octets). Pour "🎉", la longueur en caractères en JavaScript est 2 (paire de substitution) mais la longueur en octets est 4 et la longueur en graphèmes est 1. Tronquer des chaînes UTF-8 par nombre d’octets sans conscience des graphèmes produit régulièrement du mojibake — la correction standard est d’utiliser l’API Intl.Segmenter (navigateurs modernes) ou le package npm graphemer. Référence : RFC 3629 — UTF-8, a transformation format of ISO 10646.

Exemple concret

Encodons la chaîne “A€🎉”. Le point de code et la séquence d’octets UTF-8 de chaque caractère : A (U+0041) → 1 octet 0x41. € (U+20AC) → 3 octets 0xE2 0x82 0xAC (les bits de poids fort encodent la longueur : 1110xxxx 10xxxxxx 10xxxxxx). 🎉 (U+1F389) → 4 octets 0xF0 0x9F 0x8E 0x89. Total : 8 octets pour 3 caractères. Dans une colonne de base de données déclarée VARCHAR(10) avec sémantique de caractères UTF-8 (PostgreSQL moderne, MySQL avec utf8mb4), cela tient confortablement. Dans une colonne à octets fixes déclarée VARCHAR(10) BYTES (ancien MySQL utf8 qui était en réalité limité à 3 octets), l’encodage à 4 octets de l’emoji ne tient pas du tout — le mode d’échec canonique “impossible de stocker des emoji dans MySQL”. La correction sur MySQL depuis 5.5.3 est d’utiliser utf8mb4 comme charset de colonne et de connexion.

Quand et pourquoi c’est important

Chaque octet que vous traitez sur le web moderne est probablement UTF-8, mais plusieurs couches se trompent encore. Les requêtes HTTP sans Content-Type: text/...; charset=utf-8 explicite peuvent défaut vers ISO-8859-1 dans les anciens proxies ; les anciens jobs ETL mainframe livrent des fichiers EBCDIC qui doivent être transcodés à l’ingestion ; la sortie de la console Windows défaut vers la page de code système (CP-1252 sur la plupart des installations US-anglaises) et corrompt le texte dirigé sans un chcp 65001 préalable. La pratique défensive : déclarer UTF-8 explicitement partout (HTML <meta charset="utf-8">, en-têtes HTTP, pragmas d’encodage de fichier, charsets de connexion de base de données), et valider tout octet entrant contre la grammaire UTF-8 — les séquences d’octets invalides sont un signal fiable d’un décalage de charset en amont. Référence : WHATWG Encoding Standard.