Mojibake repair

Two directions. One: you have the original file (.txt / .csv / .log / .sql and the like) that opens as garbage - pick the original encoding, or let the page guess (it reads the BOM first, then judges UTF-8 versus the GBK family from the byte structure), and the page decodes the byte stream into proper text in your browser. Two: pasted text looks like 好活 - usually UTF-8 or GBK bytes read as Latin-1; the page re-encodes back and decodes again, one click to restore. Without the original file, only the second kind can be repaired.

The browser's built-in encoders only write UTF-8 - there is no native GBK / Big5 encoding support, and this page does not ship a giant encoding table either. So the output is always corrected UTF-8 text (downloadable as .txt / .csv, with an optional BOM so Excel does not garble it again); if the receiving system insists on a GBK file, re-save it as GBK in a local editor.

It checks the UTF-8 / UTF-16 BOM first; with no BOM it validates every byte against strict UTF-8 sequences, and anything failing goes down the GBK / GB18030 path (most GBK files land there). The guess is heuristic, so edge-case files can be misjudged - if the result is still garbage, switch the encoding by hand. The page states which encoding was used and how many replacement characters appeared, so you can see at a glance whether the decode worked.

No. Reading, decoding, previewing and downloading all happen in your browser, no network requests are made, and reloading clears everything.