对json字符串签名加密，从流中来的字符串和postman上的看起来一样，但是签名加密结果不一样，为什么？

Question

我调用自己写的一个接口，传入的json字符串如下图所示：

{
    "mobileNumber":"+84883232131",
    "idNumber":"12121233"
}

我复制这个字符串，在在线HMAC-SHA1 generator网站(https://www.freeformatter.com...，对其用一个timestamp(1569327938875)做key进行签名加密，得到的结果

58782ff20de5d527c0951f97c36ce40a346c8d60

content-type是 application/json; charset=utf-8
在服务器java程序上，我通过如下获得bodyStr

    byte[] body = StreamUtil.readBytes(request.getReader(), "UTF-8");
    String bodyStr = new String(body)
    

但是调试窗口看到,程序中对bodyStr用timestamp(1569327938875)签名加密结果是tmp(b024eab123fffdcac5fae23e438de4cfbedeed63)，我copy bodyStr的value放到

MDUtil.getHmacSHA1String("{ \t\"mobileNumber\":\"+84883232131\", \t\"idNumber\":\"12121233\" }", ts)

结果是110f7161be08e239ef1f5c5026cc99c35a3f7430

总之就是三个结果，我知道字符串之间的格式可能不同，但是具体原因究竟是什么呢？
我用这个签名加密方法，如何让api调用者能够在正确的json string上进行签名加密呢？

Answer 1

内容不同，结果肯定不同…
如果是签名的话，最好还是给一个指定格式，指定参数顺序的字符串去加密
json的话，不同语言不同库不同配置，字段顺序可能不同，中间可能会多一些空格之类的都不好控制，不好做签名

Answer 2

签名验证的前提是，数据一致。
不同平台对于 \t 的定义是不一样的。在前台签名时应该使用 JSON.stringify 将对象转为普通无空格字符串。后传递至后端，如果使用 Content-Type: application/json 那么后端接收到的是对象，也应该序列化成同样的字符串进行处理。

如果你两端连基础字符串都无法确保统一，那剩下步骤根本无法进行。

其次就是排序，不同的序列化工具对于key的排序方式不一样，也会导致验证出错，这也就是为什么像微信、支付宝这些网关在签名前都要求对key进行排序，来确保参数位置的一致性。