XML乱码主因是encoding声明与实际编码不一致，需确保编辑器编码、XML声明、解析时open()参数、HTTP响应头charset四者统一为UTF-8（无BOM）或对应编码。
XML声明里encoding写错或缺失导致乱码
XML文件一打开全是问号、方块或中文变符号，八成是声明里的encoding属性和实际保存编码不一致。浏览器和解析器（比如Python的xml.etree.ElementTree）会严格按这个声明去读，哪怕你用UTF-8保存，但声明写成encoding="GBK"，照样乱。
实操建议：
- 用文本编辑器（如VS Code、Notepad++）右下角确认当前文件真实编码，再检查XML第一行是否匹配：
- 如果编辑器显示“UTF-8 with BOM”，而声明是
UTF-8，也容易出问题——BOM头会让某些解析器误判，建议统一存为“UTF-8 without BOM” - 没有
声明时，XML规范默认按UTF-8解析，但Windows记事本另存时默认加BOM，此时不声明反而更稳
Python读取XML时open()没指定encoding参数
用xml.etree.ElementTree.parse()直接传文件路径看似省事，但它底层会调open()，而Python 3 默认用系统编码（Windows上常是GBK），跟XML声明冲突就崩。
实操建议：
- 别用
ET.parse("data.xml")，改用先手动打开再解析：with open("data.xml", encoding="utf-8") as f: tree = ET.parse(f) - 如果XML里声明的是
GBK，那就必须用encoding="gbk"，否则UnicodeDecodeError直接报错 - 用
requests.get().content拿到二进制再用ET.fromstring()时，别忘了先.decode("utf-8")，否则fromstring()会当字节流处理，出错提示很隐晦
IDE或编辑器自动转码导致保存后编码“悄悄变”
VS Code、IntelliJ这些工具常在你没注意时把UTF-8文件另存为UTF-8 with BOM，或者把带BOM的文件识别成GBK再重存——表面看内容没动，但文件头变了，XML解析器就翻脸。
本文档主要讲述的是Android的资源与国际化设置；资源是外部文件（不含代码的文件），它被代码使用并在编译时编入应用程序。Android支持不同类型的资源文件，包括XML，PNG以及JPEG文件XML文件根据描述的不同有不同格式。这份文档描述可以支持什么样的文件，语法，以及各种格式。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
实操建议：
- VS Code右下角点编码名称（如“UTF-8”），选“Save with Encoding” → “UTF-8”，别选“UTF-8 with BOM”
- Notepad++：菜单栏“编码”→“转为UTF-8无BOM格式”，然后保存
- Git用户注意：
.gitattributes里加*.xml text eol=lf encoding=utf-8能减少协作时的编码漂移
HTTP响应头Content-Type覆盖XML声明
通过fetch或axios加载XML时，如果服务端返回头里有Content-Type: text/xml; charset=GBK，浏览器会无视XML文件内的encoding声明，强行按GBK解码——这时连DOMParser都救不了。
实操建议：
- 用开发者工具Network面板确认响应头里的
charset值，和服务端配置对齐（Nginx用charset utf-8;，Spring Boot加spring.http.encoding.charset=UTF-8） - 实在没法改服务端，可用
response.arrayBuffer()手动读二进制，再用new TextDecoder("utf-8").decode()转字符串，最后传给DOMParser.parseFromString() - Node.js里用
axios时，默认responseType: "text"受headers影响，可改用responseType: "arraybuffer"自己控编码
真正卡住人的往往不是声明写不写，而是编辑器、IDE、HTTP栈、解析库四层编码逻辑叠在一起，改一处，另外三处没同步。动手前先用file -i data.xml（Linux/macOS）或PowerShell的Get-Content -Encoding Byte看真实字节，比猜快得多。
