xmlcipher支持元素级加密，只需传入目标element（如passwordelem）并调用dofinal(doc, targetelement)，可保留xml结构；需用getelementsbytagname精准定位，设setsubtree(true)加密子树，解密时通过encrypteddata的type属性识别。
用 XMLCipher 只加密指定节点（Java）
直接加密整个 XML 文件太粗暴，敏感字段（比如 <password></password>、<idcard></idcard>）单独加解密才是实用做法。Java 生态里最稳的选择是 XMLCipher，它支持「元素级加密」，即只对某个 Node 或 Element 加密，其余结构和标签原样保留。
关键在调用 XMLCipher 时传入目标 Element，而不是整个 Document：
XMLCipher cipher = XMLCipher.getInstance(XMLCipher.AES_128); cipher.init(XMLCipher.ENCRYPT_MODE, key); cipher.doFinal(doc, targetElement); // ← 这里 targetElement 是你要加密的那个节点，比如 passwordElem
- 必须先用
doc.getElementsByTagName("password").item(0)精准定位节点，不能传父节点或 Document - 加密后该节点会变成
<encrypteddata></encrypteddata>，原始标签名丢失，解密时靠Id或Type属性识别 - 如果节点有子元素或属性，
doFinal默认只加密文本内容；要连同子树一起加密，得提前调用cipher.setSubtree(true)
xmlsec 命令行加密单个元素（Linux/macOS）
不想写 Java？xmlsec1 命令行工具能干同样事，适合 CI/脚本或临时处理。但它不支持“按标签名模糊匹配”，必须用 XPath 定位到具体节点。
例如加密所有 <ssn></ssn> 节点：
xmlsec1 --encrypt --pubkey-pem pubkey.pem \ --node-xpath "//*[local-name()='ssn']" \ --output encrypted.xml input.xml
-
--node-xpath是核心，写错 XPath 就没加密——常见错误是忘了local-name()绕过命名空间，或用了//ssn却没声明默认命名空间 - 加密后原节点被替换成
<encrypteddata></encrypteddata>，但父结构、兄弟节点、注释、空格全保留 - 若 XML 含多个同名节点，
xmlsec1默认只加密第一个；要全加密，得加--nodes-iterator参数（部分旧版本不支持）
加密后 XML 的解析兼容性问题
加密后的 XML 仍是合法 XML，但多了 xenc: 和 ds: 命名空间，普通 DOM/SAX 解析器不会报错，但业务代码容易出问题。
- 用
getElementsByTagName("password")找不到加密后的节点——它已变成<encrypteddata></encrypteddata>，得先查EncryptedData再判断Type属性是否为http://www.w3.org/2001/04/xmlenc#Element - 某些老旧 XML 库（如早期 .NET
XmlDocument）默认不加载外部命名空间，导致xenc:元素被忽略或解析失败，需显式调用SetPrefix或启用命名空间感知 - 加密节点若含 CDATA 段，
XMLCipher会将其转为普通文本节点再加密，解密后不再保留 CDATA 包裹——这不是 bug，是 W3C 加密规范要求
别碰 Base64 + 手动替换这种“假加密”
有人图省事，用 Base64.encode(passwordText) 后字符串替换 <password>xxx</password> → <password>MTIzNDU=</password>。这根本不是加密，只是编码，毫无安全意义。
- Base64 不是加密算法，无密钥，任何工具秒解
- 破坏了 XML 结构语义：密码字段类型从 string 变成 base64 字符串，下游系统可能校验失败
- 无法与标准解密流程对接，比如用
xmlsec解密时会跳过这种“伪加密”节点，导致逻辑断裂
真正要做的，是让加密节点可被标准工具识别、解密、还原回原始结构——这点最容易被跳过，但决定了方案能不能长期维护。
