17370845950

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）

基本上就这些。核心就一条：声明、存储、读取，三者编码值必须严格一致，少一个环节出错，乱码就来了。