在日常开发中，编码乱码是一个高频且容易让人困惑的问题，尤其是涉及 UTF-8、UTF-8-BOM 与 GB2312 这几种编码格式时，很容易出现“看似不合理”的现象。最近我就遇到了一个典型场景：脚本文件最初用 UTF-8 编码，程序中指定 GB2312 读取时显示乱码；但将脚本改为 UTF-8-BOM 编码后，依然用 GB2312 读取，却能正常显示——这背后其实是 Windows 系统编码兼容机制的“小玄机”，今天就把这个踩坑过程和底层逻辑整理出来，帮大家避开同类问题。
场景很简单：我有一个包含中英文字符的脚本文件，具体情况如下：
sql脚本（UTF-8编码）：
C#语言：
using System.Text;
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
using (StreamReader sr = new StreamReader(@"C:\tmp\test.sql", Encoding.GetEncoding("GB2312")))
{
Console.WriteLine("===================GB2312====================");
Console.WriteLine(sr.ReadToEnd());
Console.WriteLine("===================GB2312====================");
sr.Close();
}
using (StreamReader sr2 = new StreamReader(@"C:\tmp\test.sql", Encoding.GetEncoding("UTF-8")))
{
Console.WriteLine("===================UTF-8====================");
Console.WriteLine(sr2.ReadToEnd());
Console.WriteLine("===================UTF-8====================");
sr2.Close();
}
数据库脚本修改为UTF-8-BOM编码后
先给大家一个最直接的结论，避免绕弯：
我的程序并不是“真的在用 GB2312 读取文件”，而是被 UTF-8-BOM 的特殊标记“强制切换”了编码：
首先要区分清楚 UTF-8 和 UTF-8-BOM 的核心差异：两者本质都是 UTF-8 编码，唯一区别是 文件开头是否包含 BOM 标记。
当脚本保存为 UTF-8（无BOM）时，程序按照指定的 GB2312 解码，必然会乱码——因为 UTF-8 和 GB2312 是两种完全不同的编码体系：
UTF-8 是国际通用编码，用 1-4 字节表示一个字符，中文通常用 3 字节；而 GB2312 是中文专用编码，用 1-2 字节表示一个字符，仅覆盖常用中文。两者的编码映射完全不同，用 GB2312 去解析 UTF-8 编码的中文，相当于“用错了解码字典”，自然会出现乱码（比如常见的“”“锟斤拷”等）。
这是整个问题的核心——Windows 有一个特殊的兼容规则：只要检测到文件开头有 BOM 标记（EF BB BF），就会优先将文件识别为 UTF-8 编码，无论程序中手动指定了什么编码。
所以当脚本改为 UTF-8-BOM 后，程序的执行流程变成了这样：
虽然“UTF-8-BOM + GB2312 读取”能正常运行，但这种方式本质是“投机取巧”，不是标准写法，长期使用可能存在兼容性隐患（比如在非 Windows 系统中，BOM 标记可能被解析为可见字符，导致脚本报错）。因此，推荐以下两种标准解决方案，按优先级排序：
这是从根源上解决问题的方式，也是开发中的标准做法：
如果暂时无法修改程序的读取编码（比如程序是固定配置，无法修改），那么继续使用 UTF-8-BOM 编码也是可行的：
这种方式的优势是“无需修改程序”，能快速解决乱码问题，且在 Windows 系统中完全正常运行；缺点是不符合编码标准，在非 Windows 系统中可能出现异常（比如 Linux 中会将 BOM 标记解析为乱码字符）。
为了让大家更直观地理解，分享两个快速验证的方法，自己动手就能验证上述逻辑：
通过这次踩坑，总结几个关键要点，帮大家避开同类问题：
编码问题看似复杂，但只要抓住“编码与解码统一”这个核心，就能避开绝大多数坑。希望这篇踩坑记录能帮到遇到同类问题的朋友，也欢迎大家在评论区分享自己遇到的编码乱码解决方案~
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。