Correcteur de mojibake

Comparaison des hypothèses de codage
Le texte collé et tous les résultats restent dans ce navigateur. Le mode par étapes conserve un enregistrement validé dans cet onglet pendant 30 minutes au maximum et place uniquement un identifiant de tâche opaque dans l’URL. Rien n’est envoyé par nos serveurs ou par une API de réparation.

Collez le texte qui semble altéré

Collez un texte tel que café ou une chaîne japonaise devenue illisible à la suite d’une incompatibilité de codage. L’original reste inchangé dans l’éditeur.

50 000 caractères au maximum. Cet outil compare uniquement du texte Unicode collé. Il n’examine ni ne répare les fichiers, flux d’octets, bases de données ou en-têtes HTTP.

Le mojibake désigne des données lisibles affichées sous forme de caractères erronés parce que leurs octets ont été décodés avec un jeu de caractères incompatible. Un exemple courant est café : café a été codé en UTF-8, mais ses octets ont été interprétés comme du Latin-1 ou du Windows-1252. Collez le texte visible pour comparer des hypothèses de réparation strictement réversibles. L’outil conserve l’original intact, présente chaque résultat comme une hypothèse et effectue la comparaison localement dans votre navigateur.

Comment comparer une hypothèse de réparation de mojibake

  1. 1

    Collez le texte visible

    Utilisez le texte exactement comme vous l’avez reçu. L’outil ne téléverse ni n’examine aucun fichier source.

  2. 2

    Acceptez la comparaison

    Demandez au navigateur de confronter les interprétations d’octets Latin-1 et Windows-1252 à un décodeur UTF-8 strict.

  3. 3

    Comparez sans présumer

    Lisez l’original intact à côté de chaque résultat réversible et ne choisissez que si le contexte le confirme.

  4. 4

    Copiez le texte brut

    Copiez, téléchargez ou imprimez une hypothèse sélectionnée sans remplacer l’original.

Ce qu’une réparation de mojibake permet d’établir ou non

Un codage associe des caractères à des octets et permet de revenir aux caractères. UTF-8 représente é avec les deux octets C3 A9. Si un logiciel décode ces octets comme du Windows-1252 ou de l’ISO-8859-1, le résultat visible peut devenir é. Une hypothèse de réparation utile inverse précisément cette erreur : elle traite les anciens caractères visibles comme des valeurs d’octets, décode strictement ces octets en UTF-8, puis vérifie que le nouveau codage UTF-8 du résultat reproduit exactement les mêmes octets.

Ce contrôle d’aller-retour élimine les séquences UTF-8 incomplètes ou mal formées. Il élimine aussi tout résultat contenant le caractère de remplacement , car les informations qu’il représente sont déjà perdues. Un aller-retour valide constitue un indice en faveur d’une hypothèse, mais ne prouve ni le codage employé par le système source ni les caractères voulus par l’auteur.

Texte visible Hypothèse testée Résultat possible Élément à vérifier
café Octets UTF-8 lus comme du Latin-1 café Comparer l’orthographe avec la source
It’s Octets UTF-8 lus comme du Windows-1252 It’s Vérifier la ponctuation et le style éditorial
文字化け Octets UTF-8 lus comme du Latin-1 文字化け Comparer le japonais avec une copie fiable
café Deux erreurs de codage successives café Examiner les deux passages contrôlés

Pourquoi le texte japonais exige du contexte

Le terme japonais 文字化け désigne des caractères affichés de manière illisible. Un texte japonais en UTF-8 peut devenir une longue suite de lettres latines, de symboles et de caractères ressemblant à des commandes lorsque ses octets sont décodés selon une ancienne table incorrecte. La réversibilité est utile, mais un nom court ou un caractère isolé peut encore être ambigu. Comparez le résultat avec le document original, une exportation de la base de données, l’expéditeur ou une autre copie faisant autorité.

Limites et méthode de récupération plus sûre

Cet outil reçoit du texte Unicode déjà décodé par le navigateur. Il ne peut pas récupérer des octets supprimés auparavant, déduire le codage d’un fichier binaire, réparer une colonne de base de données ou modifier un en-tête HTTP Content-Type. Si aucun résultat n’apparaît, conservez l’original. Dans la mesure du possible, récupérez les véritables octets sources, créez une sauvegarde, identifiez le codage déclaré et le codage réel, puis effectuez un seul décodage avec un outil conçu pour les fichiers ou les flux d’octets. N’enregistrez jamais de façon répétée le texte altéré sur l’unique copie source.

Questions fréquentes

Non. Cela signifie qu’une interprétation précise d’anciens octets a produit du UTF-8 valide et réussi un contrôle exact d’aller-retour. Plusieurs interprétations peuvent produire le même texte lisible ou des textes différents. Le contexte et une source faisant autorité restent indispensables.

Les caractères visibles ne représentent peut-être pas des octets UTF-8 lus comme de l’ISO-8859-1 ou du Windows-1252, la séquence peut être incomplète ou un caractère de remplacement peut avoir déjà supprimé des informations. Conservez l’original et examinez les véritables octets ainsi que les métadonnées de codage.

Non. Il compare uniquement du texte Unicode collé. Il ne lit pas de fichiers, ne détecte pas leur codage, ne se connecte pas aux bases de données, ne réécrit pas les valeurs stockées et ne répare pas les en-têtes de serveur. Sauvegardez la source avant toute conversion qui travaille sur les octets.

Non. La comparaison, la sélection, la copie, la création du TXT et la préparation de l’impression ont lieu dans votre navigateur. Le mode par étapes peut conserver un enregistrement validé dans cet onglet pendant 30 minutes au maximum et place uniquement un identifiant de tâche opaque dans l’URL.

Outils similaires