Correttore mojibake

Confronto delle ipotesi di codifica
Il testo incollato e tutti i risultati rimangono in questo browser. La modalità a passaggi conserva un record convalidato in questa scheda per un massimo di 30 minuti e inserisce nell’URL soltanto un ID opaco dell’operazione. Non viene inviato nulla tramite i nostri server o un’API di riparazione.

Incolla il testo che appare danneggiato

Incolla un testo come café o una stringa giapponese diventata illeggibile dopo un’incompatibilità di codifica. L’originale resta invariato nell’editor.

Massimo 50.000 caratteri. Questo strumento confronta solo testo Unicode incollato; non ispeziona né ripara file, flussi di byte, database o intestazioni HTTP.

Il mojibake è un contenuto leggibile visualizzato con caratteri sbagliati perché i byte sono stati decodificati con un set di caratteri incompatibile. Un esempio comune è café: café è stato codificato in UTF-8, ma i suoi byte sono stati interpretati come Latin-1 o Windows-1252. Incolla il testo visibile per confrontare ipotesi di riparazione rigorosamente reversibili. Lo strumento mantiene invariato l’originale, presenta ogni risultato come ipotesi ed esegue il confronto localmente nel browser.

Come confrontare un’ipotesi di riparazione del mojibake

  1. 1

    Incolla il testo visibile

    Usa il testo esattamente come lo hai ricevuto. Lo strumento non carica né esamina un file sorgente.

  2. 2

    Accetta il confronto

    Chiedi al browser di verificare le interpretazioni dei byte Latin-1 e Windows-1252 con un decodificatore UTF-8 rigoroso.

  3. 3

    Confronta senza presumere

    Leggi l’originale invariato accanto a ogni risultato reversibile e scegli solo se il contesto lo conferma.

  4. 4

    Copia il testo semplice

    Copia, scarica o stampa un’ipotesi selezionata senza sovrascrivere l’originale.

Cosa può stabilire una riparazione del mojibake e cosa non può stabilire

Una codifica associa i caratteri ai byte e permette di tornare ai caratteri. UTF-8 rappresenta é con i due byte C3 A9. Se un programma decodifica quei byte come Windows-1252 o ISO-8859-1, il risultato visibile può diventare é. Un’ipotesi di riparazione utile inverte proprio quell’errore: tratta i vecchi caratteri visibili come valori di byte, decodifica rigorosamente quei byte come UTF-8 e verifica che codificando di nuovo il risultato in UTF-8 si ottengano esattamente gli stessi byte.

Questo controllo di andata e ritorno scarta le sequenze UTF-8 incomplete o non valide. Scarta inoltre qualsiasi risultato con il carattere sostitutivo , perché le informazioni che esso rappresenta sono già andate perse. Un round trip valido è un indizio a favore di un’ipotesi, ma non dimostra quale codifica usasse il sistema sorgente né quali caratteri intendesse l’autore.

Testo visibile Ipotesi verificata Risultato possibile Cosa controllare
café Byte UTF-8 letti come Latin-1 café Confrontare l’ortografia con la fonte
It’s Byte UTF-8 letti come Windows-1252 It’s Verificare la punteggiatura e lo stile editoriale
文字化け Byte UTF-8 letti come Latin-1 文字化け Confrontare il giapponese con una copia affidabile
café Due errori di codifica consecutivi café Esaminare entrambi i passaggi controllati

Perché il testo giapponese richiede il contesto

Il termine giapponese 文字化け indica caratteri visualizzati in modo illeggibile. Un testo giapponese in UTF-8 può trasformarsi in una lunga sequenza di lettere latine, simboli e caratteri simili a controlli quando i suoi byte vengono decodificati attraverso una vecchia mappatura sbagliata. La reversibilità aiuta, ma un nome breve o un carattere isolato può comunque essere ambiguo. Confronta il risultato con il documento originale, un’esportazione del database, il mittente o un’altra copia autorevole.

Limiti e recupero più sicuro

Questo strumento riceve testo Unicode che il browser ha già decodificato. Non può recuperare byte scartati in precedenza, dedurre la codifica di un file binario, correggere una colonna del database o cambiare un’intestazione HTTP Content-Type. Se non appare alcun risultato, conserva l’originale. Se possibile, recupera i veri byte sorgente, crea un backup, identifica la codifica dichiarata e quella effettiva, quindi decodifica una sola volta con uno strumento progettato per file o flussi di byte. Non salvare ripetutamente il testo danneggiato sopra l’unica copia sorgente.

Domande frequenti

No. Significa che una specifica interpretazione di vecchi byte è stata decodificata come UTF-8 valido e ha superato un controllo esatto di andata e ritorno. Più interpretazioni possono produrre lo stesso testo leggibile o testi diversi. Restano necessari il contesto e una fonte autorevole.

I caratteri visibili potrebbero non rappresentare byte UTF-8 letti come ISO-8859-1 o Windows-1252, la sequenza potrebbe essere incompleta oppure un carattere sostitutivo potrebbe avere già eliminato informazioni. Conserva l’originale ed esamina i byte effettivi e i metadati della codifica.

No. Confronta solo testo Unicode incollato. Non legge file, non ne rileva la codifica, non si connette a database, non riscrive valori memorizzati e non ripara le intestazioni del server. Esegui un backup della fonte prima di usare un processo di conversione che operi sui byte.

No. Il confronto, la selezione, la copia, la creazione del TXT e la preparazione della stampa avvengono nel browser. La modalità a passaggi può conservare un record convalidato in questa scheda per un massimo di 30 minuti e inserisce nell’URL soltanto un ID opaco dell’operazione.

Strumenti correlati