XML数字签名通过W3C标准实现完整性保护与身份认证，支持选择性签名并依赖规范化（如Exclusive Canonical XML）消除格式差异，结构含SignedInfo、SignatureValue和KeyInfo，常见于SAML、SOAP等场景，推荐使用Apache Santuario等成熟库。
XML数字签名是通过W3C定义的XML Signature Syntax and Processing（XML Signature）标准实现的，核心目标是对XML文档或其中一部分进行可验证的完整性保护和身份认证。它不是简单地对整个XML字符串哈希后签名，而是支持“选择性签名”——可以签整个文档、某个元素、多个不连续节点，甚至外部资源，并能抵抗XML规范化（Canonicalization）带来的格式变化干扰。
关键机制：规范化（Canonicalization）
XML允许等价但格式不同的写法（如属性顺序、空格、命名空间声明位置），直接哈希会导致相同语义的文档产生不同摘要。XML Signature强制使用规范化算法（如Inclusive Canonical XML 1.0或Exclusive Canonical XML 1.0）将待签名内容转换为唯一、确定的字节序列，再进行摘要和签名。这是正确验签的前提。
- Inclusive：保留所有在作用域内的命名空间声明，适合签名内容嵌套在复杂命名空间环境中
- Exclusive：只保留签名内容自身必需的命名空间，避免父级冗余声明影响，更常用
签名结构：SignedInfo + SignatureValue + KeyInfo
一个典型<signature></signature>元素包含三个必选部分：
-
SignedInfo：签名的输入数据，含
CanonicalizationMethod、SignatureMethod、一个或多个Reference（每个引用指向被签名的数据，含其URI、摘要算法、摘要值） -
SignatureValue：对
SignedInfo规范化后的Base64编码签名结果（如RSA-SHA256） -
KeyInfo（可选但推荐）：提供验证公钥信息，如
X509Data（含证书）、KeyName或RetrievalMethod
例如，签名一个<payment></payment>元素时，Reference的URI可能为#payment123，配合Transforms（如XPath筛选、 enveloped-signature 处理）确保只签目标节点。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
常见应用场景与用法要点
XML签名广泛用于SAML断言、SOAP消息安全（WS-Security）、电子发票（如UBL）、政务数据交换等场景：
-
Enveloped签名：签名元素嵌在被签名XML内部（最常见）。验签时需先从文档中移除
<signature></signature>自身，再规范化剩余内容 -
Enveloping签名：整个XML文档是
<signature></signature>的子元素，签名包裹内容 -
Detached签名：签名与原始XML分离（如单独文件），
Reference URI指向外部XML资源 - 务必校验
Reference中的DigestValue是否匹配实际数据摘要，且SignedInfo的签名值能被KeyInfo中公钥正确验证
实现建议：别造轮子，用成熟库
手动构造XML签名极易出错（尤其规范化、XPath转换、命名空间处理）。推荐使用经过广泛审计的库：
-
Java：Apache Santuario（
xmlsec），深度集成JDK安全框架 -
.NET：
System.Security.Cryptography.Xml命名空间（注意.NET Core/.NET 5+已整合进System.Security.Cryptography） -
Python：
signxml（基于lxml，支持多种规范和算法）或xmlsec绑定 - 生产环境务必禁用不安全算法（如SHA-1、RSA-PKCS#1 v1.5 without PSS），优先选用SHA-256/SHA-384 + RSA-PSS 或 ECDSA
基本上就这些。核心是理解“规范化先行、引用驱动、结构明确”，而非把XML当普通文本签名。标准细节虽多，但主流库已封装好关键路径，重点放在正确配置和安全参数上。
