Convertisseur d'encodage et réparateur de mojibake

Collez un texte illisible pour détecter automatiquement la combinaison d'encodages qui en est la cause, avec des candidats de réparation classés. Prend aussi en charge la conversion explicite entre UTF-8, Shift_JIS, EUC-JP et JIS (ISO-2022-JP).

Astuces

  • Lorsque plusieurs candidats apparaissent, celui marqué « Meilleure correspondance » — généralement le japonais ou l'ASCII le plus naturel — est habituellement le bon.
  • Le motif classique « 縺薙繧薙?... » observé dans les e-mails et les fichiers CSV se résout presque toujours avec la paire UTF-8 → Shift_JIS.
  • Si le texte s'est transformé en une suite de « ? » ou de « � », une partie de la séquence d'octets d'origine a probablement été perdue, ce qui complique une récupération complète au niveau du texte.
  • Utilisez l'onglet « Conversion manuelle » pour obtenir un résultat en une seule étape lorsque vous connaissez déjà la paire d'encodages responsable du problème.

Questions fréquentes

Il se produit lorsque l'encodage utilisé pour enregistrer un texte diffère de celui supposé par le lecteur lors de son affichage. Le japonais y est particulièrement exposé car UTF-8, Shift_JIS et EUC-JP sont tous encore utilisés, et les décalages entre eux sont la principale cause du mojibake.

Non. Selon le type de décalage, une partie de la séquence d'octets d'origine peut être définitivement perdue dès le premier décodage (incorrect), rendant impossible une récupération complète à partir de la seule chaîne de caractères. C'est particulièrement vrai lorsqu'un encodage japonais multi-octets est mal interprété comme un autre ; un texte transformé en « ? » ou « � » ne peut généralement pas être restauré.

UTF-8 est aujourd'hui l'encodage dominant, mais certains anciens systèmes japonais et applications Windows héritées supposent encore du Shift_JIS. Comme les séquences d'octets UTF-8 des caractères japonais s'avèrent souvent aussi être des séquences Shift_JIS valides, aucune information n'est perdue dans le processus — c'est précisément pourquoi ce décalage particulier peut généralement être inversé.

Non. Toute la conversion s'exécute localement dans le JavaScript de votre navigateur, ce qui la rend sûre même pour du texte contenant des mots de passe ou des informations personnelles.
ツールくん

Anecdote — Pourquoi « 縺薙繧薙?縺ォ縺。縺ッ » est devenu le visage du mojibake japonais

Cherchez « mojibake japonais » et vous tomberez presque certainement sur « 縺薙繧薙?縺ォ縺。縺ッ » (qui devrait se lire « こんにちは », c'est-à-dire « bonjour ») — c'est devenu une sorte d'icône culturelle parmi les internautes japonais. C'est le résultat typique de l'ouverture d'un texte UTF-8 dans une application qui suppose du Shift_JIS, comme une ancienne version du Bloc-notes Windows ou divers systèmes anciens.

Cette association particulière revient constamment parce qu'un décodeur Shift_JIS réinterprète de force les séquences de 3 octets qu'UTF-8 utilise pour les caractères japonais comme s'il s'agissait de caractères Shift_JIS de 2 octets. Par coïncidence, la plupart de ces séquences réinterprétées tombent dans la plage des caractères Shift_JIS valides, si bien qu'aucune erreur ne se produit : le texte paraît simplement illisible tout en restant, secrètement, entièrement récupérable. C'est exactement cette propriété qui explique pourquoi un réparateur automatique comme celui-ci réussit si souvent.

À l'inverse, ouvrir un texte Shift_JIS comme s'il s'agissait d'EUC-JP produit généralement des séquences d'octets invalides qui sont purement et simplement rejetées, détruisant l'information sur le moment — la récupération au niveau de la chaîne devient alors impossible en principe. Cette distinction entre mojibake « récupérable » et « irrécupérable » explique en grande partie pourquoi les problèmes d'encodage des caractères japonais frustrent silencieusement les ingénieurs depuis des décennies.