文本编码转换
拖入文件自动嗅探编码并解码，反向把文本编码成 GBK 等遗留编码；本地处理，坏编码如实报告。
打开一个老文件满屏「鏂囦欢缂栫爜」，或者要把数据喂给只认 GBK 的老系统——编码问题始终是中文化的第一坑。它的本质是同一串字节按不同规则解读：UTF-8 的「文件」三个字（9 字节）被按 GBK 两两分组，就成了「鏂囦欢」。修复的方向只有两个：把字节按正确编码解码，或把文本按目标编码重新编码。
本工具两个方向都做。解码方向拖入文件即可：自动嗅探候选编码并按「能否无损解码 + CJK 字符占比」排序，点一下即切换预览，出现替换字符会明确提示「这个文件不是该编码」。编码方向是浏览器没有原生能力的部分（TextEncoder 只出 UTF-8）：本工具把目标编码的全部合法字节序列反查成字符表来编码，支持 GBK/Big5/Shift_JIS/EUC-KR 等，表达不了的字符如实列出，导出十六进制、百分号编码或字节文件。
嗅探是「猜」，候选要自己确认
编码没有百分之百的检测——同样的字节序列在 GBK 和 Big5 下都常常合法。本工具的排序依据是两条硬标准：严格模式解码不出现替换字符（无损），以及 CJK 字符占比得分。√ 标记的候选都验证过无损，但「无损」不等于「正确」——日文文档可能恰好被 GBK 无损解码成一堆汉字乱码，最终以人眼确认为准。
编码方向的反查表原理
浏览器只提供了「字节 → 文本」的内建解码，反向没有 API。这里的做法是把目标编码的全部合法字节序列（双字节编码 256×256 个组合）逐个解码一次，解出真实字符的登记进反向表——首次构建几十毫秒，之后常驻内存。这个办法零数据文件，且与浏览器的解码器天然一致：用它编码的字节用它解码必然还原。
常见问题
- 为什么「鏂囦欢」这种乱码能修复？
- 这是 UTF-8 文本被按 GBK 显示的典型症状。修复路径：把原始文件拖进本工具（不要复制粘贴屏幕上的乱码字），选 GB18030/GBK 解码会得到乱码本身对应的字符——不对；正确操作是选 UTF-8 解码得到原文。关键在于修复永远作用于「原始字节」，从屏幕上复制乱码字符已经丢失了原始字节。
- gb18030 和 GBK 是什么关系？
- GB2312 ⊂ GBK ⊂ GB18030。GBK 用双字节覆盖了两万多个汉字；GB18030 是国家强制标准，在双字节之外还有四字节区，覆盖全部 Unicode。浏览器的 TextDecoder 按 GBK 标签解码时实际使用 GB18030 解码器（超集，向后兼容），日常使用可视为等价。
- 支持哪些编码？文件会上传吗？
- 解码支持 UTF-8、UTF-16、GB18030/GBK、Big5、Shift_JIS、EUC-KR、Windows-1252/1251、KOI8-R；编码方向同样覆盖（UTF-16 与双字节 CJK 均可）。全部处理在浏览器本地完成，文件不离开设备。