The short answer
Garbled text comes in two families. <strong>First, a charset mismatch</strong>: the content is perfectly good Chinese, it is just being read with the wrong character set — you see blocks, question marks, or Latin-looking variants such as <code>ä¸æ–‡</code>. Browser tools cannot help here; you need a system tool to re-read the file in the right encoding. <strong>Second, content that was encoded</strong>: the original was fine but got wrapped in Base64, URL encoding, Unicode escapes or hex — <code>%E4%B8%AD</code>, <code>aHR0cHM6Ly</code>, <code>\u4e2d</code>, <code>E4B8AD</code> are the fingerprints, and a browser tool undoes the wrapper in one step. The fastest test: <strong>look for a percent sign or a backslash escape</strong>. Present means the second family, absent means the first. There is also a boundary case — GBK and UTF-8 misread as each other, where GBK bytes read as UTF-8 give <code>ä¸æ–‡</code> and UTF-8 bytes read as GBK give <code>涓枃</code>. That is pure transcoding, beyond what a web page should pretend to do; section five covers it.
Read the fingerprints
Match the symptom to the cause. A string starting <strong><code>%E4%B8%AD</code></strong> is URL encoding: the UTF-8 bytes of Chinese written as %XX, common in link parameters and form posts — decode it and you are done. <strong><code>aHR0cHM6Ly9</code></strong>-style text is Base64, often padded with <code>=</code> or <code>==</code>, and usually decodes to a URL or a JSON blob. <strong><code>\u4e2d\u6587</code></strong> is Unicode escaping, seen in JSON written that way to sidestep quote escaping. <strong><code>E4B8AD E69687</code></strong>-style pairs are hex bytes. <strong><code>eyJ...</code></strong> split into three dot-separated segments is a JWT. <strong><code>ä¸æ–‡</code> or <code>×ÖÖ¿Ö</code></strong> is GBK/UTF-8 confusion, which belongs to the first family. <strong><code>???</code> or empty boxes</strong> usually means the target environment had no Chinese font or forced an ASCII-only conversion — the first family in a worse form. The first five are handled in one shot: paste the whole string in and the tool tries each common encoding side by side, so you read them all at once instead of guessing.
What browser tools can and cannot do
Drawing the line explicitly saves wasted effort. A web tool can <strong>identify</strong> which encoding a suspect string uses and show every candidate decode at once so you can pick; and it can <strong>convert</strong> between Base64, URL encoding, Unicode escapes, HTML entities and hex. That makes it genuinely useful for API responses, escaped Chinese inside URLs, and Base64 fragments in logs — cases where the content is not broken, it is just wearing a wrapper. A web tool <strong>cannot</strong> transcode between GBK and UTF-8: that means reinterpreting bytes under a different character set, a real conversion operation these tools do not implement and should not pretend to. So if what you are looking at is <code>ä¸æ–‡</code>, stop trying tools and read the next section.
Charset mismatch: re-read in the right character set
The fix is always the same idea: tell the system exactly what the encoding is instead of letting it guess. On Windows the direct path is to open the file in Notepad and, if the text is garbled, walk through the "Save as" encoding dropdown — ANSI, UTF-8, GB2312, GBK — and keep the one that renders correctly (ANSI on a Chinese Windows install is the GBK family). With many files, use VS Code or Notepad++ instead: the encoding indicator in the status bar switches the current file instantly, which beats repeated save-as round trips. In scripts, pass the encoding explicitly when reading text files. In a database, check the connection character set — for MySQL set the connection to <code>utf8mb4</code>, and where a single value must be converted, wrap it (for example <code>CONVERT(x USING utf8mb4)</code>). One habit closes most of these: <strong>verify with a snippet of text you already know is correct</strong> before touching the real file, so you confirm "this encoding reads correctly" instead of guessing three times in the wrong direction.
GBK and UTF-8 misread as each other
Data created on Chinese Windows is largely GBK, and systems later moved to UTF-8, so the same file goes wrong in both directions. One way: <strong>GBK bytes read as UTF-8</strong>, and Chinese turns into <code>ä¸æ–‡</code>-style accented Latin, because GBK's high lead bytes happen to fall in the range UTF-8 treats as multi-byte starters. The other way: <strong>UTF-8 bytes read as GBK</strong>, and Chinese turns into things that look like real characters — <code>涓枃</code>, <code>鏂囨湰</code> — each three-byte sequence split into one hanzi plus a leftover. Neither is encryption; both are transcoding errors. The fix is to declare the target encoding: switch the editor as above, or line the two ends of a database export up with the same character set (exporting as UTF-8 first, then importing, causes fewer repeated failures than exporting GBK directly). One exception worth knowing: if <code>涓枃</code>-style output is the result of <em>two</em> bad conversions (UTF-8 to GBK to UTF-8), the original text is recoverable, but only by a dedicated mojibake-repair tool that reverses the specific transformation — the browser encoders here cannot do that step.
A triage order worth memorising
Follow this and you skip most of the trial and error. <strong>Step one, look for encoding marks</strong>: a percent sign, a <code>\u</code> escape, dots splitting three segments, or tidy hex pairs means "this was encoded" — paste it into the detection tool and read all candidate results side by side, then pick the readable one. <strong>Step two, no marks but Chinese is deformed</strong>: it is a charset problem, so switch the editor between UTF-8 and GBK and keep whichever renders correctly. <strong>Step three, readable but the wrong way round</strong>: the charset is settled and you now genuinely need a conversion (the file really is GBK while the target system only accepts UTF-8, say) — use the editor's "save with encoding UTF-8" rather than specifying an encoding on every read, so the fix lands in the file once. Last habit: <strong>always state the encoding explicitly</strong> — in scripts, in imports and exports, and when pasting between editors. "Let the program guess" is the main source of these problems in the first place.
想马上动手：先拿可疑字符串试 编码自动识别 看它属于哪一类，需要手工转换用 编码转换，处理接口报错时对照 JSON 报错怎么查，正则相关的转义问题看 正则表达式入门。Try it now: paste the suspect string into encoding detection to see which family it belongs to, use encoding conversion to transform it by hand, and pair it with the JSON error guide when the problem shows up in an API response.
FAQ
Chinese turned into ??? or a row of question marks — can it be recovered?
Two cases. If the question marks were produced during <strong>transfer or storage</strong>, the target environment converted as plain ASCII, and the character information was destroyed at the moment of replacement — that is irreversible, and you must re-export from the source. If the question marks are only a <strong>display</strong> artefact (the file is intact, but the opening program uses a mismatched encoding or lacks the font), nothing is wrong with the file: open it in an editor that supports Chinese using the correct encoding, and do not modify the file at all.
A URL shows Chinese as %E4%B8%AD — can I still open it?
Yes, and it is the normal form: URLs are restricted to ASCII, so Chinese has to travel as %XX. Seeing the characters render properly in the address bar means decoding already happened. The problems start when you take that escaped string and use it as a filename, a database value, or an API parameter and forget to decode at the right moment — then what gets stored is the escape sequence rather than the text.
The same file is garbled on a colleague's machine but fine on mine. How do I track it down?
It is almost always a difference in <strong>default encoding or editor settings</strong> between the two machines, not a broken file. Check three things: the editor's default file encoding (VS Code has a files.encoding option, nowadays usually UTF-8), the Windows regional setting for "Use Unicode UTF-8 for worldwide language support", and the default encoding your command-line tools use when reading text. Settle on UTF-8 everywhere and actually transcode the file once on disk — which is exactly why the earlier advice favours saving the conversion rather than specifying an encoding on every read.