🛠 文字乱码修复
通过组合多种编码自动解码乱码文本，并建议最「日语风格」的结果。批量试验 Shift_JIS、UTF-8、EUC-JP、ISO-2022-JP 的误读。
完全免费
无需注册
浏览器内完成
5 种语言
深色模式
🔒 关于隐私
- ・所有处理均在您的浏览器中完成
- ・输入文本绝不会发送到任何服务器
- ・无存储日志、无历史记录、无数据库
📖 常见的坑
针对乱码文本，穷举各种编码组合，找出能还原为可读形式的那一种。处理全部在浏览器内完成。能否还原，取决于信息是否还在：仅仅是用错误编码读取过，可以逆转；但一旦在这种状态下重新保存，丢失的字节就再也回不来了。
| 情形 | 会发生什么 | 怎么处理 |
|---|---|---|
| 全是「?」或「□」，无法还原 | 这种状态无法还原。「?」是目标编码中不存在的字符被压成替换字符后的残留，原始字节已经消失。把生僻汉字转成 Shift_JIS，或把表情符号降到 latin-1 时就会这样。相反，那种看起来还有迹可循的乱码，说明字节仍在，可以逆转。 | 一旦变成替换字符，唯一的办法就是从源头重新取数据：备份、邮件原件、数据库副本，任何未经过该次转换的路径。要杜绝复发，从入口到出口全程使用 UTF-8 是唯一可靠的答案。MySQL 中请指定 utf8mb4 而非 utf8——后者最多只能处理 3 字节，无法保存表情符号与部分汉字。 |
| 被二次编码了 | 像 ã‚ã‚ŠãŒã¨ã† 这样的形态，是把 UTF-8 字节按 latin-1 读取，再以 UTF-8 保存的结果。特征是一个字膨胀成两三个，每经过一次转换就再膨胀一层。当数据库连接字符集与表字符集不一致时，它会随着每次写入而逐层加深。 |
这种形态下字节仍然完好，因此可以还原——边试边逐层剥离即可。但该修的是配置而非数据：只修数据而不改写入路径，第二天就会恢复原状。请先把连接字符集（SET NAMES utf8mb4）、表与列的字符集、应用侧的内部编码这三者对齐，然后再着手修复数据。 |
| 唯独 CSV 出现乱码 | CSV 没有地方声明自己的编码。HTML 有 <meta charset>，XML 有声明行，而 CSV 从头到尾都是数据。于是接收方软件只能猜，日文版 Excel 在没有 BOM 时会按 Shift_JIS 打开。文件本身没错，乱码出在读取一侧。 |
发给 Excel 的文件请导出为 UTF-8 with BOM，有 BOM 时 Excel 会确定按 UTF-8 打开。但程序读取时 BOM 会碍事——第一个列名会带上不可见字符，导致键匹配失败。为「人用 Excel 打开」与「系统读取」分别产出不同文件，最终争议最少。更多细节整理在 CSV ⇔ JSON 转换。 |
发现乱码时，请先判断它发生在哪个环节。是数据库中存储的值本身已损坏，还是数据库没问题、只是显示时出错——两者的处理方式完全不同。用 SELECT HEX(column) 之类直接查看字节，立刻就能分辨。若只是显示问题，请同时检查 HTTP 响应的 Content-Type: text/html; charset=utf-8 与 HTML 中的 <meta charset="utf-8">——标头优先级更高，只改 meta 标签不会有任何变化。
📖 使用方法
-
1
粘贴乱码文本复制邮件或文件中的乱码文本并粘贴。
-
2
点击自动修复尝试 UTF-8 · Shift_JIS · EUC-JP · ISO-2022-JP · URL 各种组合。
-
3
选择候选得分高的候选排在上方,复制正确的那个。
❓ 常见问题
为什么显示多个候选？
乱码可能来自多种途径,无法机械唯一判定。按日语字符频率打分排序。
输入文本会发送到服务器吗？
不会。从 CDN 加载 encoding.js,在浏览器内处理,不发送文本。
可以直接加载 Shift_JIS 文件吗？
目前仅支持粘贴文本。如需文件编码转换,请使用换行 / 编码工具。
🐛 此工具出现问题了吗？
免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。
✅
感谢您的反馈！
已送达运营者,将用于改进工具。