XML编码需声明、保存、读取三者一致；UTF-8兼容性好、字符全，GBK仅适老旧纯中文系统；C#读写应显式指定编码避免依赖声明。
XML文件的编码设置直接影响中文能否正常显示，关键不在“怎么写声明”，而在于声明、保存格式、程序读取三者必须严格一致。选UTF-8还是GBK，本质是根据使用场景做取舍：国际化优先选UTF-8，纯中文旧系统可考虑GBK。
XML声明里的encoding只是“说明书”，不是“转换器”
像这样的声明，只告诉解析器“请用GBK方式解码”，它不会自动把UTF-8内容转成GBK。如果文件实际是UTF-8保存的，但声明写成GBK，打开必然乱码。
- 用记事本另存为时，务必在“编码”下拉菜单中选对格式（UTF-8 或 GBK）
- 用VS Code、Notepad++等工具，右下角会显示当前编码，点击可快速切换并重新以该编码保存
- 不带BOM的UTF-8和GBK文件外观一样，仅靠肉眼无法判断，需借助十六进制查看器或工具检测真实字节
UTF-8和GBK的核心差异不只是“中文字节数”
很多人以为“UTF-8中文占3字节、GBK占2字节=GBK更省”，这忽略了根本区别：
- 字符覆盖：UTF-8支持Unicode全部字符（含emoji、少数民族文字、数学符号等）；GBK只覆盖中日韩汉字+少量符号，遇到英文引号“”、破折号——、甚至某些简体字（如“镕”“堃”），可能直接缺失
- 兼容逻辑：UTF-8完全兼容ASCII（0x00–0x7F），所有英文文本无需改动；GBK虽兼容GB2312，但与ASCII无直接映射关系，混合英文处理稍复杂
- 自同步性：UTF-8每个字节有明确标记位（如1110xxxx表示3字节字符首字节），即使传输中丢几个字节，后续仍可恢复解析；GBK无此机制，错一位可能导致整段乱码
C#里读写XML时，编码要手动“双保险”
不能只依赖XML声明。.NET默认按声明解析，但声明缺失或错误时极易翻车。稳妥做法是显式控制流编码：
-
读取时：用
StreamReader指定编码打开文件，再传给XmlReader.Create()，绕过自动检测 -
写入时：用
StreamWriter指定编码创建流，再用XmlWriter.Create()保存，生成的XML头会自动更新为对应encoding值 - 若需强制转码（如读UTF-8文件但存为GBK），先用正确编码加载成XDocument，再用GBK StreamWriter保存——中间不经过字符串重编码，避免二次乱码
什么情况该选UTF-8，什么情况可考虑GBK
没有绝对优劣，只有是否匹配实际环境：
