Correction de mojibake — réparer du texte illisible

Aperçu

Le charabia n’est pas une détérioration. Ce sont des octets corrects lus avec la mauvaise table. 日本語 encodé en UTF-8 fait neuf octets ; lus comme du Windows-1252, ces mêmes neuf octets donnent 日本語. Rien n’a été perdu — l’interprétation était fausse, et l’inverser restitue exactement l’original.

Cet outil réencode le texte collé en octets à l’aide de l’encodage sous lequel il a probablement été mal lu, décode ces octets avec chaque encodage dans lequel il pourrait réellement avoir été écrit, et classe les résultats. Le premier candidat est la paire qui produit de l’UTF-8 valide sans caractère de remplacement.

Utilisation

1. Collez le texte illisible.
2. Lisez le premier candidat, marqué d’une étoile.
3. S’il n’est pas correct, examinez les autres — chacun porte l’étiquette de la paire qui l’a produit.

Pourquoi le premier candidat est généralement le bon

Le classement n’est pas une supposition sur la langue. Il repose sur une propriété structurelle de l’UTF-8 : l’encodage déclare lui-même la longueur de ses séquences. Un octet de tête indique combien d’octets de continuation suivent, et chaque octet de continuation est identifiable comme tel. Une séquence d’octets arbitraire échoue donc à se décoder en UTF-8 presque immédiatement, et le décodeur du navigateur signale cet échec par des caractères de remplacement.

Ainsi, lorsqu’un candidat se décode en UTF-8 sans aucun caractère de remplacement, c’est une preuve solide plutôt qu’une préférence — les octets étaient de l’UTF-8 valide depuis le début, ce qui est exactement ce qu’on attend d’un texte qui était en UTF-8 avant que quelque chose le lise en Latin-1. Les candidats sont en outre classés selon la persistance des signatures de charabia, et un candidat n’est proposé que s’il les réduit.

Pourquoi le texte correct est laissé intact

Avant de produire un candidat, l’entrée est examinée à la recherche des signatures du charabia : les paires d’octets spécifiques produites par les mauvaises lectures Latin-1 (à /  / †/ ã et leurs proches), les caractères de contrôle C1 de la plage U+0080–U+009F, et les caractères de remplacement U+FFFD.

Un texte qui n’en présente aucun est signalé comme propre et aucun candidat n’est proposé. C’est important car la transformation est destructrice appliquée à du texte correct. Grüße et señor sont de l’allemand et de l’espagnol ordinaires ; passez-les dans une réparation qui les suppose altérés et vous obtenez du non-sens. Un outil qui propose toujours des candidats invite précisément à cette erreur.

Ce qui ne peut pas être récupéré

Si le texte contient ?, � ou des carrés vides, les octets d’origine ont disparu.

La distinction mérite d’être précise. Le charabia préserve les octets et perd l’interprétation : il est donc réversible. La substitution perd les octets — quand un convertisseur rencontre un caractère que son encodage cible ne peut pas représenter, il écrit un remplacement et jette l’original. Aucun outil ne récupère cela, car il ne reste rien à réinterpréter. Si vous pouvez encore obtenir le fichier source, c’est la seule voie.

Le double charabia — altéré, enregistré, puis altéré à nouveau — est parfois récupérable en appliquant la réparation deux fois, mais chaque passe aggrave toute perte, et les résultats se dégradent.

D’où vient le charabia

Le schéma est presque toujours celui d’une valeur par défaut jamais déclarée :

• Un CSV ouvert dans un tableur. Excel sous Windows a longtemps supposé la page de code du système pour les .csv en l’absence de BOM UTF-8, d’où les fichiers exportés pleins d’accents qui s’ouvrent en charabia. Ainsi café devient café.
• Une connexion de base de données dont le jeu de caractères n’a pas été défini. Les données sont stockées correctement et la connexion convertit mal, d’où les mêmes lignes lisibles via un client et illisibles via un autre.
• Les lignes d’objet des courriels. Les en-têtes sont en ASCII seulement, le non-ASCII voyage donc en encoded-words RFC 2047 qui nomment leur propre jeu de caractères. Les objets japonais utilisent encore couramment ISO-2022-JP, et un décodeur qui suppose l’UTF-8 les altère tous.
• Une réponse sans charset dans son Content-Type. Le navigateur devine, et sa supposition dépend de la locale.
• Un nom de fichier ancien dans une archive. ZIP n’a pas de champ de jeu de caractères fiable : des noms créés sous une page de code sont lus sous une autre.

Exemples

• Réparer un CSV importé — collez un champ concerné pour identifier la paire, puis réimportez avec le bon encodage plutôt que de réparer les lignes une à une.
• Lire un objet de courriel altéré — pour un message complet, la visionneuse .eml décode les encoded-words avec le jeu de caractères déclaré par l’en-tête, y compris ISO-2022-JP : l’objet se lit donc correctement sans aucune réparation.
• Diagnostiquer une chaîne de traitement — la paire qui produit la correction vous dit où la conversion est fausse. « Écrit en UTF-8, lu en Windows-1252 » signale une déclaration de charset manquante côté lecture, non un problème de données.
• Vérifier une sortie de journal — un service journalisant dans un encodage et un agrégateur lisant dans un autre ne produisent du charabia que pour les lignes non ASCII, d’où le fait que cela passe inaperçu jusqu’à l’apparition d’un nom ou d’un message d’erreur venant d’un système traduit.

Remarques

Les candidats sont décodés avec le TextDecoder du navigateur : les tables sont donc celles de la plateforme — aucune table d’encodage n’est livrée avec cette page. La prise en charge des encodages multi-octets anciens est exigée par l’Encoding Standard et présente dans tous les navigateurs actuels.

Les encodages couverts sont windows-1252, iso-8859-1, windows-1251 et macintosh du côté mal lu, et utf-8, shift_jis, euc-jp, iso-2022-jp, gbk, big5 et euc-kr du côté original. Jusqu’à huit candidats sont affichés.

Lisez toujours le candidat avant de l’utiliser. Sur un échantillon court, plusieurs paires peuvent produire une sortie plausible, et la vérification structurelle ne peut pas vous dire dans quelle langue le texte était censé être. Tout se passe dans votre navigateur — voir la politique de confidentialité.