XML加密是W3C标准，选择性加密敏感元素或内容，保留XML结构可解析性；常用<EncryptedData>替换原节点，含Type、EncryptionMethod等字段；须独立管理密钥，优先加密内容而非整个元素，注意Id、URI、命名空间及归一化一致性。
XML加密不是对整个XML文件加密，而是选择性加密特定元素或内容
XML加密（XML Encryption）是W3C标准，核心目标不是把整个.xml文件当二进制流加密，而是保留XML结构可解析性的同时，只加密敏感节点（比如<Password>、<CreditCardNumber>）。加密后仍为合法XML，其他系统可跳过密文继续处理未加密部分。
用<EncryptedData>替换原始元素是最常用方式
标准做法是：定位目标元素 → 用其内容生成密文 → 用<EncryptedData>结构替换原节点。该结构包含Type（如http://www.w3.org/2001/04/xmlenc#Element表示加密整个元素）、EncryptionMethod（如http://www.w3.org/2001/04/xmlenc#aes256-cbc）、CipherData等关键字段。
实操建议：
- 优先加密元素内容（
Type="http://www.w3.org/2001/04/xmlenc#Content"），避免破坏父元素结构和命名空间 - 若加密整个元素（如
<SSN>123-45-6789</SSN>），替换后原标签名丢失，需在<EncryptionProperties>中记录原始名称供解密方还原 - 密钥管理必须独立：不要硬编码密钥到XML或代码中；推荐用
<EncryptedKey>嵌套加密会话密钥，并用接收方公钥加密该密钥
主流语言有成熟库，但密钥协商和URI引用容易出错
Java用Apache Santuario，.NET用System.Security.Cryptography.Xml，Python可用lxml配合cryptography手写逻辑。常见坑：
-
Id属性未设或重复：加密时指定Id="foo"，但XPath定位时写错路径，导致找不到目标节点 - URI引用不匹配：加密后
<EncryptedData>的Id与ds:Reference URI="#foo"中的#foo不一致，签名验证失败 - 命名空间污染：原始XML含
xmlns:ns="..."，加密后<EncryptedData>未声明相同前缀，导致XPath查找失效 - 时间戳未同步：若结合XML签名使用，
<ds:SignedInfo>中CanonicalizationMethod算法必须与加密前归一化方式一致，否则验签失败
解密时必须按<EncryptedKey>→<EncryptedData>顺序处理
一个XML可能含多个<EncryptedData>，每个对应不同<EncryptedKey>。解密流程不可跳步：
1. 解析所有 <EncryptedKey>，用本地私钥解出对称密钥（如AES密钥） 2. 遍历 <EncryptedData>，根据其 <KeyInfo> 中的 <RetrievalMethod> 或 <KeyIdentifier> 匹配对应解密密钥 3. 检查 <EncryptionMethod> 算法是否受支持（如不支持 aes192-gcm 就会报错） 4. 用匹配密钥+IV解密 <CipherValue>，再按 <Type> 决定是替换整个元素还是仅替换文本内容
最容易被忽略的是第2步——很多库默认只认第一个<EncryptedKey>，若XML中密钥顺序错乱或缺少Id关联，会导致解密出乱码却无明确报错。
