XML编码需声明、保存、解析三者严格一致；默认UTF-8，声明encoding属性须真实反映文件编码，推荐无BOM UTF-8，避免GBK跨平台问题，解析时应显式指定编码。
XML本身不规定必须用哪种编码，但默认是UTF-8；实际编码由声明中的encoding属性指定，比如。关键在于声明、保存、解析三者必须一致，否则就会乱码。
XML声明里的encoding要真实反映文件编码
声明只是“告诉解析器怎么读”，不是“让文件变成这个编码”。如果文件实际是UTF-8，却写encoding="GBK"，解析器就会按GBK去解码UTF-8字节，结果必然错乱。
- 用文本编辑器（如VS Code、Notepad++）打开XML，先确认右下角显示的真实编码
- 再检查首行声明是否匹配——不匹配就改声明，或另存为对应编码格式
- 没有声明时，XML标准规定解析器默认按UTF-8处理（不含BOM）或UTF-16（含BOM）
保存文件时选对编码，尤其注意BOM问题
UTF-8有带BOM和无BOM两种常见形式。Windows记事本默认存带BOM的UTF-8，而很多Linux工具或Java解析器对BOM敏感，可能报“非法字符”错误。
- 推荐统一使用无BOM的UTF-8，兼容性更好
- GBK（或GB2312/GB18030）适合纯中文老系统，但跨平台支持弱，新项目尽量避免
- 用Notepad++可点击“编码 → 转为UTF-8无BOM格式”，再保存
程序解析时别依赖自动探测，显式指定编码
很多XML解析库（如Python的xml.etree.ElementTree、Java的DocumentBuilder）会优先读声明，但若声明缺失或错误，可能自行猜测编码，导致不稳定。
- Python中建议用
open(file, encoding='utf-8')先读成字符串，再用ET.fromstring()解析，绕过底层编码判断 - Java里用
InputStreamReader(new FileInputStream(f), "GBK")包装流，再传给SAXParser - 不要依赖
new String(bytes)这种无参构造，它用系统默认编码，极不可靠
遇到乱码先查三层：声明、文件、解析器
一个典型排查顺序：
- 用十六进制查看器（如HxD）打开XML，看开头几个字节：EF BB BF = UTF-8 BOM，A1 A2 = GBK常见汉字头
- 对比声明里的encoding值是否与字节特征吻合
- 检查代码中读取文件的方式是否覆盖了原始编码（例如用FileReader而没指定charset）
基本上就这些。核心就一条：声明、存储、读取，三者编码值必须严格一致，少一个环节出错，乱码就来了。
