以下问题比最初看起来要复杂。

假设我有一个任意 JSON 对象，它可能包含任意数量的数据，包括其他嵌套的 JSON 对象。我想要的是 JSON 数据的加密哈希/摘要，而不考虑实际的 JSON 格式本身(例如:忽略 JSON token 之间的换行符和间距差异)。

最后一部分是一项要求，因为 JSON 将由许多不同平台上的各种(反)序列化程序生成/读取。我知道至少有一个用于 Java 的 JSON 库可以在反序列化期间读取数据时完全删除格式。因此它会破坏散列。

上面的任意数据子句也使事情变得复杂，因为它阻止我以给定的顺序获取已知字段并在拥有之前将它们连接起来(大致想想 Java 的非加密 hashCode() 方法是如何工作的)。

最后，将整个 JSON 字符串作为一个字节 block (在反序列化之前)散列也是不可取的，因为在计算散列时应该忽略 JSON 中的某些字段。

我不确定这个问题是否有好的解决方案，但我欢迎任何方法或想法 =)

最佳答案

在为任何允许灵 active 的数据格式计算哈希时，这个问题很常见。为了解决这个问题，您需要规范化表示。

例如，Twitter 和其他服务用于身份验证的 OAuth1.0a 协议(protocol)需要请求消息的安全哈希。要计算散列，OAuth1.0a 说您需要首先按字母顺序排列字段，用换行符分隔它们，删除字段名称(众所周知)，并为空值使用空行。签名或散列是根据该规范化的结果计算的。

XML DSIG 的工作方式相同 - 您需要在签署 XML 之前对其进行规范化。有一个proposed W3 standard covering this ，因为这是签名的基本要求。有些人称之为c14n。

我不知道 json 的规范化标准。值得研究。

如果没有，您当然可以为您的特定应用程序使用建立一个约定。一个合理的开始可能是:

• 按名称按字典顺序对属性进行排序
• 所有名称都使用双引号
• 所有字符串值都使用双引号
• 名称和冒号之间以及冒号和值之间没有空格或一个空格
• 值和以下逗号之间没有空格
• 所有其他空白都折叠成一个空格或什么都没有 - 选择一个
• 排除您不想签名的任何属性(例如，拥有签名本身的属性)
• 使用您选择的算法对结果进行签名

您可能还想考虑如何在 JSON 对象中传递该签名 - 可能建立一个众所周知的属性名称，如“nichols-hmac”或其他东西，它会获取 base64 编码版本的哈希。散列算法必须明确排除此属性。然后，JSON 的任何接收者都可以检查散列。

规范化的表示不必是您在应用程序中传递的表示。它只需要在给定任意 JSON 对象的情况下轻松生成。

https://stackoverflow.com/questions/4670494/