这是最可靠的方式：文件里是原始字节，可以完整还原。
如果乱码里能看到中文（如「涓枃」），说明是被当成 GBK 读错了——这种情况需要 GBK 编码表才能还原，请改用「上传文件」方式。
按「乱码程度」从低到高排序：乱码字符越少越可能是正确编码。标红的是替换字符（U+FFFD），代表「这个字节解不出来」。
对照下表，能快速判断「原本是什么编码、被当成了什么」。
| 你看到的乱码 | 原本是 | 被当成 | 怎么修 |
|---|---|---|---|
| ÖÐÎÄ / ÏÔʾ | GBK | Latin-1 | 选 Latin-1 还原后按 GBK 解 |
| ä¸æ–‡ | UTF-8 | Latin-1 | 选 Latin-1 还原后按 UTF-8 解 |
| 涓枃 / 鏄剧ず | UTF-8 | GBK | 只能用「上传文件」方式 |
| ????? 或 | 任意 | 不兼容编码 | 浏览器已尽力，试试其它候选 |
| 锟斤拷 | UTF-8 | GBK（二次损坏） | 基本无法还原，找回原始文件 |
⚠️ 使用提示：① 「上传文件」永远比「粘贴文字」可靠——粘贴时，乱码字符已经经过一次编码，信息可能已经丢失；② 已被 GBK 误读的中文（如「涓枃」）需要 GBK 编码表才能还原字节，浏览器原生 TextEncoder 只支持 UTF-8，请改用文件上传；③ 「锟斤拷」是二次损坏，几乎不可能还原，请找回原始文件；④ 检测靠的是「解出来像不像正常文本」，短文本可能误判，请人工看预览确认；⑤ 导出只提供 UTF-8（可带 BOM），不支持导出 GBK / Big5——浏览器没有这些编码器；⑥ 全程本地处理，文件不上传。
从老系统导出的 CSV 全是问号？十年前存的 txt 打开是「ÖÐÎÄ」？别人发来的字幕文件一堆方块？
本质只有一个：写的人和读的人用的编码不一样。本工具把这个猜的过程自动化：
① 14 种编码逐个试：UTF-8 / GBK / GB18030 / Big5 / Shift-JIS / EUC-JP / EUC-KR / KOI8-R / Latin-1 / Windows-1252 等；
② 按乱码程度排序：解不出来的字节会变成替换字符 �，越少越可能是正确答案；
③ 候选预览：每条候选直接显示前几行内容，一眼就能认出哪个是对的；
④ 两种输入：上传文件（最准）或粘贴乱码文字（方便）；
⑤ 一键导出：还原成正常中文后，导出 UTF-8 文本文件（可选带 BOM，方便 Windows 记事本正确识别）。
全程在你自己的浏览器里解码，文件不上传。
怎么实现：
① 拿字节：文件用 FileReader.readAsArrayBuffer；粘贴的文字则先按你指定的「错误编码」还原成字节——Latin-1 用 charCodeAt 逐字写回，UTF-8 用 TextEncoder；
② 逐编码解码：new TextDecoder(enc).decode(bytes)，逐个尝试 14 种编码，浏览器不支持的（如某些老旧编码）会抛错并跳过；
③ 打分：统计替换字符 \uFFFD、控制字符与「可疑符号」的数量，坏字符越少排越前；
④ 导出：选定编码后用 TextEncoder（UTF-8）重新编码，可选写入 EF BB BF 三个 BOM 字节。
它不做：不做编码「修复」到 GBK / Big5 的输出（浏览器没有这些编码器），不做「锟斤拷」这类二次损坏的还原，不做二进制文件的识别。
D6 D0），编码表决定这两个字节显示成什么字——GBK 表里是「中」，Latin-1 表里是「ÖÐ」。? 或 � 的字节 → 永久丢失，神仙难救。EF BF BD EF BF BD，也就是两个替换字符——说明系统在第一次出错时就已经「不知道这是什么」，只能填占位符。TextEncoder 只支持 UTF-8（规范如此），没有 GBK / Big5 / Shift-JIS 的编码器。审核通过后就会展示在留言板上，稍安勿躁～
还没有留言，来抢沙发吧！