编码检测与乱码修复

乱码到底是怎么产生的

字符本身不会乱，乱的是「字节 + 解码规则」这一对。同样一串字节，按 UTF-8 念是「你好」， 按西欧编码念就是「ä½ å¥½」，按 GBK 念又是「浣犲ソ」。只要写入时用一种编码、读取时用另一种， 屏幕上就会出现这种能看出是「同一个字被念歪了」的乱码。这种乱码是可逆的，因为字节没丢。

修复就是反过来走一遍：先按当初错误使用的编码把字符还原成字节，再按正确的 UTF-8 解码。 反着还原需要「字符到字节」的表，而浏览器只提供了「字节到字符」的 TextDecoder， 所以这个工具第一次使用时会在本地把所有字节组合解一遍、建出反查表，之后就一直复用。 建表在浏览器里完成，文本不会上传。

三种常见的错配方向

Windows-1252 / Latin-1：乱码里全是 æ µ ‹ è ¯ 这种西欧字母和符号。 这是最典型的一种，常见于 UTF-8 字节被当成西欧编码渲染，比如老邮件客户端、没声明字符集的网页。

GBK：乱码看起来全是「娴嬭瘯涓€閿」这种生僻汉字。UTF-8 的中文一个字三个字节， 每两个字节被 GBK 读成一个字，所以乱码长度大约是原文的 1.5 倍。国内的老系统、Excel 导出的 CSV、 记事本另存为 ANSI，都是这种。

Big5：同样的道理，换成繁体中文常用的 Big5。如果 GBK 修出来不对、Big5 修出来通顺， 就说明当初是按繁体编码读的。

什么时候修不回来

如果输入里出现了 �（替换符号），说明当初解码那一步就已经把读不懂的字节丢掉了， 信息不在文本里，工具也无能为力。同样地，GBK 解码遇到不成对的字节会直接跳过，那种丢失也是不可逆的。 这两种情况只能回到原始文件或原始字节重新转一次。

还有一类是「转了好几手」，比如先被当成 GBK 又被当成西欧编码。工具会把单次修复的结果再跑一遍， 把连着修两次的路径也列出来，但层数越多越容易失败，因为每一层都可能已经丢字节。

怎么从源头避免

统一用 UTF-8：网页在 <head> 里写 <meta charset="utf-8">， 服务器响应头带上 Content-Type: text/html; charset=utf-8，数据库连接串写明 characterEncoding=utf8，导出 CSV 时选「UTF-8 带 BOM」让 Excel 认出来。

Linux 上排查可以用 file -i 文件名 看编码，用 iconv -f gbk -t utf-8 旧文件 > 新文件 批量转换。转换前先备份，因为方向猜错的话就会把好文件也弄坏。