为什么直接用 Encoding.UTF8.GetString()
会乱码
GB2312 是双字节编码，UTF-8 是变长编码，两者字节序列不兼容。如果用
Encoding.UTF8去解码原本是 GB2312 编码的字节数组，
GetString()会按 UTF-8 规则错误解析每个字节，导致中文变成问号、方块或异常字符。反过来也一样：用 GB2312 解码 UTF-8 字节也会出错。
关键不是“选哪个 Encoding”，而是「明确原始字节的编码类型，再用对应 Encoding 解码」。
拿到的是 GB2312 字节数组？→ 用Encoding.GetEncoding("GB2312") 解码
拿到的是 UTF-8 字节数组？→ 用 Encoding.UTF8解码 需要把字符串从 UTF-8 转成 GB2312 字节？→ 先用 UTF-8 编码成字节，再用 GB2312 解码成字符串（中间不经过 string）
正确转换：UTF-8 字节数组 → GB2312 字节数组
这是最常遇到的场景：比如从 HTTP 响应、文件读取得到 UTF-8 字节，但下游系统只认 GB2312 字节流。不能先转 string 再 encode——因为若原始 UTF-8 含 GB2312 不支持的字符（如 emoji、生僻字），
Encoding.GetEncoding("GB2312").GetBytes() 会静默替换成问号，且不可逆。
安全做法是「字节到字节」转换，绕过 string 中间态：
public static byte[] Utf8BytesToGb2312Bytes(byte[] utf8Bytes)
{
var utf8 = Encoding.UTF8;
var gb2312 = Encoding.GetEncoding("GB2312");
// 先解码为 string（必须走这步，但仅限于你确认源内容纯中文/ASCII）
string text = utf8.GetString(utf8Bytes);
// 再用 GB2312 编码（注意：可能丢失字符）
return gb2312.GetBytes(text);
}
⚠️ 注意：
GetEncoding("GB2312") 在 .NET Core 3.0+ 和 .NET 5+ 默认不启用，需安装 System.Text.Encoding.CodePagesNuGet 包，并在启动时调用
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)，否则抛
NotSupportedException。
避免乱码的关键：识别原始编码再处理
很多乱码问题其实源于“不知道输入字节本来是什么编码”。比如读取文本文件时没指定 encoding，
File.ReadAllText(path)默认用 UTF-8，但如果文件实际是 GB2312 就必然乱码。 读文件：用
File.ReadAllBytes()拿原始字节，再根据 BOM 或业务约定判断编码 HTTP 响应：优先看响应头
Content-Type: text/html; charset=gb2312，而不是硬写
Encoding.UTF8无 BOM 的 GB2312 文件：无法 100% 自动识别，需人工约定或 fallback 尝试（如先试 GB2312，解码后检查是否含大量 ）
Windows 系统默认 ANSI 编码在简体中文环境就是 GB2312（准确说是 GBK 子集），所以用记事本另存为“ANSI”时，实际保存的是 GB2312/GBK 字节。
GB2312 和 GBK、GB18030 的兼容关系
GB2312 是较老的标准，只覆盖约 6763 个汉字；GBK 是其超集，支持约 2 万字；GB18030 支持全部 Unicode 字符，是国家标准强制要求。三者向下兼容：GB2312 字节流一定能被 GBK/GB18030 正确解码，但反之不行。
实践中建议：
新项目尽量用 UTF-8，避免编码转换 对接老系统必须用 GB2312？优先确认它是否实际接受 GBK —— 很多标称“GB2312”的系统内部已支持 GBK 用Encoding.GetEncoding("GBK") 替代 "GB2312"可减少字符丢失，但要注意 GBK 不是所有环境都注册（同样要
CodePagesEncodingProvider）
真正麻烦的不是转换代码怎么写，而是你永远不确定对方传来的“GB2312 字节”里有没有偷偷混进 GBK 扩展区的字 —— 这种边界情况只能靠实测和日志验证。
