xml声明的encoding属性必须与实际字节编码严格一致，否则会导致乱码或解析失败；解析器不自动探测编码，需手动确保文件保存、http头、api调用等各环节编码统一。
XML声明中的encoding属性必须与实际字节编码一致
XML解析器不会自动探测编码，它完全依赖<?xml version="1.0" encoding="UTF-8"?>声明来决定如何解码字节流。如果文件实际是GBK编码，但声明写成UTF-8，就会出现乱码或解析失败（如UnicodeDecodeError或XMLSyntaxError: invalid byte sequence）。
- 用
file -i filename.xml（Linux/macOS）或chardet filename.xml（Python）确认真实编码 - 编辑器保存时务必选择与声明匹配的编码格式；VS Code、Notepad++ 都需手动设置“编码→另存为”
- HTTP传输时，
Content-Type头中的charset优先级高于XML声明，二者冲突会导致浏览器/客户端行为不一致
Python xml.etree.ElementTree默认按UTF-8读取，不读声明
ElementTree.parse()在传入文件路径时，会直接以系统默认编码（通常是UTF-8）打开文件，完全忽略XML声明里的encoding。这意味着：即使XML文件开头写着encoding="GBK"，用ET.parse("data.xml")仍会按UTF-8尝试解码，大概率报错。
- 正确做法是先用指定编码读取为字符串，再用
ET.fromstring()解析：with open("data.xml", "rb") as f: content = f.read() root = ET.fromstring(content.decode("GBK")) - 或者用
codecs.open(..., encoding="GBK")配合ET.parse()，但必须传入文件对象而非路径字符串 -
lxml.etree更健壮：它会主动检查XML声明并自动适配编码，推荐在处理编码不确定的XML时替换使用
Java DocumentBuilder需要显式设置InputStream编码
Java标准DOM解析器不会从XML声明中推断编码，DocumentBuilder.parse(new File("data.xml"))底层仍走平台默认编码（如Windows上常为GBK），极易出错。
- 必须用
InputStream+InputSource控制编码：InputStream is = new FileInputStream("data.xml"); is = new ByteArrayInputStream(is.readAllBytes()); // 确保可重读 InputSource source = new InputSource(is); source.setEncoding("UTF-8"); // 显式设为与XML声明一致的值 Document doc = builder.parse(source); - 若用
FileInputStream直接构造InputSource，setEncoding()无效——因为流已按系统默认编码打开，字节早已损坏 - Spring的
Dom4jUtils或JAXBContext通常封装了编码处理，但需确认其是否读取了XML声明；否则仍需预处理
XML转义字符与编码无关，但影响可读性与传输安全
<、你这类实体始终按Unicode码点解释，与文档编码无关。但错误的编码设置会让这些实体本身变成乱码——比如你在GBK下被误读为两个非法字节，导致解析器跳过或报错。
- 避免在非ASCII内容中混用实体和原始字符：统一用UTF-8保存+原始汉字，比全用
...更可靠 - HTTP POST提交XML时，确保
Content-Type: application/xml; charset=UTF-8与XML声明、请求体编码三者严格一致 - 数据库存储XML字段前，确认字段字符集（如MySQL的
utf8mb4）支持全部所需Unicode字符，否则😂这类emoji会截断
