这种乱码是怎么产生的
UTF-8 里一个常用汉字占 3 字节，GBK 里占 2 字节。当 GBK 解码器去读 UTF-8 字节时，会按 2 字节一组切分，切错了边界却往往仍落在 GBK 的合法双字节区间，于是输出一串形态怪异但「合法」的汉字——这就是「你好」显示成「浣犲ソ」的原因。因为每个字节都被完整保留、只是分组错了，这种乱码在数学上是可逆的，前提是链路中没有出现问号或其他替换。
基本信息
| 成因 | 用 GBK/CP936 解码 UTF-8 字节流 |
|---|---|
| 典型来源 | Windows 中文环境默认代码页、老程序按本地编码读文件、Excel 打开 UTF-8 CSV |
| 外观特征 | 汉字数量变多（3 字节变 1.5 个字），出现浣、犲、ソ、涓、鏂、浠这类生僻字 |
| 可逆性 | 通常可逆（字节未丢失时） |
| 还原方法 | 乱码串按 GBK 编码回字节 → 再按 UTF-8 解码 |
| 不可逆情形 | 链路上已写入问号或替换符，字节信息丢失 |
典型使用场景
- 老系统取数：程序按系统默认编码读取 UTF-8 文件，入库后全是怪字
- 报表导出排查：CSV 在某些工具里打开正常，在 Excel 里全乱
- 日志分析：日志本体是 UTF-8，查看工具按 GBK 渲染
- 数据修复：确认可逆后写脚本批量还原并回写
- 接口联调：对方用本地编码接收 UTF-8 请求体，落库后内容变形
还原与验证示例
还原与验证示例
# 单条验证：把乱码串按 GBK 编回字节，再按 UTF-8 解码
python -c "print('浣犲ソ'.encode('gbk').decode('utf-8'))" # 预期输出「你好」
python -c "print('鏂囦欢'.encode('gbk').decode('utf-8'))" # 预期输出「文件」
# 文件级修复：错误解码后的内容被存成了 GBK 字节文件时，直接反向转码
iconv -f GBK -t UTF-8 wrong.txt -o right.txt
# 无法确定时先做无损检查：确认没有问号与替换符
python -c "s=open('wrong.txt',encoding='utf-8').read();print('lossy' if ('?' in s or '\ufffd' in s) else 'maybe-reversible')"
# 修复后回归：抽样比对关键字段
head -3 right.txt常见乱码对照
| 原始内容 | 按 GBK 误读后 | 字节关系 |
|---|---|---|
| 你好 | 浣犲ソ | 6 字节被切成 3 组双字节 |
| 文件 | 鏂囦欢 | 同上，边界全错但落在合法区间 |
| 长文本 | 呈规律性成对错位 | 每 3 字节汉字被切成 1.5 组双字节，故汉字个数变多 |
| （已丢失） | 问号或替换符 | 编码阶段替换，无法还原 |
反向还原是标准套路：乱码字符串（Unicode 码点序列）→ 按 GBK 编码得到原始字节 → 按 UTF-8 解码得到正确文本。用命令行工具时等价于「文件里的字节本来就是 UTF-8，只是被当 GBK 存成了别的字节」，因此常见的做法是 iconv 反向转一次。
有些字节组合在 GBK 下不是合法序列，会因此报错或出现替换字符；一旦出现替换字符，说明信息已部分丢失，只能最大程度还原并人工核对，不要期待全自动完美修复。
修复要一次性做对：如果先按错误编码把文件另存为 GBK，再想还原就需要多做一次反向操作，且每一步都可能引入替换符。修复前先备份原始字节，在副本上验证，确认后再替换原件。