ISO-8859-1不支持中文，乱码主因是声明与实际编码不匹配；须用工具确认真实编码，再同步修改声明或文件内容，并在解析时显式指定编码。

XML声明里写encoding="ISO-8859-1"却显示中文乱码

这不是编码声明错了，而是根本用错了字符集——ISO-8859-1（即Latin-1）压根不包含中文字符。它只定义了0–255范围的字节映射，中文需要至少双字节表示，所以XML解析器读到中文字节时会直接报错或替换成。

• 常见错误现象：org.xml.sax.SAXParseException提示“Invalid byte 2 of 3-byte UTF-8 sequence”，或浏览器/IDE里中文全变成问号、方块、
• 真实使用场景：老系统导出的XML硬编码了ISO-8859-1，但实际内容混入了UTF-8编码的中文（比如从数据库或网页抓取的数据）
• 别试图“修复”声明：把encoding="ISO-8859-1"改成"UTF-8"却不改文件二进制内容，会导致更严重的解析失败

确认文件真实编码再决定怎么改

不能只看XML声明，得看文件实际字节。用file -i filename.xml（Linux/macOS）或VS Code右下角编码标识（注意点开确认是“Reopen with Encoding”而非“Save with Encoding”）。

• 如果真实编码是UTF-8：必须同步修改XML声明为encoding="UTF-8"，否则解析器按ISO-8859-1读UTF-8字节，必然乱码
• 如果真实编码确实是ISO-8859-1：那文件里根本不可能有合法中文——所谓“中文”其实是错误转码残留，比如UTF-8字节被当Latin-1解码后显示成“某些文字”，此时要回溯源头，确保生成XML时用UTF-8编码写入
• Windows记事本保存的“UTF-8”可能带BOM，而某些老解析器（如Java DocumentBuilder）对BOM敏感，建议用xxd filename.xml | head检查开头是否为ef bb bf，如有且报错，可转为无BOM UTF-8

Java解析时显式指定编码比依赖声明更可靠

XML声明只是建议，很多解析器（尤其老版本JDK）默认忽略或处理不一致。与其赌声明，不如在代码里锁死编码。

• 用InputStream + InputStreamReader手动指定：

  new InputStreamReader(new FileInputStream("a.xml"), "UTF-8")

• 用SAXParserFactory时，传入InputSource并设编码：

  InputSource src = new InputSource(new FileInputStream("a.xml")); src.setEncoding("UTF-8");

• Spring的Resource加载XML时，ClassPathResource不认XML声明，必须靠外部指定编码，否则默认用平台编码（Windows是GBK，Linux是UTF-8），极易不一致

Python里xml.etree.ElementTree默认不认声明

ElementTree.parse()底层用的是系统默认编码，不是XML里的encoding属性。声明只对xml.parsers.expat这类底层解析器生效。

• 安全做法：先用open(... , encoding="utf-8")读成字符串，再用ET.fromstring()解析
• 或者用ET.parse()配xmlparser：

  parser = ET.XMLParser(encoding="utf-8"); tree = ET.parse("a.xml", parser)

• 如果文件是Windows生成的，注意换行符和BOM干扰；encoding="utf-8-sig"能自动剥离BOM，比硬写"utf-8"更健壮

XML头部声明只是纸面约定，真正起作用的是文件字节流本身和解析器如何解读它。最容易被忽略的，是以为改了encoding属性就万事大吉，结果文件内容和声明持续不匹配。