我们 / 鎴戜滑 的文字，粘进来直接还原。全程本地处理，不上传。
文件编码转换 做两件事：把文本文件在 UTF-8、GBK、GB18030、Big5、Shift_JIS、UTF-16 之间互转（自动识别原编码、支持批量、可加 BOM 和统一换行符），以及把已经错码的文字反推回原文。全程浏览器本地处理，文件不上传任何服务器。
这是两个完全不同的问题，解法也不同：
| 你的处境 | 用哪个模式 | 结果 |
|---|---|---|
| 源文件还在，只是打开方式不对 | 文件编码转换 | 无损，字符一个不少 |
| 只剩下一段错码的文字，源文件没了 | 乱码文本修复 | 多数能完整还原，部分情况有损 |
只要源文件还在，永远优先走文件转换——那是无损的。乱码修复是拿不到源文件时的补救。
BOM 是文件开头的几个字节，用来声明”我是什么编码”。加不加的判断很简单：给人用 Excel / 记事本打开的，加；给程序读、进 Git 的，不加。 UTF-16 是例外——没有 BOM 就分不出大端小端，所以选 UTF-16 时默认帮你勾上。
UTF-8 能表示全部 Unicode 字符，GBK、Big5 这些传统编码不能。把 UTF-8 转成 GBK 时，emoji、生僻字、部分外文字符会退化成 ?，这是有损的。转换前预览区会把装不下的字符逐个列出来，看到警告就先留一份 UTF-8 原件。需要国标编码又要全字符覆盖，选 GB18030——它是 GBK 的超集，覆盖全部 Unicode。
一段乱码的成因是”A 编码的字节被 B 解码器读了”。还原就是把这个过程倒过来：先按 B 把乱码编回字节，再按 A 重新解一遍。工具会穷举常见的错配组合（最多两层嵌套错码），只保留能严格对上的路径，再按常用字占比排序。对不上就直说对不上——没有任何工具能凭空补回已经丢掉的字节。
存成 UTF-8 带 BOM。Excel 读 CSV 时不看内容猜编码，只认文件开头那三个字节 EF BB BF（BOM）；没有 BOM 它就按系统本地编码（简体中文 Windows 是 GBK）去解，UTF-8 的中文自然全乱。本工具的"Excel 打开 CSV 不乱码"预设就是 UTF-8 + BOM + CRLF 三件套。反过来，给程序读的配置文件、给 Git 管的源码不要加 BOM，很多解析器会把 BOM 当成正文第一个字符。
原生 TextEncoder 确实只能输出 UTF-8，这是 Encoding Standard 的硬性规定。所以这里换了个思路：用 TextDecoder 把目标编码的全部合法字节序列穷举解一遍，反过来建出"字符 → 字节"的码表，首次使用时构建一次（实测 5–30 毫秒），之后编码就是查表。全程零依赖、零上传，GB18030 的 4 字节区和辅助平面也一并覆盖。
按三级判断：先看 BOM（EF BB BF → UTF-8、FF FE → UTF-16LE、FE FF → UTF-16BE），最可信；再做 UTF-8 严格校验，整份文件没有一处非法字节序列就判定 UTF-8；都不中才猜，按 GB18030 / Big5 / Shift_JIS / EUC-KR / Windows-1252 各解一遍打分选最像的。猜的结果会标成"按内容推断"，猜错了在文件行右侧的下拉里手动改，预览立刻重算。文件越短越容易猜错——GBK 和 Big5 在短句上有时字节完全合法但解出来是不同的字。
因为 GBK 里根本没有这个字。GBK 收了两万多个汉字，但装不下 emoji、生僻字、部分少数民族文字和西里尔扩展。转换前预览区上方会明确列出装不下的字符，导出时它们会变成 ?——这是有损的，转之前请留一份 UTF-8 原件。真的需要保留全部字符又要国标编码，改选 GB18030：它是 GBK 的超集，能覆盖全部 Unicode 字符。
两道硬过滤加一次排序。过滤一：把乱码按"当初读错用的编码"编回字节，编不回去（有字符不在那个编码里）说明这条路径不可能是成因，直接否掉。过滤二：换成推断的真实编码重新解，要求严格合法，出现一个非法字节序列就否掉。排序：传统编码的码位天然按常用度分区（GB2312 一级字、Big5 常用字、Shift_JIS 第一水準），据此算"常用字占比"，把那种通篇生僻字、看着像中文其实是乱码的假还原压到后面。对不上就明说对不上，不硬凑一个结果给你。
因为原始字节在保存那一刻就已经没了。解码器遇到不认识的字节序列会吐一个替换符 U+FFFD（显示成 �），这一步是不可逆的：原来那几个字节被丢弃，只留下一个"这里出过错"的记号；「锟斤拷」则是这个替换符又被编码了一轮的产物。这种情况下任何工具都还原不回来，唯一的解法是回到源文件，用"文件编码转换"重新转一次。如果只是零星几处丢失，工具会给一个尽力而为的结果，丢失位用 ? 占位并明确标注。
不上传。读文件用 File API，解码用浏览器原生 TextDecoder，编码用本地生成的反查码表，批量导出用 JSZip 在内存里打包，全过程没有一个网络请求，断网也能用。文件大小取决于可用内存，实测几十 MB 的文本没问题；超过 100MB 建议先切分。