乱码修复工具

本地处理

打赏支持
分享链接
反馈建议

最常见的乱码是「UTF-8 被当成单字节编码读取」，表现形如 ä¸æ–‡。粘贴乱码文本后点击修复，工具会生成多个候选并按可信度排序。

乱码文本

最佳可信度

候选数量

输入字符数

最佳结果汉字数

修复结果将显示在这里

还原方式	结果预览	可信度

可信度 = (汉字数 × 1.0 + 常用标点数 × 0.6 + 字母数字数 × 0.3) ÷ 结果字符数，再按结果是否含替换字符（U+FFFD）扣分。候选生成方式包括：把每个字符按其 cp1252 或 latin1 字节还原后按 UTF-8 解码、URL 百分号解码、HTML 实体解码、Unicode 转义还原、全角转半角。

乱码的本质是编码错配

字符在计算机里以字节存储，同一条字节流用不同编码解读会得到完全不同的字符。中文环境最常见的事故是：数据本来是 UTF-8 编码，某个环节却按单字节编码（Latin-1 或 Windows-1252）读取，于是三个字节的汉字被拆成三个独立字符，显示成 ä¸ 这类奇怪的组合。

常见乱码形态对照

ä¸æ–‡ 形：UTF-8 被按 cp1252 读，最典型。可以完整还原。
锟斤拷形：GBK 与 UTF-8 反复转换产生的不可逆损伤，原始的「替换字符」已经写死在数据里，通常无法完全恢复。
%E4%B8%AD 形：URL 编码没有被解码。用百分号解码即可还原。
中 形：HTML 实体没有被解析。做实体解码即可。
\u4e2d 形：Unicode 转义序列直接显示。做转义还原即可。

为什么有些乱码修不回来

编码转换是「字节 → 字符」的单向映射，如果原来的字节序列不符合目标编码的合法结构，解码器会用替换字符（显示为问号或黑菱形）占位，原始字节就此丢失。所以看到大量问号的文本基本无法还原；而 ä¸æ–‡ 这类每个字符都完整保留了原始字节值，就能完美还原。这也解释了为什么修复前应该先备份原始文本。

常见问题

为什么给出了多个候选

因为从乱码本身无法百分之百断定当初用的是哪种错配方式。工具会同时尝试几种主流组合，用「还原后文本中有多少汉字与常用标点」来打分排序。可信度只是启发式判断，具体哪个正确还要人眼确认。

数据库里的乱码也能修吗

如果数据库表本身的字符集配错，读出时就已经丢了信息，需要从备份或二进制日志里恢复。判断方法是用客户端工具以原始字节方式（例如十六进制）读取，看字节是否符合 UTF-8 的结构。只要字节还在，就可以修；字节已经变成问号，就修不回来了。

你可能还想问

常见乱码是怎么产生的？

编码与解码方式不匹配：文本以 UTF-8 存储却按 GBK 读取（或反之），就会出现问号、方块或怪字符；常见于跨系统复制、旧软件导出。

能修复到什么程度？

由编码错配产生的乱码多数可还原（尝试常见编码组合）；若字符在转换中已丢失（显示为连续问号），则无法恢复，只能从原文件重新导出。

怎么从根本上避免乱码？

全流程统一使用 UTF-8，文件与接口显式声明编码；复制粘贴跨平台内容时用纯文本中转，避免经过会改变编码的中间软件。