Encoding Converter & Mojibake Fixer

Quick answers

What is 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

What this tool does

Worked examples

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(partial only)

How to use this tool

1. 1

   Paste the garbled text

   Drop it straight in — no need to identify the encoding first. A short fragment is enough; a dozen characters usually pins the chain down.

2. 2

   Read the top candidate and its badge

   Exact means the chain round-trips back to your input exactly. Partial means it does not, so treat the result as a lead.

3. 3

   Check the encoding chain

   Each candidate shows which encoding the text was really written in and which one misread it. That tells you what to fix upstream, not just what the text said.

4. 4

   Inspect the bytes if you need to

   The second section shows any text as bytes in every common encoding, and decodes raw hex the other way. Use it to size columns or check protocol frames.

Mistakes that make it worse

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

# Confirm the current encoding first
file -I correct.txt   # charset=utf-8 → nothing to convert

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

-- Go via a binary type so the bytes are preserved, not reinterpreted
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Take the first candidate whatever the badge says
db.update(row.id, candidates[0].text);

// Only write back what round-trips
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

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

# Decode once at the boundary, with the encoding the file actually uses
with open(path, encoding='gbk') as f:
    text = f.read()

When you need this

A database migration produced garbage

Legacy MySQL tables declared latin1 while actually holding UTF-8 bytes are the single most common source. Paste a garbled row here to confirm the real chain before you write the ALTER TABLE — running the conversion in the wrong direction turns a recoverable problem into a permanent one.

A CSV opened in Excel shows nonsense

Excel on Windows still assumes the system code page for CSV files without a BOM, so UTF-8 exports come out as mojibake. Confirm the chain here, then re-export with a BOM or import through the text wizard with the encoding set explicitly.

Log files from a legacy service

Applications built against GBK or Shift_JIS write logs in those encodings, and modern log aggregators read everything as UTF-8. Paste a line to recover it — and because nothing is uploaded, you can do this with production logs.

Filenames broken by a ZIP archive

The ZIP format has no encoding field, so archives created on Chinese or Japanese Windows carry filenames in GBK or Shift_JIS that Unix tools read as UTF-8. Recover the real names here before you rename anything.

Sizing a database column

The byte view shows the same text across every encoding at once. A Chinese character is 3 bytes in UTF-8 but 2 in GBK, which is exactly the sort of difference that turns a VARCHAR(50) into a truncation bug.

How mojibake happens

Bytes survive, meaning does not

Encoding maps characters to bytes; decoding maps bytes back. Mojibake is a decode with the wrong map. The bytes were never damaged, which is why running the wrong decode backwards recovers the original exactly — provided the wrong decode did not discard anything.

Why CJK text suffers most

ASCII occupies 0x00–0x7F and every common encoding agrees on it, so English text passes through unharmed. Chinese, Japanese and Korean need multi-byte sequences, and the encodings disagree about how to group them. UTF-8 uses three bytes per Chinese character; GBK uses two. Feed UTF-8 bytes to a GBK decoder and the grouping shifts, producing a different number of different characters.

The round-trip test

For each candidate chain the tool re-encodes the recovered text with the first encoding and re-decodes with the second. If that reproduces the input exactly, the chain explains every character and the candidate is marked Exact. Candidates that fail this test are still shown, because a partial recovery often identifies the text even when it cannot reproduce it.

Where the encoding tables come from

The browser's TextDecoder supplies the tables. Encoding in the other direction is trickier, because TextEncoder only supports UTF-8 — so the tool builds a reverse map by walking the byte space and asking the decoder what each sequence means. The mapping is therefore always consistent with the browser's own behaviour, and no lookup tables are shipped to your device.

The ranking heuristic, and its limits

Beyond the round-trip test, candidates are scored by how much of the text is common Chinese characters (those whose GBK lead byte falls in 0xB0–0xF7), minus penalties for replacement characters, half-width katakana and control characters. Half-width katakana is a strong Shift_JIS signal because normal Japanese text hardly ever uses it. This is a heuristic; it breaks ties, it does not establish truth.

Stopping it from happening again

Fix the source, not just the string

The encoding chain shown under each candidate tells you which component is misconfigured. Repairing the text without fixing the connection charset, file reader or export setting means doing it again tomorrow with fresh data.

Confirm the direction before converting a whole file

Run a representative line through this page first. Converting in the wrong direction can produce replacement characters, and unlike the original mistake, that step is not reversible.

Set the encoding explicitly everywhere

Database connection charset, HTTP Content-Type, file open calls, CSV exports. Every place that defaults to "the system encoding" is a place where the same bug returns when the code moves to a different machine.

Prefer utf8mb4 over utf8 in MySQL

MySQL's utf8 stores at most three bytes per character, so emoji and some rarer Chinese characters are silently truncated. utf8mb4 is real UTF-8. This is a different failure from mojibake and the recovery tool cannot help with it, because the bytes are genuinely gone.

Keep the original bytes until the fix is verified

Take a copy before converting anything. As long as the original bytes exist, every wrong decode is reversible — once they are overwritten with replacement characters, no tool on this page or anywhere else can bring them back.

Frequently asked questions