xml不能直接存储二进制流，必须用base64编码为文本；超100kb应避免内联，优先用外部路径或url；base64需去空白、补等号、声明xsd:base64binary类型。
XML 本身不能直接存储二进制流
XML 是纯文本格式，所有内容必须是合法的 Unicode 字符；0x00、0xFF、换行前的裸 \r 等非字符字节会直接导致解析失败。你看到的“XML 里存图片”，实际都是编码后的文本表示，不是原始二进制。
常见错误现象：XML parsing error: invalid character 或 DOMException: InvalidCharacterError，往往就是把 raw bytes 当字符串拼进了 XML。
- 别用
Buffer.toString()（Node.js）或bytes.decode('utf-8')（Python）直接转二进制再塞进 XML —— 编码失败时会静默丢数据或报错 - 别手动替换
\x00为—— XML 不允许字符引用值0到8、11、12、14–31（除空格、\t、\n、\r） - Base64 是唯一被广泛支持、无歧义的方案；其他如 hex 编码可读性差，且不被标准工具链默认识别
用 Base64 嵌入图片：标准做法与参数注意点
Base64 把每 3 字节转成 4 个 ASCII 字符，安全、可嵌入任意 XML 元素值或属性中，但体积膨胀约 33%，且无压缩。
使用场景：小图标、签名图章、配置内联证书、离线打包的资源（如 SVG 中嵌 PNG fallback）。
关键参数差异：
-
base64.b64encode()（Python）和Buffer.from(imgData).toString('base64')（Node.js）结果一致，但注意末尾换行 —— XML 不允许元素内容含裸\n，需加.replace(/\s/g, '')或用带encoding='base64'的 DOM API - XML Schema 中应声明为
xsd:base64Binary类型，否则校验工具可能拒绝该值 - 浏览器
DOMParser能正常解析含 Base64 的 XML，但后续用atob()解码时需确保字符串长度是 4 的倍数（补=）
示例片段：
<image type="png">AQAAAGZmZg==</image>
大文件别硬塞进 XML：性能与兼容性红线
超过 1MB 的 Base64 内容会显著拖慢 XML 解析、序列化、内存占用，部分老系统（如 Java SAX 解析器配了低 entityExpansionLimit）甚至直接拒绝加载。
真实痛点：
- IDE 和 XML 编辑器（如 VS Code 的 XML 插件）对超长 Base64 行常卡顿或崩溃
- Git diff/merge 失效 —— 一行几万字符，无法比对变更点
- HTTP 传输时，未启用 gzip 的 Base64 XML 实际比压缩后的原始文件还大
- 移动端解析耗电明显，尤其低端 Android 设备上
atob()解大块 Base64 可能触发 ANR
替代方案优先级：外部文件路径
真正“嵌入”的边界在哪？别混淆封装与存储
XML 文件里写 <file href="data:image/png;base64,iVBOR..."></file>，这仍是 Base64 文本；而所谓“存储二进制”，只有在底层文件系统层面把 XML 和二进制块拼成一个文件（如 Compound Document 格式），那已不是 XML 规范范畴。
容易被忽略的点：
- XML 数字签名（
<signature></signature>）验证时，Base64 内容会被规范化处理（剔除空白、换行），若手动拼接出错会导致验签失败 - 某些 XML 库（如 Python 的
xml.etree.ElementTree）对超长文本节点内部做了截断优化，可能悄悄丢掉 Base64 尾部 - UTF-8 BOM 若意外混入 Base64 字符串开头，
atob()会直接报错 —— 检查是否用了fs.writeFileSync(path, '\uFEFF' + xmlStr)
事情说清了就结束。
