下面的问题比最初看起来要复杂得多。
假设我有一个任意 JSON 对象，它可能包含任意数量的数据，包括其他嵌套的 JSON 对象。我想要的是 JSON 数据的加密哈希/摘要，而不考虑实际的 JSON 格式本身（例如：忽略 JSON 令牌之间的换行符和间距差异）。
最后一部分是一个要求，因为 JSON 将由许多不同平台上的各种（反）序列化器生成/读取。我知道至少有一个用于 Java 的 JSON 库可以在反序列化期间读取数据时完全删除格式。因此，它会破坏哈希。
上面的任意数据子句也使事情变得复杂，因为它阻止我以给定的顺序获取已知字段并在拥有之前将它们连接起来（粗略想想 Java 的非加密 hashCode() 方法是如何工作的）。
最后，将整个 JSON 字符串散列为一个字节块（在反序列化之前）也是不可取的，因为在计算散列时应该忽略 JSON 中的某些字段。
我不确定这个问题是否有很好的解决方案，但我欢迎任何方法或想法 =)
当为任何允许灵活性的数据格式计算哈希时，这个问题很常见。为了解决这个问题，您需要规范化表示。
例如，Twitter 和其他服务用于身份验证的 OAuth1.0a 协议需要请求消息的安全哈希。要计算散列，OAuth1.0a 说您需要首先按字母顺序排列字段，用换行符分隔它们，删除字段名称（众所周知），并为空值使用空行。签名或散列是根据该规范化的结果计算的。
XML DSIG 的工作方式相同——您需要在签署 XML 之前对其进行规范化。有一个提议的 W3 标准涵盖了这一点，因为它是签名的基本要求。有些人称之为c14n。
我不知道 json 的规范化标准。值得研究。
如果没有，您当然可以为您的特定应用程序使用建立一个约定。一个合理的开始可能是：
您可能还想考虑如何在 JSON 对象中传递该签名 - 可能建立一个众所周知的属性名称，例如“nichols-hmac”或其他东西，它可以获取哈希的 base64 编码版本。散列算法必须明确排除此属性。然后，JSON 的任何接收者都可以检查散列。
规范化的表示不需要是您在应用程序中传递的表示。它只需要在给定任意 JSON 对象的情况下轻松生成。
您可能想要使用bencode ，而不是发明自己的 JSON 规范化/规范化。从语义上讲，它与 JSON（数字、字符串、列表和字典的组合）相同，但具有加密哈希所必需的明确编码属性。
bencode 用作 torrent 文件格式，每个 bittorrent 客户端都包含一个实现。
这与导致 S/MIME 签名和 XML 签名出现问题的问题相同。也就是说，要签名的数据有多种等效表示。
例如在 JSON 中：
{ "Name1": "Value1", "Name2": "Value2" }
对比
{
"Name1": "Value\u0031",
"Name2": "Value\u0032"
}
或者根据您的应用程序，这甚至可能是等效的：
{
"Name1": "Value\u0031",
"Name2": "Value\u0032",
"Optional": null
}
规范化可以解决这个问题，但这是你根本不需要的问题。
如果您可以控制规范，那么简单的解决方案是将对象包装在某种容器中，以防止它被转换为“等效”但不同的表示形式。
即通过不签署“逻辑”对象而是签署它的特定序列化表示来避免问题。
例如，JSON 对象 -> UTF-8 文本 -> 字节。将字节签名为 bytes，然后将它们作为字节传输，例如通过 base64 编码。由于您正在对字节进行签名，因此空格等差异是签名内容的一部分。
而不是尝试这样做：
{
"JSONContent": { "Name1": "Value1", "Name2": "Value2" },
"Signature": "asdflkajsdrliuejadceaageaetge="
}
只需这样做：
{
"Base64JSONContent": "eyAgIk5hbWUxIjogIlZhbHVlMSIsICJOYW1lMiI6ICJWYWx1ZTIiIH0s",
"Signature": "asdflkajsdrliuejadceaageaetge="
}
即不签署JSON，签署编码JSON 的字节。
是的，这意味着签名不再透明。
JSON-LD可以进行规范化。
您将必须定义您的上下文。
RFC 7638：JSON Web Key (JWK) 指纹包括一种规范化。尽管 RFC7638 需要一组有限的成员，但我们可以对任何成员应用相同的计算。
我会按给定的顺序（例如按字母顺序）处理所有字段。为什么任意数据会产生影响？您可以只迭代属性（ala 反射）。
或者，我会考虑将原始 json 字符串转换为一些定义明确的规范形式（删除所有多余的格式） - 并将其散列。
我们在散列 JSON 编码的有效负载时遇到了一个简单的问题。在我们的案例中，我们使用以下方法：
使用此解决方案的优点：
缺点