编码转换与中文乱码恢复

快速解答

什么是乱码

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

这个工具能做什么

实例解析

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

（只能部分还原）

使用方法

1. 1

   粘贴乱码

   直接粘进来，不用先判断编码。一小段就够，十几个字符通常足以锁定编码链。

2. 2

   看首条结果和它的徽章

   无损＝沿同一条链倒推能逐字复现你的输入；部分＝对不上，只能当线索。

3. 3

   看清编码链

   每条候选都标出原文的真实编码与误读它的编码。这告诉你上游该改哪里，而不只是这段文字原本是什么。

4. 4

   需要时查字节

   第二个区块能把任意文本按各编码列出字节，也能把 hex 反解成文字。核对字段长度、排查报文时用它。

越弄越糟的几种做法

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# 先确认当前编码
file -I correct.txt   # charset=utf-8 → 无需转换

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- 先过一次二进制类型，让字节被保留而不是被重新解释
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// 不管徽章说什么，取第一条
db.update(row.id, candidates[0].text);

// 只写回通过往返校验的结果
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# 在边界处解码一次，用文件真正使用的编码
with open(path, encoding='gbk') as f:
    text = f.read()

什么时候需要它

数据库迁移之后全是乱码

老 MySQL 表声明为 latin1、实际存的却是 UTF-8 字节，这是最常见的单一来源。先把一条乱码记录粘到本页确认真实的编码链，再去写 ALTER TABLE——方向搞反会把一个可恢复的问题变成永久性损坏。

CSV 用 Excel 打开是乱码

Windows 版 Excel 至今对没有 BOM 的 CSV 按系统代码页解读，所以 UTF-8 导出的文件打开就是乱码。在本页确认编码链后，导出时加 BOM，或者用「数据 → 从文本」向导显式指定编码。

老服务写出来的日志

按 GBK 或 Shift_JIS 开发的程序，日志就是那个编码写的，而现代日志采集端一律按 UTF-8 读。粘一行进来即可还原——而且因为内容不上传，可以直接拿生产日志来做。

压缩包里的文件名坏了

ZIP 格式没有编码字段，中文或日文 Windows 上打的包，文件名是 GBK / Shift_JIS，Unix 工具按 UTF-8 读就成了乱码。改名之前先在这里还原出真实文件名。

估算数据库字段长度

字节视图把同一段文本在各编码下的长度并排列出。一个汉字在 UTF-8 里占 3 字节、在 GBK 里占 2 字节——这个差别正是把 VARCHAR(50) 变成截断故障的那类原因。

乱码是怎么产生的

字节留下了，含义没有

编码是把字符映射成字节，解码是把字节映射回字符。乱码就是用错了映射表的一次解码。字节从头到尾没被破坏过，所以把错误的解码倒着走一遍就能精确拿回原文——前提是那次错误的解码没有丢掉任何东西。

为什么中日韩文本受害最深

ASCII 占据 0x00–0x7F，所有常见编码在这一段的约定完全一致，所以英文文本能毫发无损地穿过去。中日韩文字必须用多字节序列，而各编码对「怎么分组」的规定不同：UTF-8 一个汉字 3 字节，GBK 是 2 字节。把 UTF-8 字节喂给 GBK 解码器，分组就错位了，于是得到数量不同、内容也不同的一串字。

往返校验

对每条候选链，工具用第一个编码把还原结果重新编码，再用第二个编码解码。若能逐字复现输入，说明这条链解释了每一个字符，该候选标记为无损。校验不通过的候选仍然会列出，因为部分还原往往已经足以看懂原文，即使无法完整复现。

编码表从哪来

解码方向直接用浏览器的 TextDecoder。反方向要麻烦些——TextEncoder 只支持 UTF-8，所以工具通过遍历字节空间、逐个询问解码器的方式反推出编码表。这样映射永远与浏览器自身行为一致，也不必向你的设备下发任何映射数据。

排序启发式，以及它的边界

在往返校验之外，候选还会按可读性打分：常用汉字（GBK 首字节落在 0xB0–0xF7 那一段）占比加分，替换符、半角片假名、控制字符扣分。半角片假名是 Shift_JIS 误读的强特征，因为正常日文文本几乎不用它。这是启发式，只用于打破平局，不负责判定真相。

怎样避免再次发生

修源头，不只是修那串字

每条候选下面标出的编码链会告诉你是哪个环节配错了。只修好文本却不改连接串编码、文件读取方式或导出设置，明天面对新数据还得再修一次。

整文件转换前先确认方向

先拿有代表性的一行到本页跑一遍。 方向反了会产生替换符，而这一步与最初那次误读不同——它不可逆。

所有地方都显式写死编码

数据库连接串编码、HTTP Content-Type、文件打开调用、CSV 导出选项。每一处依赖「系统默认编码」的地方，都是同一个 bug 换台机器就会复发的地方。

MySQL 里用 utf8mb4 而不是 utf8

MySQL 的 utf8 每个字符最多存 3 字节，emoji 和部分生僻汉字会被静默截断。utf8mb4 才是真正的 UTF-8。这类损坏与乱码不同，本工具救不了——那些字节是真的没了。

在验证修复之前留住原始字节

动手转换前先备份。只要原始字节还在，任何一次错误的解码都是可逆的；一旦被替换符覆盖写回，本页和其他任何工具都无能为力。

常见问题