Guide
Le cours « Encodage des caractères » est un tutoriel interactif en 14 niveaux qui répond à des questions récurrentes en développement : combien d'octets occupe un caractère chinois ? Pourquoi "😀".length vaut-il 2 ? À quoi sert le = à la fin d'un Base64 ? Un texte illisible, c'est un fichier cassé ou une situation rattrapable ? Chaque niveau donne un texte d'essai (modifiable à volonté) et plusieurs vues — les bits de chaque caractère, les octets, les points de code Unicode, la décomposition UTF-8 octet par octet, les groupes de 6 bits Base64, l'encodage URL en pourcentage, et « ce que donnerait une autre lecture d'encodage » — avec pour objectif de lire un nombre, d'écrire une chaîne hexadécimale ou de saisir un caractère qui remplit une condition ; le validateur coche immédiatement.
Mis à jour le 2026-09-095 sources15 min read
Le cours « Encodage des caractères » est un tutoriel interactif en 14 niveaux qui répond à des questions récurrentes en développement : combien d'octets occupe un caractère chinois ? Pourquoi "😀".length vaut-il 2 ? À quoi sert le = à la fin d'un Base64 ? Un texte illisible, c'est un fichier cassé ou une situation rattrapable ? Chaque niveau donne un texte d'essai (modifiable à volonté) et plusieurs vues — les bits de chaque caractère, les octets, les points de code Unicode, la décomposition UTF-8 octet par octet, les groupes de 6 bits Base64, l'encodage URL en pourcentage, et « ce que donnerait une autre lecture d'encodage » — avec pour objectif de lire un nombre, d'écrire une chaîne hexadécimale ou de saisir un caractère qui remplit une condition ; le validateur coche immédiatement.
L'ordre du cours suit l'histoire de l'encodage : bits et octets → les 128 conventions ASCII → Unicode qui numérote chaque caractère → comment UTF-8 transforme un numéro en 1 à 4 octets → UTF-16 et la longueur des chaînes JavaScript → Base64 qui amène les octets dans du texte → encodage URL → et les deux derniers niveaux consacrés aux textes illisibles : d'où ils viennent et comment remonter de 浣犲ソ à 你好.
Comptez environ 40 minutes. Pour les développeurs front et back, les personnes qui traitent des données, et quiconque a souffert d'un texte illisible, d'un Base64 ou de la longueur d'un emoji ; savoir compter en binaire suffit.
%XX ; « Autre lecture d'encodage » montre la même suite d'octets lue en GBK, Latin-1 ou UTF-16.?lesson=n mène directement à un niveau.Le cours proprement dit est au-dessus de cette page : modifiez le texte d'essai, lisez les vues, remplissez une réponse.
Le niveau 6, « UTF-8 sur deux octets », prend café comme échantillon et demande d'écrire les deux octets de é :
Le niveau 14, « remonter un texte illisible », donne 浣犲ソ interprété comme du GBK et demande de retrouver l'original dans le texte d'essai :
Caractère Point de code Code binaire Modèle UTF-8 Octets
c U+0063 1100011 0xxxxxxx 63
a U+0061 1100001 0xxxxxxx 61
f U+0066 1100110 0xxxxxxx 66
é U+00E9 000 1110 1001 110xxxxx 10xxxxxx C3 A9
→ 11 bits utiles 00011 101001 dans le modèle → 11000011 10101001
Réponse C3 A9 ✓Texte d'essai 中文 octets UTF-8 E4 B8 AD E6 96 87 lu en GBK → 涓枃
Texte d'essai 你好 octets UTF-8 E4 BD A0 E5 A5 BD lu en GBK → 浣犲ソ ← conforme à l'énoncé
Réponse 你好 ✓Un ordinateur ne connaît que 0 et 1. Un bit est un interrupteur ; 8 bits forment un octet, soit valeurs possibles. Additionner les poids des bits convertit le binaire en décimal : 01000001 = 64 + 1 = 65. Tout texte est au final une suite d'octets, et un « encodage de caractères » est une table qui dit quel nombre représente quel caractère — des tables différentes, ce sont des encodages différents.
L'ASCII de 1963 définit 128 caractères sur 7 bits : 0–31 pour les caractères de contrôle (retour à la ligne, tabulation, bip), 48–57 pour les chiffres 0–9, 65–90 pour les majuscules, 97–122 pour les minuscules. La table n'est pas disposée au hasard : majuscules et minuscules ne diffèrent que de 32 (le 6e bit), donc c | 0x20 met une lettre en minuscule ; un chiffre moins 48 donne sa valeur. L'hexadécimal est l'écriture habituelle pour lire des octets, deux chiffres par octet : 0x48 0x69 = Hi. L'ASCII n'utilise que 7 bits, le 8e restait libre — chaque pays l'a ensuite rempli à sa façon (Latin-1, GBK, Shift_JIS…), de manière incompatible : c'est la racine historique des textes illisibles.
Unicode numérote les caractères du monde entier : un point de code s'écrit U+ suivi d'hexadécimal — A = U+0041, 中 = U+4E2D, 😀 = U+1F600. L'espace va de U+0000 à U+10FFFF et se découpe en 17 « plans » ; les caractères courants tiennent presque tous dans le plan de base (U+0000–U+FFFF), emoji et sinogrammes rares vivant dans les plans supplémentaires. Le point clé : un point de code n'est qu'un numéro ; sa transformation en octets dépend de « formes d'encodage » comme UTF-8, UTF-16 ou UTF-32. « Unicode » n'est pas un encodage ; utf-8 en est un.
UTF-8 (RFC 3629) représente un point de code sur 1 à 4 octets, et toute la règle tient dans le préfixe du premier octet :
| Plage de points de code | Octets | Modèle | Bits utiles |
|---|---|---|---|
| U+0000–U+007F | 1 | 0xxxxxxx |
7 |
| U+0080–U+07FF | 2 | 110xxxxx 10xxxxxx |
11 |
| U+0800–U+FFFF | 3 | 1110xxxx 10xxxxxx 10xxxxxx |
16 |
| U+10000–U+10FFFF | 4 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
21 |
On complète le binaire du point de code de zéros à gauche jusqu'au nombre de bits utiles, puis on remplit les x dans l'ordre pour obtenir les octets. é = U+00E9 = 11101001, complété à 11 bits en 00011 101001, remplit le modèle à deux octets : 11000011 10101001 = C3 A9.
Ce choix a trois avantages : un texte ASCII encodé en UTF-8 reste identique octet pour octet (compatibilité descendante totale) ; tout octet suivant commence par 10, donc on retrouve le début du caractère suivant n'importe où dans le flux (auto-synchronisation : perdre un octet ne décale pas toute la suite) ; les encodages de longueurs différentes ne se recouvrent jamais, un zéro comme 00 ne représentant que U+0000 (sûr pour les chaînes C). Le prix : un caractère chinois coûte 3 octets, 50 % de plus que les 2 octets du GBK ; mais l'anglais, la ponctuation et le code ne bougent pas, et UTF-8 est devenu l'encodage de plus de 98 % des pages web.
Les niveaux 7 et 8 font saisir un caractère de 3 octets puis un de 4. Ce dernier révèle un piège encore courant : le jeu utf8 de MySQL ne va en réalité que jusqu'à 3 octets, stocker un emoji provoque une erreur ou une troncature, il faut utf8mb4.
.lengthLes chaînes de JavaScript, Java, C# et de l'API Windows utilisent UTF-16 en interne : chaque unité de code fait 16 bits. Un caractère du plan de base tient sur une unité ; un point de code des plans supplémentaires se scinde en deux unités, une paire de substitution (surrogate pair), dans les plages D800–DBFF et DC00–DFFF. D'où "😀".length === 2, "😀".split("") qui coupe en deux moitiés sans signification, et str[0] qui renvoie la substitution haute. Pour compter les caractères réels, utilisez [...str].length (itération par point de code) ; pour compter les « caractères » perçus (emoji composés, diacritiques), Intl.Segmenter.
Base64 (RFC 4648) n'est pas du chiffrement : c'est un moyen de transport qui transforme des octets quelconques en 64 caractères ASCII imprimables (A–Z a–z 0–9 + /), pour faire passer du binaire là où seul du texte est accepté : pièces jointes, champs JSON, URL data:, JWT. La méthode : 3 octets = 24 bits, découpés en 4 segments de 6 bits (), chacun donnant un caractère par table : Man = 4D 61 6E = 01001101 01100001 01101110 → 010011 010110 000101 101110 → T W F u. Le volume gonfle donc à 4/3 de l'original.
Quand le nombre d'octets n'est pas un multiple de 3, le dernier groupe est incomplet : 1 octet manquant → un =, 2 manquants → deux =, pour que la longueur de sortie reste un multiple de 4. A, un octet de 8 bits, complété à 12 bits, se découpe en 010000 01(0000) → QQ, puis ==. La variante URL-safe remplace + / par - _ (pour éviter l'échappement dans une URL) et omet souvent le =, que le décodage restitue selon la longueur.
Dans une URL, seule une petite partie des caractères ASCII peut apparaître telle quelle (RFC 3986 §2). Les caractères réservés à signification syntaxique (&, =, ?, /), l'espace et tous les caractères non ASCII doivent s'écrire % suivi de l'hexadécimal de l'octet. L'encodage URL, c'est donc d'abord UTF-8, puis un % par octet : 中 → E4 B8 AD → %E4%B8%AD, un caractère chinois devenant 9 caractères. En JavaScript, encodeURIComponent encode le plus complètement (même / ? & =) et convient aux valeurs de paramètres ; encodeURI préserve les caractères de structure et convient à une adresse entière. La soumission de formulaire application/x-www-form-urlencoded écrit en plus l'espace en + — une convention historique des formulaires HTML, pas une partie de la RFC 3986.
Un texte illisible n'est pas une donnée corrompue : c'est de l'écrit avec un encodage A et lu avec un encodage B. Le 中 d'UTF-8 vaut E4 B8 AD :
ä¸, trois lettres d'Europe de l'Ouest — une suite de lettres à diacritiques est le signe d'un « UTF-8 lu comme encodage occidental ».E4 B8 forme le caractère 涓 et le AD restant est une moitié — « sinogrammes bizarres + moitié de caractère » signale un « UTF-8 lu comme GBK » ; 浣犲ソ et 涓枃 en font partie.� (U+FFFD) dès qu'une séquence d'octets est invalide.Tant que les octets d'origine sont intacts, une relecture avec le bon encodage restitue le texte. D'où la première règle de réparation : conserver le fichier original, ne pas convertir en boucle — chaque conversion risque de remplacer un octet invalide par ? ou �, et c'est là la vraie perte d'information. Le niveau 14 fait faire le trajet inverse : reprendre 浣犲ソ en GBK pour retrouver les octets E4 BD A0 E5 A5 BD, puis lire en UTF-8 你好. La méthode moderne consiste à déclarer UTF-8 partout — en-tête HTTP, <meta charset> HTML, connexion à la base de données, boîte de dialogue d'enregistrement — pour que le désaccord n'ait pas l'occasion d'arriver.
L'UTF-16 a deux ordres d'octets, gros-boutiste et petit-boutiste, et les fichiers commencent souvent par une marque d'ordre BOM (FE FF ou FF FE). L'UTF-8 n'a pas de problème d'ordre, mais le Bloc-notes Windows écrivait autrefois un BOM UTF-8 EF BB BF, ce qui fait échouer la première ligne d'un script shell ou ajoute un caractère invisible devant le premier nom de colonne d'un CSV. Si la vue « Décomposition UTF-8 » du cours montre ces trois octets au début, vous savez d'où ils viennent.
TextDecoder du navigateur ; la structure interne de GB18030, Big5 et Shift_JIS n'est pas traitée.length est le nombre de caractères » : en JavaScript, c'est le nombre d'unités UTF-16 ; emoji et certains sinogrammes rares comptent 2. Le n de VARCHAR(n) peut désigner des octets ou des caractères selon la base.encodeURIComponent, sinon &, # et l'espace cassent la structure.Voir %E4%B8%AD%E6%96%87 et reconnaître aussitôt deux caractères chinois en UTF-8 ; voir un JWT en trois segments Base64 séparés par des . et savoir le ramener en JSON ; comprendre pourquoi + et %20 sont reçus différemment côté serveur.
Utilisez la méthode des niveaux 13–14 pour distinguer « UTF-8 lu comme GBK » de l'inverse, puis « rouvrir avec l'encodage » plutôt que « convertir l'encodage » : préserver les octets d'origine est la première règle.
Stockez les emoji en utf8mb4 ; pour estimer un stockage UTF-8, comptez 3 octets par caractère chinois ; vérifiez si l'unité de VARCHAR est l'octet ou le caractère.
Pour tronquer un pseudo, utilisez [...str].slice(0, n) plutôt que str.slice(0, n), sous peine de couper un emoji en deux ; pour compter, décidez entre unités de code, points de code et grappes de graphèmes.
Les emoji à modificateur de peau ou composés par liant ZWJ (comme 👍🏽 ou 👨👩👧) comprennent plusieurs points de code, que la vue « Points de code » liste un à un. Le niveau 8 exige exactement un caractère de 4 octets : prenez un emoji de base sans modificateur, comme 😀.
Ni l'un ni l'autre. c3a9, C3 A9 et c3 a9 sont tous acceptés.
Le cours utilise le TextDecoder('gbk') intégré au navigateur (en pratique un sur-ensemble de GB18030) et affiche � sur une séquence invalide ; certains outils écrivent ? ou sautent l'octet. Le glyphe change, le sens non : « illisible ici ».
Si les octets d'origine sont complets et que seule la lecture était fausse, oui : rouvrez le fichier avec le bon encodage dans un éditeur. Si le fichier a déjà été « converti » et montre de nombreux ?, cette information est perdue et le cours ne la reconstituera pas.
Dans le localStorage du navigateur courant, sans envoi ; le lien « Partager ce niveau » ne contient que le numéro du niveau, pas la progression.
Le cours tourne entièrement en local dans le navigateur : encodage et décodage du texte d'essai, Base64 et encodage URL passent par TextEncoder / TextDecoder et des fonctions pures de la page, sans envoi vers un serveur ; la progression est conservée dans le localStorage de la machine.
TextDecoder du navigateur et algorithmes de décodage, norme des décodeurs GBK / windows-1252 utilisés par la démonstration du cours : https://encoding.spec.whatwg.org/(consulté le 2026-09-09)Mis à jour le 2026-09-09
14 niveaux pour comprendre les bits, les octets, l’ASCII, les points de code Unicode, l’encodage UTF-8 à longueur variable, les groupes Base64, l’encodage URL et l’origine des caractères illisibles
Cet outil n’est pas entièrement traduit ; certains contenus utilisent la langue source ou une langue de repli.
ObjectifL'exemple de texte est la lettre A, dont le seul octet s'affiche sous la forme 01000001. Convertissez ce nombre binaire en décimal et saisissez-le.
| Caractère | Point de code | Octets UTF-8 | Unités de code UTF-16 | Nombre d’octets |
|---|---|---|---|---|
| A | U+0041 | 41 | 0041 | 1 |
Les ordinateurs ne stockent que 0 et 1. Un bit est un commutateur ; 8 bits constituent un octet pouvant contenir 0 à 255, 256 valeurs. Valeurs de position des sommes binaires : 01000001 = 64 + 1 = 65. Tous les textes, images et sons sont en fin de compte des séquences d'octets, et un "codage" définit quel nombre signifie quel caractère.