我还没有找到为什么为什么有人比面向XAdES的人更喜欢实现面向CAdES的电子签名软件解决方案的任何原因。
互联网上有更多开放的库，实现案例以及XAdES的示例，但是我仍然不相信这是人们决定在CAdES上使用XAdES的原因。
是否因为XAdES是面向XML的，并且软件开发人员倾向于爱与XML相关的任何东西？在某些情况下，CAdES绝对是在XAdES上使用的最佳选择吗？
以供引用:
最佳答案
CAdES的优点之一是，它通常不会引起互操作性问题，因为XML-DSig标准允许许多选项，包括XSLT，XPointer Framework，XML规范化等等。如果仅处理严格的DER编码的签名，则CAdES的要求会降低(一旦您需要处理BER编码，图片就会发生变化)。
在需要在大数据块上生成“附加”签名的情况下，CAdES优于XAdES(您希望结果是包含原始数据和签名的单个数据块)。附加的CAdES签名的等效项(原始输入数据存储在CMS结构的EncapContentInfo元素中)为Enveloping Signature。如果您需要产生这种签名，那么如果您的XAdES实现是基于DOM的(我所知道的)，则在处理大型输入数据时很有可能会遇到问题-您的计算机最终将耗尽的内存。
性能将是支持CAdES的另一个理由。 CAdES的消息摘要计算通常直接在输入数据的原始字节上完成，在XML文档上计算的XML签名涉及很多开销，例如XPath表达式的评估，XSLT转换，Base64编码/解码和规范化，并可能包含多个Transform元素。
如果您要构建用于长期验证签名的存储(其中存储了很多签名)的归档系统，则CAdES是首选格式，因为与文本XAdES格式相比，其紧凑性。