linux/macos 下用 iconv 最可靠，windows 用 powershell + [system.text.encoding]；必须同步转换字节与 xml 声明中的 encoding 属性，确认真实编码（非仅声明），避免 bom 冲突，禁用记事本/notepad++ 批量转。
用 iconv 批量转 XML 文件编码最稳
直接结论：Linux/macOS 下用 iconv 最可靠，Windows 建议用 PowerShell + [System.Text.Encoding]，别信记事本另存为或 Notepad++ 批量转——它们会静默丢掉 BOM 或改坏声明里的 encoding="GBK"。
核心原因：XML 文件头部的 <?xml version="1.0" encoding="GBK"?> 不只是注释，解析器真会按它读字节。只转内容不改声明，等于埋雷；只改声明不转字节，直接报 Invalid byte 1 of 1-byte UTF-8 sequence。
- 先确认原始编码是否真是 GBK：用
file -i filename.xml或enca -L zh filename.xml，有些“GBK”其实是 GB2312 或 GB18030，iconv -f GBK对后者可能失败 - 批量处理时加
-o指定输出路径，别用-f直接覆盖原文件，一错全毁 - 示例命令：
iconv -f GBK -t UTF-8 input.xml -o output.xml，注意顺序：-f 是源，-t 是目标，反了会乱码
XML 声明里的 encoding 属性必须同步改
很多脚本只转字节，忘了改 行。Java、Python 的 xml.etree.ElementTree、甚至浏览器都会严格校验这个字符串和实际字节是否匹配。
- 用
sed -i 's/encoding="GBK"/encoding="UTF-8"/' *.xml（Linux/macOS）或(Get-Content f.xml) -replace 'encoding="GBK"', 'encoding="UTF-8"' | Set-Content f.xml（PowerShell）补这步 - 注意大小写：
GBK和gbk都可能出现，正则建议写成encoding=["'](?:GBK|gbk|GB2312|gb2312)["'] - 如果文件里有多个
encoding=（比如注释里误写），别全局替换，优先只改第一行的 声明
Python 脚本处理要绕开 xml.etree 的自动编码探测
直接用 xml.etree.ElementTree.parse() 读 GBK XML 会崩，因为它默认按 UTF-8 解码字节流，根本没机会传 encoding 参数。
- 正确做法：先用
open(file, encoding="gbk")读成字符串，再用ET.fromstring()解析，而不是parse() - 或者更稳妥：用
lxml.etree，它支持显式指定编码：etree.parse(file, parser=etree.XMLParser(encoding="gbk")) - 别用
str.replace("GBK", "UTF-8")硬改——XML 声明可能跨行、含空格、或被压缩成<?xml version="1.0"encoding="GBK"?>，正则都比字符串操作靠谱
Windows 上用记事本转编码为什么总出问题
因为记事本保存 UTF-8 时默认加 BOM，而很多 Java/XML 工具（如 JAXB、Spring OXM）把 BOM 当非法字符，报 Content is not allowed in prolog。
- PowerShell 中用
[System.IO.File]::WriteAllText("out.xml", $content, [System.Text.UTF8Encoding]::new($false))，第三个参数$false表示不写 BOM - Notepad++ 的“转为 UTF-8 无 BOM 格式”菜单项是安全的，但批量操作前务必关掉“以 UTF-8 格式打开所有文件”的选项，否则它会先用 UTF-8 解析 GBK 文件，直接乱码再保存
- 真实场景中，有些 XML 里混着 Base64 编码的 GBK 字节（比如附件内容），这种只能人工审，工具无解
真正麻烦的不是转编码本身，而是得确认每个文件的实际字节编码、声明值、BOM 存在与否、以及下游系统是否接受无 BOM UTF-8 —— 四个变量两两组合，就有至少六种失败路径。
