解析json字符串时，取消unicode自动解码

[cloud-jie]

String json = "{\"message\": \"\\u4f60\\u597d\"}";
System.out.println(JSON.parse(json));

输出结果：{"message":"你好"} 期待的结果：{"message": "\u4f60\u597d"}

根据文档，https://alibaba.github.io/fastjson2/features_cn.html JSONReader.Feature根本没有对应取消解码unicode的实现

我之前有提过，但您一直没有回复，可能是没有看到，所以我关闭了之前的问题，提出了这个问题。

[wenshao]

这个是非JSON标准，为什么要有这个需求？

[MoshiCoCo]

这个是非JSON标准，为什么要有这个需求？

有些API接口，会对请求体做签名验证签名操作。写客户端业务的时候都会先转成json obj，然后对某些字段拼接，并且进行验签操作，此时客户端拿到的结果是 你好，服务端签名使用的原始文本是是 \u4f60\u597d ，此时就会出现签名验证不一致的情况。我觉得这个需求还是有必要的。

[ForgottenR]

这个是非JSON标准，为什么要有这个需求？

有些API接口，会对请求体做签名验证签名操作。写客户端业务的时候都会先转成json obj，然后对某些字段拼接，并且进行验签操作，此时客户端拿到的结果是 你好，服务端签名使用的原始文本是是 \u4f60\u597d ，此时就会出现签名验证不一致的情况。我觉得这个需求还是有必要的。

既然提到服务端的“原始文本”应该是指请求的响应体吧？这种情况下是服务端序列化逻辑有问题啊，如果原始文本是 “\u4f60\u597d”那么服务端把它转换为json的时候应该按照json的逻辑做escaping，客户端收到的就不应该是“你好”。听起来像是服务端用拼接的逻辑做了序列化，这是不正确行为啊……

[wenshao]

同意 @ForgottenR 的看法，这个是非标准不合理的需求，fastjson2不应该做这样的功能

[MoshiCoCo]

这个是非JSON标准，为什么要有这个需求？

有些API接口，会对请求体做签名验证签名操作。写客户端业务的时候都会先转成json obj，然后对某些字段拼接，并且进行验签操作，此时客户端拿到的结果是 你好，服务端签名使用的原始文本是是 \u4f60\u597d ，此时就会出现签名验证不一致的情况。我觉得这个需求还是有必要的。

既然提到服务端的“原始文本”应该是指请求的响应体吧？这种情况下是服务端序列化逻辑有问题啊，如果原始文本是 “\u4f60\u597d”那么服务端把它转换为json的时候应该按照json的逻辑做escaping，客户端收到的就不应该是“你好”。听起来像是服务端用拼接的逻辑做了序列化，这是不正确行为啊……

是这样的，确实是不正确的行为，但是在实际的业务实践中，此类问题发生的概率还是比较高的。 我遇到此类问题一般是先要求服务商改，服务商有时候不改的时候（有时候很难推动他们改），就自己单独处理来自此服务商的响应。