问题标签 [canonicalization]

我的问题是此页面上的步骤 6、7 和 8：http: //docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html

第 6 步和第 7 步很容易遵循。出于说明目的，您可以使用免费的生成器： http: //hash.online-convert.com/sha256-generator

Action=ListUsers&Version=2010-05-08转换为b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2，就像它说的那样。但是在第 8 步，它说要使用相同的算法，

根本不转换为3511de7e95d28ecd39e9513b642aee07e54f4941150d8df8bf94b328ef7e55e2。相反，我得到8b483975a604a39ca8882bc11bc0101df17c9ecc64a96206e504babc614fcb37. 这个例子对我来说很不清楚。我可能会错误地解释它，但是如何？

我有这样的代码：

当我写道：

它返回

不是

有什么方法可以获得区分大小写的值吗？

I'm learning for my exams in the course databases and have some problems with the functional dependencies.

So I got the functional dependencies:

A->BE, AE->BD, F->CD, CD->BEF, CF->B

After decomposition and left-reduction I get:

A->B, A->E, A->D, F->B, F->C, F->D, CD->B, CD->E, CD->F

So after checking for transitivity's I get as solution:

A-> BDE, F->CD, CD->BEF

But I'm not sure if its right. I did the same steps like in this tutorial here:

http://www.youtube.com/watch?v=lKYz5e7INTg

Thanks for any help!

我正在编写一个带有一点 WS-Security（XML 签名）的简单 CXF 客户端和服务器。到目前为止，一切都很好。

我想更改的是规范化算法EXCLUSIVE（C14N_EXCL_OMIT_COMMENTS aka “ http://www.w3.org/2001/10/xml-exc-c14n# ”）。

每次我输入错误的文件名时，它都会导致正则表达式不匹配。我在哪里做错了是正则表达式还是其他东西。为什么 r 总是匹配 REG_NOMATCH

使用 Zend 框架 1.12、PHP 5.3.1。为 Zend_Mail 指定多个邮件收件人并使用 Smtp 传输，“To:”标头包含以逗号分隔的收件人列表。例如

To: a@example.com,b@example.com

根据RFC 2822，这似乎是正确的语法。我添加了 DKIM 签名（使用https://github.com/louisameline/php-mail-signature），它可以正常工作，生成 gmail 和其他验证者接受的传递签名，只有一个 To: 收件人。但是对于多个recipents，签名失败。

发送签名邮件check-auth@verifier.port25.com将电子邮件返回到 Return-path，其中包含各种检查的结果，其中包含它计算的标头和正文的规范化版本。我看到它在规范化 To: 标头时在每个逗号后添加了一个空格（我正在为标头和正文指定宽松的规范化）。事实上，我在规范化 To: 标头时破解了我的签名生成以添加该空间，这解决了问题：port25.com 验证程序、gmail 和其他人现在通过了签名。

但是在我看到的关于 DKIM 宽松规范化的任何描述中，包括对RFC 6376的第 3.4 节的非常仔细的阅读，以及我从上面引用的 github 下载的签名类中的代码，都没有添加任何空白的地方存在于原件中；指定的规范化都是关于更改现有空格的。

所以在我看来，由 port25 验证器完成的规范化与 RFC 6376 不一致——除了 gmail、autorespond+dkim-relaxed@dk.elandsys.com 和http://www.appmaildev 等其他 DKIM 验证器。 com/en/dkim/都同意最终结果（他们没有像 port25 那样显示他们执行的规范化，但如果我不规范化逗号后的空格，他们会拒绝签名）。

这里有人对此有任何见解吗？由于该领域的实践似乎与 2011 年的 RFC 一致，难道不应该更新 RFC 吗？当然还有一个问题，在 WSP 被单个空格替换之前，是否应该将 To: 标头值中的所有逗号规范化为逗号空间，以及是否影响任何其他标头。

最终决议摘要

关于 OP，Evan 的回答完全正确：我的 MTA 是在添加空间，而不是验证器的规范化。我只是没有仔细查看实际收到的 To: 标头。

但是知道这一点并不能完全解决生成正确签名的问题。“根本”问题是 Zend_Mail 使用逗号在标题中生成地址列表值，而没有后面的空格作为分隔符 - 尽管它是完全有效的语法，但对于 MTA 来说，在每个之后引入一个空格也是完全有效的。RFC 6376 指定并广泛实施的宽松规范化不适应这种 MTA 重写。将 Zend_Mail 代码更改为使用逗号空格作为分隔符将是微不足道的，除了它是在一个相当长且复杂的方法中间完成的，该方法将涉及主要的复制粘贴来覆盖，这感觉是错误的。所以我最终做的是编写一个预过滤器，在签名之前将空格放在标题中。

与此问题类似，我正在尝试计算 SEPA 容器文件的文档哈希值。这是我的代码当前生成的容器：

根据银行提供的格式检查工具，我的文件大部分是正确的，除了散列。由于 PHP 的 SHA256 实现可能没有错，我认为我在规范化文档时做错了。

有问题的代码相当简单：

$element<Document>是包含节点的 DOMElement 。该函数在容器文件的创建过程中被调用；因此该xmlns:xsi参数不适用于节点。但是，手动添加它似乎并没有改善问题。

生成的哈希是错误的 - 它是 058098433DAC5D66ED34933CFFD98BF65CAD5C97CC45F9B0619B1FF96C3930E7；根据格式检查器的预期值为 942AB2F57DBAF6302EDC526472098DF38C540EB75E1913DAB0DF416D168C3253。现在的问题是我在这里做错了什么——或者更确切地说，为了取悦银行，我必须如何处理我的 XML。

看起来是这样$text的：（不幸的是，规范化的 XML 不能生成漂亮的代码块。）

我有一个依赖查询字符串的单页在线应用程序。添加了 Google Analytics 跟踪，但直到几天后才添加规范元数据，因此由于查询字符串的差异，现在 Analytics 显示同一页面的多个条目，例如“/app/?s=4324,543 ,12421”和“/app/?s=5234,86754”，而规范只是“/app/”。

有没有办法合并 GA 中额外页面（在报告 > 行为 > 概述中）的数据，这些页面已经被规范化了？

我正在寻找在 C++ 中规范化部分 XML 文档的最简单方法。对我来说最好的选择是小型库（我不是 c++ 大师），我可以简单地将其添加到我的项目中。
如果没有这样的方法，我必须创建规范化部分 mysefl，我必须记住什么？要删除所有不必要的空格、换行符并按字母顺序设置属性（和命名空间）？
我必须手动创建数字签名，而这种规范化是其中的一部分。
我在 Windows 上工作，所以来自 Linux 的任何工具都无济于事

当必须根据http://www.w3.org/TR/xml-exc-c14n/规范化 XML 时，以下 XML 是否应该相等？（注意，.字符代表' '空格）

和

换句话说：Exclusive Canonicalization 是否忽略空格？（或忽略缩进大小）

或者，缩进是否​​应该保持不变？那么第一个呢？<b>（从秒的例子）的规范化版本会变成

或者

或者