Vous copiez du texte depuis une base de données ou un document et il ressemble à ceci : « échéance » ou « ‘guillemets typographiques’ ». C'est le mojibake — un texte encodé dans un jeu de caractères et décodé dans un autre. Ce guide explique précisément pourquoi cela se produit, comment identifier quel décalage d'encodage vous avez affaire et comment le corriger en quelques secondes avec les bons outils.
Qu'est-ce que le mojibake ?
Mojibake (文字化け) est un terme japonais signifiant « transformation de caractères » : il désigne le texte illisible qui apparaît quand une chaîne est interprétée avec le mauvais encodage de caractères. Au lieu de « résumé », vous voyez « résumé ». Au lieu d'une apostrophe typographique, vous voyez « ’ ». Les caractères ne sont pas corrompus au niveau des octets — les octets sont sains. Le problème, c'est que le logiciel qui les lit utilise le mauvais référentiel pour traduire les octets en caractères.
Le problème de la traduction octets-caractères
Chaque encodage de caractères est une correspondance entre des nombres (octets) et des caractères. La lettre « e » est l'octet 0x65 dans pratiquement tous les encodages. Mais un « é » accentué est représenté différemment selon l'encodage : en UTF-8 c'est la séquence de deux octets 0xC3 0xA9, tandis qu'en Latin-1 c'est l'octet unique 0xE9. Quand un programme lit les octets UTF-8 0xC3 0xA9 selon les règles Latin-1, il produit deux caractères distincts — Ã et © — au lieu du seul caractère é. Cette substitution, c'est le mojibake.
- é devient é — octets UTF-8 lus comme Latin-1 (le motif le plus courant)
- ü devient ü — même décalage pour le u tréma allemand
- ’ (apostrophe droite) devient ’ — apostrophe typographique UTF-8 mal lue comme Latin-1
- – (tiret demi-cadratin) devient – — courant dans le texte collé depuis Word ou un PDF
- Caractère de remplacement Unicode — un caractère valide a été forcé dans un contexte incapable de le représenter
Note
Pourquoi les erreurs d'encodage se produisent
Les erreurs d'encodage sont un problème de frontières système. Elles surviennent quand le texte traverse une frontière — entre un fichier et une application, entre une base de données et une API, entre un serveur web et un navigateur — et que l'émetteur et le récepteur ne s'accordent pas sur l'encodage du texte. Dans un monde où UTF-8 est la norme universelle, ces erreurs devraient être rares. Mais elles sont fréquentes parce que les systèmes legacy, les outils Windows et certaines bases de données utilisent encore des encodages anciens par défaut.
Les sources les plus courantes
- Fichiers CSV d'Excel — Excel enregistre le CSV en Windows-1252 sous Windows par défaut, pas en UTF-8. Ouvert sous Linux ou en Python, les caractères accentués se dégradent.
- Bases MySQL avec charset latin1 — les anciennes installations MySQL utilisent `latin1` par défaut pour les jeux de caractères des colonnes. Y stocker des données UTF-8 cause du mojibake à la lecture.
- En-têtes et corps d'e-mails — les clients de messagerie qui ne déclarent pas de charset, ou qui lisent mal une déclaration de charset, produisent du mojibake dans les champs De, Objet et corps.
- Extraction de texte PDF — les fichiers PDF intègrent des polices avec des mappages de glyphes personnalisés qui ne correspondent pas toujours aux points de code Unicode standard, produisant une sortie illisible lors de la copie.
- Réponses HTTP sans charset dans Content-Type — un serveur qui envoie `Content-Type: text/html` sans `; charset=utf-8` laisse le navigateur deviner, et il devine souvent faux.
UTF-8 vs Windows-1252 — le décalage le plus fréquent
Windows-1252 (aussi appelé CP1252) est un surensemble du Latin-1 développé par Microsoft pour les langues d'Europe de l'Ouest. Il utilise un octet par caractère et couvre 256 points de code — suffisant pour l'anglais, le français, l'allemand, l'espagnol et le portugais. UTF-8 utilise un à quatre octets par caractère et couvre les 1,1 million de points de code Unicode. Quand du texte UTF-8 est lu comme Windows-1252, les séquences multi-octets produisent les motifs caractéristiques de mojibake de deux ou trois caractères. L'inverse — du texte Windows-1252 lu comme UTF-8 — produit des caractères de remplacement (□ ou ?) car les octets hauts isolés ne sont pas des séquences UTF-8 valides.
Un texte sans métadonnées d'encodage n'est pas du texte — c'est une suite d'octets en attente d'être mal interprétés.
Comment détecter les problèmes d'encodage
Détecter un problème d'encodage est généralement simple : l'apparence visuelle du mojibake est assez distinctive pour identifier le motif du décalage. Mais pour une détection programmatique, ou pour du texte qui semble correct mais contient des problèmes invisibles, vous avez besoin de techniques spécifiques.
Reconnaissance visuelle des motifs
Le diagnostic le plus fiable est le motif de mojibake lui-même. Du texte UTF-8 lu comme Latin-1 produit un préfixe caractéristique « à » suivi d'un second caractère — par exemple é pour é, à pour à, ü pour ü. La ponctuation typographique de Word ou des éditeurs de texte enrichi produit des séquences commençant par †— par exemple ’ pour ’ et “ pour “. Si vous voyez ces séquences, la solution est de ré-encoder les octets du Latin-1 vers l'UTF-8.
Détection programmatique de l'encodage
Pour les fichiers et flux de données dont vous ne pouvez pas voir le contenu visuellement, utilisez la bibliothèque `chardet` (Python) ou le paquet `jschardet` (Node.js) pour détecter automatiquement l'encodage à partir des motifs d'octets. Ces bibliothèques analysent la fréquence et la distribution des valeurs d'octets pour identifier l'encodage le plus probable. Elles ne sont pas précises à 100 % — les chaînes courtes et celles comportant peu de caractères non-ASCII sont plus difficiles à classer avec assurance — mais elles gèrent bien les cas courants. Utilisez le Consultateur de Caractères Unicode pour inspecter des points de code individuels et leurs représentations en octets attendues lors du débogage de caractères précis.
Tip
Comment corriger le mojibake en ligne
Le moyen le plus rapide de corriger du texte mojibake est l'Outil de Réparation Unicode et d'Encodage. Il fonctionne entièrement dans votre navigateur — aucun envoi serveur, aucun enregistrement — et gère automatiquement les décalages UTF-8/Latin-1 les plus courants, la dégradation des guillemets typographiques et la suppression des caractères invisibles.
Identifiez le motif du décalage d'encodage
Avant de corriger le mojibake, identifiez de quel décalage il s'agit. Observez les caractères illisibles : si vous voyez des séquences é ou ü, le texte est de l'UTF-8 lu comme Latin-1. Si vous voyez des séquences ’ ou “, le texte contient des guillemets ou de la ponctuation typographique dégradés de la même manière. Si vous voyez des points d'interrogation ou des symboles □, l'encodage était inversé — des octets non UTF-8 ont été forcés dans un contexte UTF-8.
Collez le texte corrompu dans l'outil de réparation
Ouvrez l'Outil de Réparation Unicode et d'Encodage et collez votre texte mojibake dans le champ de saisie. L'outil analyse immédiatement le texte et identifie la réparation la plus probable : ré-encodage de Latin-1 vers UTF-8, correction des séquences de guillemets typographiques, suppression des caractères de largeur nulle, normalisation des formes Unicode ou suppression des marques d'ordre des octets. La détection se fait dans votre navigateur — votre texte ne quitte pas votre appareil.
Sélectionnez la paire d'encodages et appliquez la correction
Si la détection automatique est correcte, cliquez sur Réparer pour appliquer la correction. Si la sélection automatique ne correspond pas à votre cas, choisissez manuellement l'encodage source (celui avec lequel le texte a été mal lu) et l'encodage cible (celui avec lequel il aurait dû être lu). Pour la plupart des contenus web, la paire est Latin-1 → UTF-8. Pour les fichiers CSV de Windows, c'est souvent Windows-1252 → UTF-8.
Copiez le texte réparé et vérifiez
Après réparation, copiez le résultat et collez-le dans votre contexte d'origine — un éditeur de documents, une interface de base de données ou un fichier de code. Vérifiez que tous les caractères accentués, guillemets et symboles spéciaux s'affichent correctement avant d'enregistrer ou de committer les modifications. Pour une réparation massive en base de données, testez le motif sur un échantillon de lignes avant de l'exécuter sur toute la table.
Outil de Réparation Unicode et d'Encodage
Corrigez le mojibake, réparez les artefacts d'encodage, normalisez l'Unicode et supprimez les caractères invisibles — gratuit, dans le navigateur, sans envoi de fichier.
Motifs de mojibake courants et leurs corrections
Les différents décalages d'encodage produisent des motifs visuels différents. Reconnaître le motif vous indique à la fois la cause et la bonne correction — quelle paire d'encodages appliquer, ou quelle opération de réparation exécuter.
| Motif mojibake | Caractère d'origine | Cause | Correction |
|---|---|---|---|
| é | é (e accent aigu) | UTF-8 lu comme Latin-1 | Ré-encoder Latin-1 → UTF-8 |
| ü | ü (u tréma) | UTF-8 lu comme Latin-1 | Ré-encoder Latin-1 → UTF-8 |
| À | À (a accent grave) | UTF-8 lu comme Latin-1 | Ré-encoder Latin-1 → UTF-8 |
| ’ | ’ (apostrophe droite) | UTF-8 lu comme Latin-1 | Ré-encoder Latin-1 → UTF-8 |
| “ | “ (guillemet ouvrant) | UTF-8 lu comme Latin-1 | Ré-encoder Latin-1 → UTF-8 |
| – | – (tiret demi-cadratin) | UTF-8 lu comme Latin-1 | Ré-encoder Latin-1 → UTF-8 |
| ’ | ’ (apostrophe droite) | UTF-8 lu comme Windows-1252 | Ré-encoder Windows-1252 → UTF-8 |
| ? ou □ | Tout caractère non-ASCII | Non-UTF-8 dans un contexte UTF-8 | Trouver l'encodage d'origine avec chardet |
Le problème du double encodage
Une variante particulièrement dommageable est le double mojibake — quand le texte a été mal encodé deux fois. Cela produit des séquences comme © au lieu de ©, ou Æ¢ au lieu de ¢. Cela arrive quand un texte déjà mojibake est enregistré puis relu une seconde fois avec le mauvais encodage. La réparation exige deux cycles de ré-encodage en ordre inverse. L'Outil de Réparation Unicode et d'Encodage détecte et gère automatiquement les motifs de double encodage les plus courants.
Warning
Prévenir les erreurs d'encodage
La solution durable au mojibake est d'imposer l'UTF-8 à chaque frontière de votre système — stockage de fichiers, base de données, API et couche web. Voici les endroits précis où les déclarations d'encodage doivent être explicites.
Bases de données — déclarez l'UTF-8 partout
Dans MySQL et MariaDB, définissez le jeu de caractères par défaut sur `utf8mb4` (pas `utf8` — le `utf8` de MySQL ne couvre que les séquences de 3 octets et exclut les emoji et les caractères Unicode rares). Définissez-le à trois niveaux : la valeur par défaut du serveur dans `my.cnf`, le charset de la base et les charsets des colonnes individuelles. Dans PostgreSQL, la valeur par défaut est déjà UTF-8 pour les nouvelles installations. Dans SQLite, le texte est toujours UTF-8 par défaut.
-- MySQL: set all levels to utf8mb4
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;Fichiers — enregistrez toujours en UTF-8
Quand vous enregistrez des fichiers texte, des exports CSV ou des fichiers de configuration, choisissez toujours UTF-8 comme encodage. Dans VS Code, l'encodage apparaît dans la barre d'état — cliquez pour le modifier. Dans Excel, exportez le CSV avec « CSV UTF-8 (Séparé par des virgules) » plutôt que le « CSV (Séparé par des virgules) » par défaut. Pour les scripts Python qui écrivent des fichiers, passez toujours `encoding='utf-8'` explicitement à l'appel `open()` au lieu de vous fier au défaut du système. Nettoyez le texte après collage depuis des sources externes avec le Nettoyeur de Texte d'E-mail, qui supprime les caractères invisibles et normalise les espaces automatiquement.
API et HTTP — déclarez le charset dans Content-Type
Chaque réponse HTTP contenant du texte doit inclure une déclaration de charset : `Content-Type: application/json; charset=utf-8` ou `Content-Type: text/html; charset=utf-8`. Sans elle, le client devine — et les anciens clients HTTP utilisent Latin-1 par défaut pour les réponses `text/html`. Pour les pages HTML, ajoutez aussi `<meta charset="UTF-8">` comme premier élément dans `<head>`. Pour les API JSON, `Content-Type: application/json` implique l'UTF-8 selon la RFC, mais être explicite élimine l'ambiguïté et prévient les problèmes avec les clients non conformes.
Liste de contrôle d'encodage par contexte
- Fichiers Python : ajoutez l'en-tête `# -*- coding: utf-8 -*-` pour Python 2 ; en Python 3 c'est inutile mais inoffensif
- Chaînes de connexion MySQL : incluez `charset=utf8mb4` dans le DSN — p. ex. `mysql+pymysql://user:pass@host/db?charset=utf8mb4`
- Lectures de fichiers Node.js : passez `encoding: "utf8"` à `fs.readFile()` ou utilisez `Buffer.from(data).toString("utf8")`
- Documents XML et HTML : incluez toujours `<?xml version="1.0" encoding="UTF-8"?>` et `<meta charset="UTF-8">`
- Bibliothèques d'envoi d'e-mails : définissez `Content-Type: text/plain; charset=utf-8` et `Content-Transfer-Encoding: 8bit` ou `quoted-printable`
Normalisation Unicode et caractères invisibles
Au-delà du décalage classique UTF-8/Latin-1, deux autres problèmes Unicode produisent des bugs subtils plus difficiles à détecter : les décalages de normalisation et les caractères invisibles. Tous deux peuvent faire échouer les comparaisons de chaînes, manquer des recherches en base de données et rendre les résultats de recherche incomplets — même quand le texte semble identique à l'écran.
Formes de normalisation Unicode
Unicode permet de représenter le même caractère visible de plusieurs façons. La lettre « é » peut être encodée comme un unique point de code précomposé (U+00E9) ou comme la combinaison de « e » (U+0065) suivie d'un accent aigu combinant (U+0301). Les deux se ressemblent à l'écran mais sont des séquences d'octets différentes qui échouent aux comparaisons d'égalité de chaînes. C'est pourquoi chercher « résumé » dans une base de données manque parfois des résultats — le texte stocké utilise une autre forme de normalisation. NFC (Décomposition Canonique suivie de Composition Canonique) est la forme normale recommandée pour la plupart des applications. L'Outil de Réparation Unicode et d'Encodage normalise le texte en NFC dans le cadre de son processus de réparation.
Caractères invisibles et de largeur nulle
Les caractères de largeur nulle sont des points de code Unicode qui occupent de la place dans une chaîne mais ne rendent rien de visible. Ils sont fréquemment insérés par les traitements de texte, les applications de chat et les opérations copier-coller depuis des PDF ou des pages web. Les coupables habituels sont l'espace sans chasse (U+200B), l'espace insécable sans chasse (U+FEFF, aussi la marque d'ordre des octets) et divers caractères de contrôle bidirectionnels (U+200E, U+200F, U+202A-U+202E). Ces caractères cassent les motifs regex, perturbent les tokeniseurs et font que des chaînes d'apparence identique se comparent comme différentes. Utilisez le Consultateur de Caractères Unicode pour identifier les points de code suspects dans une chaîne.
Note
Consultateur de Caractères Unicode
Recherchez n'importe quel caractère Unicode par point de code ou nom, ou collez un caractère pour identifier des points de code invisibles ou suspects dans votre texte.
Key takeaways
- Le mojibake vient de la lecture des octets d'un texte avec le mauvais encodage — le plus souvent des octets UTF-8 lus comme Latin-1 ou Windows-1252.
- Le motif é (pour é) est la signature diagnostique du mojibake UTF-8-vu-comme-Latin-1 — reconnaître le motif indique la correction exacte à appliquer.
- L'Outil de Réparation Unicode et d'Encodage détecte et corrige automatiquement les motifs de mojibake courants, les caractères invisibles et les problèmes de normalisation Unicode dans votre navigateur.
- Ne corrigez jamais le mojibake par rechercher-remplacer sur les séquences illisibles — réparez toujours au niveau de l'encodage en ré-encodant correctement les octets.
- Prévenez les erreurs d'encodage en déclarant l'UTF-8 explicitement à chaque frontière du système : fichiers, bases de données, réponses d'API et en-têtes HTTP.
- Les caractères invisibles (espace sans chasse, BOM, contrôles bidirectionnels) causent des échecs de comparaison et de recherche même quand le texte paraît correct — ils doivent être supprimés par programmation.
- Les décalages de forme de normalisation Unicode (NFC vs NFD) font échouer les comparaisons d'égalité entre chaînes d'apparence identique — normalisez en NFC avant de stocker ou de comparer du texte.