xml中不能直接存放二进制数据，必须先用base64编码为合法ASCII字符；cdata仅跳过解析不豁免非法unicode，对原始二进制无效；各语言实现需确保无换行、填充完整。
XML里直接放二进制数据会出错
不能。XML规范只允许合法的Unicode字符，x00、xff、控制字符等原始二进制字节一写进去，解析器立刻报错，比如XMLSyntaxError: invalid character或ParseError: not well-formed。这不是编码问题，是语法越界。
常见错误现象：用fs.readFileSync读取图片后直接拼进XML字符串，或把Buffer转成字符串再塞进<data>...</data>——结果XML文件根本无法被DOMParser或xml2js加载。
- 别用
toString()硬转二进制Buffer，它默认用UTF-8解码，遇到非法字节就截断或替换 -
CDATA不是万能兜底：它只豁免字符引用和标签解析，不豁免非法Unicode字符本身 - 真正安全的路径只有一条：先编码，再当文本存
Base64是XML存二进制的实际标准方案
Base64把任意字节流映射成A–Z、a–z、0–9、+、/和=这65个可打印ASCII字符，完全符合XML对字符内容的要求。几乎所有语言都有现成支持，且解析开销可控。
使用场景：配置文件里嵌小图标、SOAP消息传附件、RSS扩展字段带缩略图、本地存储离线资源。
- 编码时用
buffer.toString('base64')（Node.js）或b64encode()（Python），别漏掉utf-8编码前提（如先text.encode('utf-8')再base64） - 解码时注意补全
=填充符，有些库（如JavaScript原生atob）要求长度是4的倍数，不足要手动补 - 大文件（>1MB）慎用：Base64体积膨胀约33%，且需全量加载到内存再解码，容易OOM
示例：<image encoding="base64">iVBORw0KGgoAAAANSUhEUgAA...</image>
CDATA只适合“已知安全”的文本型二进制伪装
CDATA段里的内容不被XML解析器当作标记处理，但它**不改变内容本身的合法性**。也就是说，只有当你确认二进制数据已经过编码（如Base64）、或本身就是纯文本（如json、XML片段、日志行），才能放心用![CDATA[...]]包住。
误用典型：把new Buffer([0xff, 0xfe, 0x00])直接丢进CDATA——依然非法，因为xff和xfe不在Unicode基本多文种平面有效范围内，XML声明版本再高也救不了。
-
CDATA本质是“跳过解析”，不是“跳过校验” - 它对Base64字符串是安全的，因为Base64输出全是ASCII；对十六进制字符串（如
fffe00）也安全 - 但对原始
.bin文件内容、加密后的密文块、未处理的序列化对象，一律不行
不同语言处理Base64的细节差异
Node.js、Python、Java、C#都支持Base64，但默认行为有坑：有的自动换行（76字符折行），有的不处理填充，有的对空白敏感。XML里必须用“无换行、无空格、填充完整”的变体。
- Node.js：
buffer.toString('base64')默认无换行，安全；但Buffer.from(str, 'base64')要求str末尾=数量正确 - Python：
base64.b64encode(data).decode('ascii')即可；若用base64.encodebytes()会加换行，XML里直接爆炸 - Java：
DatatypeConverter.printBase64Binary(byte[])安全；Base64.getEncoder().encodeToString()也行，但别用wrap()方法 - 浏览器JS：
btoa(encodeURIComponent(str))是错的！只能用于Latin-1，中文会乱；正确做法是先new TextEncoder().encode(str)再btoa()
跨语言传输时，务必在文档里写明Base64是否含换行、是否补全=——这点极容易被忽略，导致一方能编，另一方解不出来。