XML中存储PDF或图片需先Base64编码为合法文本，不可直接嵌入二进制；否则引发解析错误，须用RFC 4648标准编码、去除换行、二进制模式读取，并建议用<data encoding="base64">标识。
XML里存PDF或图片，本质是存Base64编码字符串
可以，但不是“嵌入二进制”，而是把二进制数据用base64编码成纯文本后塞进XML元素或属性里。XML规范只允许合法字符（Unicode子集），直接写PDF字节流会破坏格式、导致解析失败。
常见错误现象：XML parsing error: invalid token、DOMDocument::load(): Start tag expected——多半是没编码就硬塞了二进制内容。
- 必须用标准Base64编码（RFC 4648），不能截断换行（有些工具默认每76字符加
\n，XML里要删掉） - 编码前确认原始文件完整：用
file_get_contents()（PHP）、readFileSync()（Node.js）等读取二进制模式，别用文本函数误删\x00等字节 - XML中建议放在
<data encoding="base64">这类带说明的标签里，方便下游识别处理方式
Python用base64.b64encode()存PDF到XML最简流程
关键不是“能不能”，而是“怎么避免乱码和体积膨胀”。Base64会让数据变大~33%，PDF本身又常含压缩流，再编码纯属雪上加霜。
使用场景：小图标（<attachment href="files/report.pdf"/>。
- 读PDF必须用
open("file.pdf", "rb")，传给base64.b64encode()，返回bytes，再用.decode("ascii")转字符串 - 写入XML时，确保该字符串不包含
<、&、"等特殊字符——base64输出只含A-Za-z0-9+/=，天然安全，无需xml.sax.saxutils.escape() - 别用
base64.encodebytes()：它自动加换行，XML里会多出\n字符，解析器可能报错
import base64
with open("logo.png", "rb") as f:
encoded = base64.b64encode(f.read()).decode("ascii")
# 然后拼进XML字符串或用xml.etree.ElementTree设置textJava里DatatypeConverter.printBase64Binary()已弃用，改用java.util.Base64
老项目还在用javax.xml.bind.DatatypeConverter？JDK 17+已彻底移除，编译直接失败。新代码必须切到java.util.Base64。
参数差异明显：DatatypeConverter输出带换行，Base64.getEncoder()默认不带——这反而是XML友好行为。
- 用
Base64.getEncoder().encodeToString(byte[])，输入是Files.readAllBytes(Paths.get("doc.pdf")) - 别用
Base64.getMimeEncoder()：它按MIME标准每76字符加\r\n，XML里就是非法空白 - 如果XML要通过SOAP传输，注意某些老SOAP栈对Base64长度敏感，超长字段可能被截断——实测超过500KB需分块或换方案
浏览器解析XML时，atob()解Base64图片但显示空白？检查三件事
前端从XML取<image>...base64...</image>后调atob()再转Blob，结果<img>啥也不显示——大概率不是编码问题，而是上下文陷阱。
-
atob()只支持ASCII字符，若XML被错误声明为encoding="UTF-8"但实际含BOM或非ASCII注释，解析后字符串可能损坏 - 别直接
document.querySelector("image").textContent：XML文档里空格、换行会被保留，atob()对首尾空白敏感，务必.trim() - 生成
Blob时类型字符串必须精确匹配，new Blob([bytes], {type: "image/png"})比"image/*"可靠；PDF同理用"application/pdf"
真正麻烦的是调试：XML里Base64串肉眼无法验证是否有效，建议服务端返回时同步提供content-length和sha256摘要，前端解完校验一次。
