Réparer les caractères illisibles (é, ’) — Correcteur d’encodage
Un outil qui répare le mojibake en inversant chaque paire probable d’encodages confondus
Traitement dans le navigateur · aucun envoi de fichier
L’exemple est un texte UTF-8 lu en Windows-1252. Remplacez-le par votre propre texte illisible.
1 candidats. Le plus probable : enregistré en UTF-8, lu en Windows-1252 (Latin-1)
Le plus probable
Café crème brûlée — naïve résumé
enregistré en UTF-8, lu en Windows-1252 (Latin-1)
Chaque paire parmi UTF-8, CP949 (EUC-KR), Shift_JIS et Windows-1252 (12 paires) est inversée, et un texte abîmé deux fois est inversé une fois de plus. Les candidats sont mieux classés avec davantage de lettres courantes (latines, kana, les 2 350 syllabes hangeul courantes de KS X 1001) et moins de �, de codes de contrôle et de symboles Latin-1 isolés. Les tables suivent le WHATWG Encoding Standard ; votre texte reste dans votre navigateur.
Présentation
Le réparateur de mojibake redonne à un texte illisible ce qu’il voulait dire. Il vous aide quand l’objet d’un e-mail affiche « é » au lieu de « é », qu’un export de base de données est truffé de « ’ » à la place des apostrophes, ou qu’un texte coréen ou japonais s’est transformé en suite de symboles étranges. Inutile de savoir quels encodages ont été confondus : toutes les paires probables sont essayées et les résultats les plus naturels apparaissent en premier.
Mode d’emploi
- Collez le texte illisible. Un exemple est déjà rempli pour commencer.
- Regardez d’abord le candidat « Le plus probable ».
- Chaque candidat indique comment le texte a été abîmé, par exemple « enregistré en UTF-8, lu en Windows-1252 ». Si le problème revient, modifiez ce réglage dans le programme qui a mal lu le texte.
- Copiez le candidat voulu.
- Si rien de mieux n’apparaît, ou si le texte est rempli de �, ouvrez le fichier d’origine avec le convertisseur d’encodage.
Fonctionnement
- Encodages testés : UTF-8, CP949 (EUC-KR), Shift_JIS et Windows-1252 (Latin-1), soit les 12 paires possibles. Chaque inversion encode le texte abîmé avec l’encodage dans lequel il a été lu à tort, puis décode les octets avec l’encodage dans lequel ils étaient réellement.
- Les candidats qui n’ont rien perdu à la première étape sont inversés une fois de plus pour détecter un double encodage.
- Le classement favorise les lettres latines et les chiffres, les kana japonais et les 2 350 syllabes hangeul courantes, et pénalise les �, les codes de contrôle, les symboles Latin-1 isolés et le hangeul collé devant des lettres latines. Un candidat qui crée de nouveaux trous en � est fortement rétrogradé.
- Quand 20 % ou plus de la saisie est constituée de �, la note « impossible à récupérer à partir du texte » et un lien vers le convertisseur d’encodage passent en premier, et seuls les candidats dont les lettres restantes se lisent clairement (hangeul courant ou kana) sont conservés, si bien qu’un bruit aléatoire n’est jamais proposé comme réparation.
- Les tables d’encodage suivent le WHATWG Encoding Standard.
Exemples
| Texte abîmé | Cause | Texte réparé |
|---|---|---|
| Café crème | UTF-8 lu en Windows-1252 | Café crème |
| l’été | UTF-8 lu en Windows-1252 | l’été |
| 한글 | UTF-8 lu en Windows-1252 | 한글 |
| À̸§ | CP949 lu en Windows-1252 | 이름 |
| 譌･譛ｬ隱槭� | UTF-8 japonais lu en Shift_JIS | 日本語… (en partie) |
| �ȳ��ϼ��� | CP949 lu en UTF-8 | irrécupérable (note et lien vers le convertisseur affichés) |
Questions fréquentes
Qu’est-ce que le mojibake ?
Un texte est stocké sous forme d’octets. S’il est enregistré dans un encodage puis lu dans un autre, les mêmes octets s’affichent sous forme de mauvais caractères. Le mot « café » en UTF-8 lu en Windows-1252 devient « café », l’apostrophe ’ devient « ’ », et le coréen « 한글 » devient « 한글 ».
Dans quels cas la réparation est-elle impossible ?
Si le texte est rempli de � (le caractère de remplacement), les octets d’origine ont été jetés lors de la mauvaise lecture et ne peuvent pas être reconstruits à partir du texte. Le cas typique est un fichier coréen en EUC-KR ouvert en UTF-8. Ouvrez plutôt le fichier d’origine avec le convertisseur d’encodage.
Quels encodages sont pris en charge ?
UTF-8, CP949 (EUC-KR), Shift_JIS et Windows-1252 (Latin-1). Cela couvre les accents français abîmés (é, è, à, ç, ô devenus é, è, à , ç, ô) et les guillemets ou apostrophes typographiques transformés en â€. Les autres pages de codes, comme Windows-1251, GBK ou Big5, ne sont pas testées.
À quel candidat me fier ?
Le premier est la lecture la plus naturelle, mais un texte très court peut être ambigu. Choisissez celui qui forme de vraies phrases et regardez l’explication de la façon dont il a été abîmé.
L’outil gère-t-il un texte abîmé deux fois ?
Oui. Un texte mal lu, enregistré puis mal lu à nouveau (é qui devient Â…) est inversé en deux étapes. Au-delà de 5 000 caractères, une seule étape est tentée pour rester rapide.
Pourquoi de très courtes chaînes japonaises restent-elles parfois non réparées ?
Les candidats sont classés selon leur naturel, et une très courte chaîne abîmée peut elle-même paraître plausible parce qu’elle mélange kanji et kana. « ありがとう » abîmé via Shift_JIS (« 縺ゅｊ縺後→縺� ») peut n’obtenir aucun candidat ou un ordre différent. Un texte plus long est classé de façon bien plus fiable ; collez donc aussi les phrases qui l’entourent.
Mon texte est-il enregistré ?
Non. Tout se fait dans votre navigateur.
