Convertisseur d'encodage et réparateur de mojibake

Réponses rapides

Qu'est-ce que le mojibake ?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

Ce que fait cet outil

Exemples commentés

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(récupération partielle uniquement)

Comment utiliser cet outil

1. 1

   Collez le texte illisible

   Mettez-le tel quel, sans identifier l'encodage au préalable. Un court fragment suffit : une douzaine de caractères permet en général de fixer la chaîne.

2. 2

   Lisez le premier candidat et son badge

   Exact signifie que la chaîne reproduit exactement votre saisie en aller-retour. Partiel signifie que non : traitez alors le résultat comme une piste.

3. 3

   Regardez la chaîne d'encodage

   Chaque candidat indique l'encodage dans lequel le texte a réellement été écrit et celui qui l'a mal lu. Cela vous dit quoi corriger en amont, pas seulement ce que disait le texte.

4. 4

   Inspectez les octets si nécessaire

   La seconde section montre n'importe quel texte sous forme d'octets dans tous les encodages courants, et décode l'hexadécimal brut dans l'autre sens. Servez-vous-en pour dimensionner des colonnes ou vérifier des trames de protocole.

Les erreurs qui aggravent la situation

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# Confirmez d'abord l'encodage actuel
file -I correct.txt   # charset=utf-8 → rien à convertir

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- Passez par un type binaire pour préserver les octets au lieu de les réinterpréter
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Prendre le premier candidat quoi que dise le badge
db.update(row.id, candidates[0].text);

// N'écrire que ce qui passe l'aller-retour
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# Décodez une seule fois à la frontière, avec l'encodage réellement utilisé par le fichier
with open(path, encoding='gbk') as f:
    text = f.read()

Quand vous en avez besoin

Une migration de base de données a produit du charabia

Les anciennes tables MySQL déclarées en latin1 alors qu'elles contiennent en réalité des octets UTF-8 sont de loin la source la plus fréquente. Collez ici une ligne illisible pour confirmer la vraie chaîne avant d'écrire votre ALTER TABLE — lancer la conversion dans le mauvais sens transforme un problème récupérable en problème définitif.

Un CSV ouvert dans Excel n'affiche que du charabia

Excel sous Windows suppose toujours la page de code du système pour les fichiers CSV sans BOM, si bien que les exports UTF-8 ressortent en mojibake. Confirmez la chaîne ici, puis ré-exportez avec un BOM ou importez via l'assistant texte en fixant explicitement l'encodage.

Les logs d'un service hérité

Les applications écrites pour GBK ou Shift_JIS produisent des logs dans ces encodages, et les agrégateurs de logs modernes lisent tout en UTF-8. Collez une ligne pour la récupérer — et comme rien n'est envoyé nulle part, vous pouvez le faire avec des logs de production.

Des noms de fichiers cassés par une archive ZIP

Le format ZIP n'a pas de champ d'encodage : les archives créées sur un Windows chinois ou japonais transportent des noms de fichiers en GBK ou Shift_JIS que les outils Unix lisent comme de l'UTF-8. Récupérez ici les vrais noms avant de renommer quoi que ce soit.

Dimensionner une colonne de base de données

La vue octets montre le même texte dans tous les encodages à la fois. Un caractère chinois occupe 3 octets en UTF-8 mais 2 en GBK, et c'est exactement le genre d'écart qui transforme un VARCHAR(50) en bug de troncature.

Comment naît le mojibake

Les octets survivent, le sens non

Encoder associe des caractères à des octets ; décoder fait le chemin inverse. Le mojibake est un décodage avec la mauvaise table. Les octets n'ont jamais été abîmés, c'est pourquoi rejouer le mauvais décodage à l'envers restitue exactement l'original — à condition que ce mauvais décodage n'ait rien jeté.

Pourquoi les textes CJC souffrent le plus

L'ASCII occupe 0x00–0x7F et tous les encodages courants s'accordent dessus, donc le texte anglais passe indemne. Le chinois, le japonais et le coréen exigent des séquences multi-octets, et les encodages divergent sur la façon de les grouper. UTF-8 utilise trois octets par caractère chinois, GBK en utilise deux. Donnez des octets UTF-8 à un décodeur GBK et le découpage se décale, produisant un nombre différent de caractères différents.

Le test d'aller-retour

Pour chaque chaîne candidate, l'outil ré-encode le texte récupéré avec le premier encodage et le redécode avec le second. Si cela reproduit exactement la saisie, la chaîne explique chaque caractère et le candidat est marqué Exact. Les candidats qui échouent au test restent affichés, car une récupération partielle permet souvent d'identifier le texte même sans le reproduire.

D'où viennent les tables d'encodage

Le TextDecoder du navigateur fournit les tables. Encoder dans l'autre sens est plus délicat, parce que TextEncoder ne gère que l'UTF-8 : l'outil construit donc une table inverse en parcourant l'espace des octets et en demandant au décodeur ce que signifie chaque séquence. La correspondance reste ainsi toujours cohérente avec le comportement du navigateur lui-même, et aucune table n'est téléchargée sur votre appareil.

L'heuristique de classement, et ses limites

Au-delà du test d'aller-retour, les candidats sont notés selon la proportion de caractères chinois courants (ceux dont l'octet de tête GBK tombe entre 0xB0 et 0xF7), moins des pénalités pour les caractères de remplacement, les katakanas demi-chasse et les caractères de contrôle. Les katakanas demi-chasse sont un signal fort de Shift_JIS, car un texte japonais normal ne s'en sert quasiment jamais. C'est une heuristique : elle départage, elle n'établit pas la vérité.

Éviter que cela se reproduise

Corrigez la source, pas seulement la chaîne de caractères

La chaîne d'encodage affichée sous chaque candidat vous dit quel composant est mal configuré. Réparer le texte sans corriger le charset de la connexion, le lecteur de fichiers ou le paramètre d'export revient à recommencer demain avec de nouvelles données.

Confirmez le sens avant de convertir un fichier entier

Passez d'abord une ligne représentative par cette page. Convertir dans le mauvais sens peut produire des caractères de remplacement et, contrairement à l'erreur initiale, cette étape-là n'est pas réversible.

Fixez l'encodage explicitement partout

Charset de la connexion à la base, Content-Type HTTP, appels d'ouverture de fichier, exports CSV. Chaque endroit qui se rabat sur « l'encodage du système » est un endroit où le même bug revient dès que le code change de machine.

Préférez utf8mb4 à utf8 dans MySQL

L'utf8 de MySQL stocke au plus trois octets par caractère : les emoji et certains caractères chinois rares sont donc tronqués en silence. utf8mb4 est le véritable UTF-8. C'est une panne différente du mojibake et l'outil de récupération n'y peut rien, parce que les octets ont réellement disparu.

Gardez les octets d'origine jusqu'à validation du correctif

Faites une copie avant toute conversion. Tant que les octets d'origine existent, tout mauvais décodage est réversible ; une fois écrasés par des caractères de remplacement, aucun outil de cette page ni d'ailleurs ne les ramènera.

Questions fréquentes