xml声明中的encoding必须与文件实际二进制编码完全一致，否则会导致解析失败、中文乱码或“invalid byte 1 of 1-byte utf-8 sequence”错误；务必用文本编辑器手动保存为utf-8（无bom），代码生成时显式指定encoding="utf-8"并启用xml_declaration=true，批量修正需先确认真实编码再用iconv等工具转换，且http传输中content-type优先级高于xml声明。
XML声明里的encoding必须和实际文件编码完全一致
XML解析失败、中文变乱码、工具报Invalid byte 1 of 1-byte UTF-8 sequence，八成是这个原因。不是“写了UTF-8就万事大吉”，而是文件二进制字节流真得是UTF-8编码——否则声明就是假话，解析器会直接拒掉。
- 用文本编辑器保存时，务必手动选“UTF-8（无BOM）”，Notepad++/VS Code 都有明确下拉选项，别信默认
- Python写XML时，
xml.etree.ElementTree.write()默认不带声明且用系统编码，必须显式传encoding="utf-8"并设xml_declaration=True - Java里
Transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8")只管输出声明，底层OutputStream还得用OutputStreamWriter套一层UTF-8编码
用iconv或recode批量修正已错编码的XML文件
线上一堆GBK编码却声明UTF-8的XML？别手改。命令行转码最稳，但顺序不能错：先按声明反解，再按真实编码重读，最后写新声明。
- 确认真实编码：用
file -i broken.xml或enca -L zh broken.xml看实际字节分布 - 若真实是GBK，声明却是UTF-8：先用
iconv -f gbk -t utf-8 broken.xml > fixed.xml，再确保新文件头是<?xml version="1.0" encoding="UTF-8"?> - Windows记事本存的UTF-8带BOM？
sed -i '1s/^\xEF\xBB\xBF//' file.xml（Linux/macOS）或用xxd删前3字节
Python生成XML时绕不开的ElementTree编码陷阱
ElementTree写文件最常踩坑：不设encoding参数，它就用sys.getdefaultencoding()（常是ascii），一写中文就崩；设了又容易漏xml_declaration=True，导致没声明但内容是UTF-8，某些老解析器仍报错。
- 安全写法：
tree.write("out.xml", encoding="utf-8", xml_declaration=True) - 如果用
tostring()拼接再写入，必须自己加声明：b'<?xml version="1.0" encoding="UTF-8"?>' + ET.tostring(root, encoding="utf-8") - 别用
open().write()直接写tostring(root, encoding="unicode")结果——那是str，不是bytes，编码逻辑全乱
XML解析器对编码不一致的容忍度差异极大
libxml2（lxml底层）、Xerces-C这类严格派，声明和字节不匹配直接抛异常；而部分Java DOM实现或老旧浏览器XML parser可能“自动纠错”，结果中文显示错位或截断——这反而更危险，问题被掩盖。
- 测试时别只看浏览器能打开：用
xmllint --noout --encoding UTF-8 file.xml强制校验声明与内容一致性 - HTTP传输时，
Content-Type: application/xml; charset=utf-8优先级高于XML声明，但本地文件只认声明+字节 - IDEA/Eclipse里XML文件属性设为UTF-8，仅影响编辑器显示，不改变保存行为——保存动作本身才是关键
encoding="UTF-8"，而是从编辑器保存、代码生成、管道传输到最终解析，每个环节都得对齐同一套字节解释规则。少一个环节对不上，前面全白干。 
