Convertitore di Codifica e Riparazione Mojibake

Risposte rapide

Che cos'è il mojibake?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

Che cosa fa questo strumento

Esempi svolti

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(solo parziale)

Come si usa

1. 1

   Incolla il testo illeggibile

   Buttalo dentro così com'è: non serve identificare prima la codifica. Basta un frammento breve, una dozzina di caratteri di solito inchioda la catena.

2. 2

   Leggi il primo candidato e il suo badge

   Esatto significa che la catena ripercorsa a ritroso riproduce esattamente il tuo input. Parziale significa di no, quindi tratta il risultato come una pista.

3. 3

   Controlla la catena di codifica

   Ogni candidato mostra con quale codifica il testo era davvero scritto e quale l'ha letto male. È questo a dirti che cosa correggere a monte, non solo che cosa diceva il testo.

4. 4

   Ispeziona i byte, se ti serve

   La seconda sezione mostra qualsiasi testo come byte in tutte le codifiche comuni e decodifica esadecimale grezzo nella direzione opposta. Usala per dimensionare colonne o verificare trame di protocollo.

Mosse che peggiorano la situazione

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# Conferma prima la codifica attuale
file -I correct.txt   # charset=utf-8 → niente da convertire

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- Passa da un tipo binario, così i byte vengono preservati e non reinterpretati
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Prendi il primo candidato qualunque cosa dica il badge
db.update(row.id, candidates[0].text);

// Riscrivi solo ciò che supera l'andata e ritorno
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# Decodifica una volta sola al confine, con la codifica che il file usa davvero
with open(path, encoding='gbk') as f:
    text = f.read()

Quando ti serve

Una migrazione di database ha prodotto spazzatura

Le vecchie tabelle MySQL dichiarate latin1 che in realtà contengono byte UTF-8 sono di gran lunga la sorgente più comune. Incolla qui una riga illeggibile per confermare la catena reale prima di scrivere la ALTER TABLE: eseguire la conversione nella direzione sbagliata trasforma un problema recuperabile in uno permanente.

Un CSV aperto in Excel mostra caratteri assurdi

Excel su Windows presume ancora la code page di sistema per i file CSV privi di BOM, quindi le esportazioni UTF-8 escono come mojibake. Conferma qui la catena, poi riesporta con il BOM oppure importa dalla procedura guidata di testo indicando la codifica in modo esplicito.

File di log di un servizio legacy

Le applicazioni sviluppate per GBK o Shift_JIS scrivono i log in quelle codifiche, e gli aggregatori di log moderni leggono tutto come UTF-8. Incolla una riga per recuperarla — e visto che niente viene caricato, puoi farlo con i log di produzione.

Nomi di file rovinati da un archivio ZIP

Il formato ZIP non ha un campo per la codifica, quindi gli archivi creati su Windows cinese o giapponese portano nomi di file in GBK o Shift_JIS che gli strumenti Unix leggono come UTF-8. Recupera qui i nomi reali prima di rinominare qualcosa.

Dimensionare una colonna di database

La vista dei byte mostra lo stesso testo in tutte le codifiche in una volta sola. Un carattere cinese occupa 3 byte in UTF-8 ma 2 in GBK, ed è esattamente il tipo di differenza che trasforma un VARCHAR(50) in un bug di troncamento.

Come nasce il mojibake

I byte sopravvivono, il significato no

La codifica mappa i caratteri in byte, la decodifica riporta i byte a caratteri. Il mojibake è una decodifica fatta con la mappa sbagliata. I byte non sono mai stati danneggiati, ed è per questo che eseguire al contrario la decodifica sbagliata recupera l'originale in modo esatto — a patto che quella decodifica sbagliata non abbia scartato nulla.

Perché il testo CJK ne soffre di più

L'ASCII occupa 0x00–0x7F e ogni codifica comune concorda su quella fascia, quindi il testo inglese passa indenne. Cinese, giapponese e coreano hanno bisogno di sequenze multibyte, e le codifiche non concordano su come raggrupparle. UTF-8 usa tre byte per carattere cinese, GBK ne usa due. Dai byte UTF-8 in pasto a un decoder GBK e il raggruppamento si sposta, producendo un numero diverso di caratteri diversi.

Il test di andata e ritorno

Per ogni catena candidata lo strumento ricodifica il testo recuperato con la prima codifica e lo ridecodifica con la seconda. Se questo riproduce esattamente l'input, la catena spiega ogni singolo carattere e il candidato viene marcato Esatto. I candidati che non superano il test vengono comunque mostrati, perché un recupero parziale spesso identifica il testo anche quando non riesce a riprodurlo.

Da dove arrivano le tabelle di codifica

Le tabelle le fornisce il TextDecoder del browser. Codificare nella direzione opposta è più scomodo, perché TextEncoder supporta solo UTF-8: lo strumento costruisce quindi una mappa inversa percorrendo lo spazio dei byte e chiedendo al decoder che cosa significa ogni sequenza. La corrispondenza resta perciò sempre coerente con il comportamento del browser stesso, e nessuna tabella di lookup viene scaricata sul tuo dispositivo.

L'euristica di ordinamento, e i suoi limiti

Oltre al test di andata e ritorno, i candidati ricevono un punteggio in base a quanta parte del testo è fatta di caratteri cinesi comuni (quelli il cui byte iniziale GBK cade fra 0xB0 e 0xF7), meno le penalità per caratteri di sostituzione, katakana a mezza larghezza e caratteri di controllo. I katakana a mezza larghezza sono un indizio forte di Shift_JIS, perché il testo giapponese normale non li usa quasi mai. Questa è un'euristica: rompe le parità, non stabilisce la verità.

Come evitare che si ripeta

Correggi la sorgente, non solo la stringa

La catena di codifica mostrata sotto ogni candidato ti dice quale componente è configurato male. Riparare il testo senza correggere il charset della connessione, il lettore di file o le opzioni di esportazione significa rifare tutto domani con dati freschi.

Conferma la direzione prima di convertire un intero file

Fai passare prima una riga rappresentativa da questa pagina. Convertire nella direzione sbagliata può produrre caratteri di sostituzione e, a differenza dell'errore originale, quel passaggio non è reversibile.

Imposta la codifica in modo esplicito ovunque

Charset della connessione al database, Content-Type HTTP, chiamate di apertura dei file, esportazioni CSV. Ogni punto che ricade sulla «codifica di sistema» è un punto in cui lo stesso bug ritorna appena il codice si sposta su un'altra macchina.

In MySQL preferisci utf8mb4 a utf8

L'utf8 di MySQL memorizza al massimo tre byte per carattere, quindi le emoji e alcuni caratteri cinesi più rari vengono troncati in silenzio. utf8mb4 è UTF-8 vero. Questo è un guasto diverso dal mojibake e lo strumento di recupero non può farci niente, perché quei byte sono davvero spariti.

Conserva i byte originali finché la correzione non è verificata

Fai una copia prima di convertire qualsiasi cosa. Finché i byte originali esistono, ogni decodifica sbagliata è reversibile; una volta sovrascritti con caratteri di sostituzione, nessuno strumento di questa pagina né di altrove può riportarli indietro.

Domande frequenti