Réparer les caractères bizarres d’un texte (mojibake)

Qu’est-ce que le mojibake ?

Un fichier contient des octets. Un encodage de caractères est la convention qui transforme ces octets en lettres, et le mojibake survient quand celui qui écrit et celui qui lit n’emploient pas la même. Le texte a été écrit en UTF-8, où le é vaut les deux octets C3 A9, puis relu à travers une table sur un octet où ces deux octets sont deux lettres distinctes : Ã et ©. Rien n’a été corrompu en chemin. Les octets sont intacts et sont lus avec le mauvais mode d’emploi.

D’où des dégâts si reconnaissables. Ã, Â, â et € s’agglutinent devant les lettres accentuées, une apostrophe devient ’ et un tiret cadratin devient –. Une fois la forme repérée, cela se déchiffre à l’œil : ’ est toujours une apostrophe typographique vue à travers Windows-1252.

Cela veut dire aussi que la réparation est exacte, et non approchée. Si les octets ont survécu, ramener chaque caractère à l’octet dont il provient puis relire ces octets en UTF-8 restitue le texte d’origine — pas quelque chose d’approchant, l’original. Sur les 1 112 032 points de code que peut assigner Unicode, cet aller-retour à travers Windows-1252 réussit à chaque fois.

Comment le réparer

1. Collez le texte abîmé. Un champ, un nom ou une ligne à la fois donne les meilleurs résultats. Chaque ligne est traitée séparément : un document avec une colonne cassée et onze correctes ne pose donc aucun problème.
2. Lisez le résultat, puis les paires en dessous. Chaque caractère produit est affiché à côté des caractères exacts qu’il remplace. Si é est devenu é et ’ une apostrophe, la réparation est bonne. Si cette liste contient quelque chose que vous vouliez garder, elle ne l’est pas.
3. Recopiez le texte. Si rien n’est réparé, le panneau indique laquelle des deux raisons s’applique : le texte est déjà propre, ou aucune table ne rend compte de tous ses caractères.

Pourquoi cet outil refuse plus souvent que les autres

Un outil de réparation a un défaut dont personne ne parle : réécrire un texte qui n’a jamais été abîmé. C’est pire que de ne rien faire, car le résultat paraît plausible et le lecteur n’a aucune raison de vérifier.

La mesure est facile à faire, et ce site compte 19 655 lignes de prose correcte en espagnol, portugais, français et arabe dans ses propres pages. Avec ftfy, l’implémentation de référence sur laquelle tout le monde s’appuie, la fonction la plus évidente en réécrit 2 514, soit 12,8 pour cent, parce qu’elle redresse aussi les apostrophes typographiques, ce qui n’a rien à voir avec l’encodage. Sa fonction prudente en réécrit cinq. Quatre de ces cinq sont le même paragraphe expliquant ce qu’est un encodage de caractères, en quatre langues, parce que ce paragraphe cite le mojibake qu’il décrit. La cinquième est une phrase portugaise au sujet de la lettre Ã.

Cet outil n’en réécrit aucune, pour une raison structurelle : il répare la ligne entière d’un coup. Chaque caractère doit correspondre à un octet et toute la suite d’octets doit être de l’UTF-8 valide, si bien qu’une seule lettre réellement accentuée ailleurs dans la ligne oppose son veto. Dans la phrase française, les mots là où fournissent les octets E0 20, qu’aucune séquence UTF-8 ne peut être, et la ligne reste intacte.

Le prix est réel et mérite d’être connu. Si votre mojibake a subi ensuite un autre dommage — une espace insécable aplatie en espace ordinaire par un serveur de courrier, par exemple — le compte d’octets ne tombe plus juste et cet outil refusera là où un outil permissif devinerait. Collez un fragment plus court : cela fonctionne souvent.

Limites assumées

Seules des tables sur un octet sont essayées. Vingt-sept par défaut, plus le Mac Roman derrière une case à cocher. Le Mac Roman est écarté pour une raison mesurée et non par intuition : il place l’apostrophe typographique sur un octet qui ouvre une séquence UTF-8, si bien qu’un français ordinaire comme l’échelle passe pour du mojibake valide, et c’est la seule des vingt-huit tables à se déclencher sur une prose qui n’a jamais été abîmée.

Toutes les tables ne sont pas réversibles. Dix-neuf des vingt-huit assignent les 256 octets, et le mojibake qui passe par elles se défait toujours. Les neuf autres laissent des octets non assignés — l’ISO-8859-6 en laisse 45 — et un octet tombé sur l’un d’eux a été remplacé dès la première lecture du texte : il était donc perdu avant même d’arriver ici. Le panneau vous dit dans quel cas vous êtes.

Il arrive que plusieurs tables expliquent le même texte sans être d’accord. La lecture la plus probable est affichée et les autres sont listées plutôt que masquées, car le texte seul ne dit pas laquelle est la bonne. Le mojibake latin est généralement expliqué à l’identique par une douzaine de tables ; le mojibake cyrillique, en général par une seule.

Un caractère demande de l’attention même quand tout le reste fonctionne. Une marque d’ordre des octets en début de ligne, U+FEFF, est supprimée par tout décodeur UTF-8 à moins qu’on ne lui demande explicitement de la garder. C’est ce qui est fait ici : une différence d’une ligne que presque toutes les implémentations oublient.

Enfin, aucun outil ne distingue un exemple cité d’un vrai dégât. Une page consacrée au mojibake en contient volontairement. C’est pourquoi les changements sont montrés appariés au lieu d’être appliqués en silence.

Pourquoi est-ce gratuit ?

Tout se passe dans votre navigateur. Les tables caractère-vers-octet ne voyagent pas avec la page : elles sont lues dans le décodeur de votre propre navigateur, octet par octet, ce qui ne coûte rien et fait que la réponse correspond à ce que votre navigateur tient réellement pour chaque table.

Rien n’est envoyé. Il n’y a pas de serveur à financer, donc pas de compte, pas de limite et pas de filigrane.