ToolConvoyToolConvoyv2.6
CODE

字符编码修复器 — 在线免费修复乱码（mojibake）

修复乱码（mojibake）。自动检测原始编码并转换为 UTF-8。支持 Shift_JIS、GBK、EUC-JP 以及 Latin-1 误读等情况。100% 本地处理，零上传。

● 本地运行 · 在内存中编码页面加载以来工具发出的网络请求：0 次

您可能还需要

排序行MD5 哈希UUID 生成器JSON 转 CSVBase64 编码PDF 拆分HAR 转 cURLTOML 工具.env 助手MsgPack 检查器PDF 压缩PDF 转 EPUB
打开字符编码修复器

Mojibake — 由错误的字符编码引起的乱码 — 是软件中最令人头疼且最顽固的 bug 之一。日本银行导出的 CSV 在 Excel 中打开，看起来像一串随机的带音标欧洲字符；中文 Windows 机器上保存的 README 在 Linux 上变成问号和方框；遗留系统的数据库转储在所有现代编辑器里都产生不可读的文本。根本原因始终相同：一段字节以一种编码（通常是 UTF-8）写入，却以另一种编码（通常是系统的旧代码页）读取。字符编码修复器从乱码文本的字节模式里推断最可能的原始编码，并在输出端重建出正确的 UTF-8。

工具按两种模式工作。自动检测会扫描输入中五种常见编码的字节模式 — UTF-8、Shift_JIS、EUC-JP、GBK 和 ISO-8859-1 — 并应用置信度最高的那个修复。手动配对模式把控制权交给你：选择与你的 mojibake 场景对应的具体编码对。第一个选项「UTF-8 被当作 Latin-1 解码」修复最常见的那一种情况 — UTF-8 文本在西方欧洲应用里被打开，多字节 UTF-8 序列中的每个字节变成了单独的带音标 Latin 字符。这一种配对就涵盖了网上绝大多数 mojibake 报告。

隐私模型很简单：TextEncoder 和 TextDecoder API 在你的浏览器里跑。乱码文本从 textarea 读入，用源编码重新编码为字节，再用目标编码解码为 UTF-8。整个过程不会向任何服务器发送任何数据。这一点尤其重要，因为乱码文本常常来自敏感来源 — 银行对账单、病历、法律文书 — 把它发给一个服务器端转换器等于把这些内容暴露给第三方。本地浏览器方案从构造上就保证了隐私。

广告

使用方法

  1. 粘贴乱码文本

    粘贴显示成错误字符的文本 — 也就是把带音标的 Latin 字母出现却本应是中文、日文或韩文的位置。这种现象叫 mojibake — 文本以一种编码写入，却被当作另一种解码并显示出来。

  2. 选择修复模式

    自动检测会扫描输入中常见编码（UTF-8、Shift_JIS、EUC-JP、GBK、ISO-8859-1）的特征字节模式，并应用最常见的修复。手动配对让你选择指定的编码对 — 例如「UTF-8 被当作 Latin-1」用于修正 UTF-8 字节被解读为 Windows-1252 的情况。

  3. 复制修复后的文本

    如果自动检测成功，输出应当显示正确的字符。如果不对，就把每个手动配对选项挨个试一遍。最常见的 mojibake 场景 — UTF-8 文本被当作 Latin-1 打开 — 就是第一个配对，它能修复绝大多数乱码文本。

常见问题

什么是 mojibake？

Mojibake（斾化け，字面意思是「character transformation」）是把一种编码的字节当作另一种编码解读时产生的乱码。最经典的例子：以 UTF-8 保存的日文文本会产生多字节序列，当这些字节被解读为 Latin-1（一个字节对应一个字符）时，多字节序列里的每个字节都变成单独的带音标字符 — 把「日本語」（日语）变成「æ◥本語」。

它能检测哪些编码？

自动检测会检查 UTF-8、Shift_JIS（日语）、EUC-JP（日语 Unix）、GBK（简体中文）和 ISO-8859-1（西欧）的字节模式。手动配对模式覆盖常见的误读场景：UTF-8 被当作 Latin-1、Shift_JIS 被当作 Latin-1、GBK 被当作 Latin-1、EUC-JP 被当作 Latin-1，以及 Latin-1 与 UTF-8 的来回转换。

为什么会产生这种现象？

最常见的场景是：日本或中国应用程序生成的 CSV 文件以 UTF-8 保存，但接收方在 Excel 中打开，而 Excel 默认使用系统的旧编码（英文系统上是 Windows-1252，日文系统上是 Shift_JIS）。Excel 把每个 UTF-8 字节当成错误编码里的单个字符来处理，于是产生乱码。修复的做法就是反向执行这个误读过程，把原文重建出来。

它能修复所有乱码吗？

只有原始字节完整保留时才行。有些编码转换会丢失信息 — 目标编码字符集之外的字符会被替换成 `?` 或直接丢弃。本工具只能恢复「原始编码的每一个字节都保留下来」的那部分文本。数据丢失是永久性的，没有任何工具能恢复。

对混合语言文本也有效吗？

自动检测基于统计启发式，对单一语言文本效果最好。混合语言文本（例如英语注释里夹杂中文）可能让检测器出错。这种情况下请试手动配对选项 — 非英语部分对应的正确编码通常能把整段文本都修好。

限制说明

  • 无法从编码丢失中恢复如果字符在之前的编码转换中被替换成 `?` 或被丢弃，那份信息就永久丢失了。本工具只能反向修复编码误读，无法恢复因截断或替换而丢失的内容。
  • 启发式检测自动检测基于字节模式启发式，可能出错，尤其是短文本（少于 50 个字符）或语言成分混杂的情况。手动配对选项提供了确定性的兜底。
  • 不支持 EBCDIC 或冷门编码本工具覆盖最常见的 Web 和桌面编码。主机端的 EBCDIC、ISO-2022-JP 这类冷门 CJK 变体，以及阿拉伯文、印地文等文字的编码都不在支持范围内。

平台说明

macOS
macOS 上大多数应用以 UTF-8 为原生编码，但 Terminal.app 和遗留 Carbon 应用可能默认使用 MacRoman。本工具能处理 Latin-1 误读，这也是 macOS 与 Windows 之间最常见的编码不匹配。
Windows
Windows 是 mojibake 的高发地，因为很多应用仍默认使用系统的 ANSI 代码页（西方是 Windows-1252，日本是 Shift_JIS，中国是 GBK，韩国是 EUC-KR）而不是 UTF-8。
Linux
Linux 系统几乎一律默认 UTF-8，但从 Windows 系统或按区域设置默认 EUC-JP、ISO-8859-1 的遗留 Unix 服务器传输过来的文件仍会产生 mojibake。命令行替代是 `iconv`：`iconv -f shift_jis -t utf-8 file.txt`。
Web
完全在浏览器中运行。任何文本内容都不会发送到服务器。检测器和转换器用的是浏览器内置的 TextEncoder/TextDecoder API。
广告
广告