关于JSON解析时 Unicode U+2028 等字符的bug - WXOPEN Club

概述

wx.request 对于含有 U+2028 等字符的 Response Body 存在错误的过度处理（注意：该问题只在真机上复现）。

经过查找文章和社区，我发现这是一个反馈较多的问题（参见最后“可能的相关问题”部分），对于特殊字符很多人选择了进行过滤，但这是不对的，正确的做法应当是对其进行合理编码、解码。

JSON对特殊字符的处理

在详细描述bug之前，我们先了解下JSON处理中特殊字符的正确处理方式。

在 ECMAscript 5.1 （ https://www.ecma-international.org/ecma-262/5.1/#sec-15.12.2 ）中有这样一句话：

JSON uses a more limited set of white space characters than WhiteSpace and allows Unicode code points U+2028 and U+2029 to directly appear in JSONString literals without using an escape sequence.

这意味着 JSON.stringify 和 JSON.parse 都不应当对空格、U+2028、U+2029这三个字符进行转义，例如对于空格：

可以看到空格未进行转义，同样的道理，U+2028 也不会被转义：

但对于 ‘\n’ ，是需要转义的：

因此可以得出结论，在HTTP Response中 U+2028 等字符是不应当被转义的；由于这两个字符被创造也是有其含义和目的，更不应当被过滤掉（如 <https://developers.weixin.qq.com/community/develop/doc/8d93389c3bea4acff6e7bb765c3e634f?highLine=2028>>> 和 <<<FLOATING LINK: https://developers.weixin.qq.com/community/develop/doc/f085c4b5f547113dbb032d0f4b46e1b5> ）

wx.request 的问题

在 wx.request 对JSON的处理中，没有正确将 JSON String 解析为 Object，而是将 String进行了返回，同时将 U+2028 和 U+2029 两个字符替代成了 \n 。在这一过程中存在如下问题：

假设wx.request处理JSON异常，应当触发fail回调函数传递具体的错误，给用户明确的意图，而不是调用 success 给出未能成功解析的字符串。（举一个例子，JSON.parse 结果并不一定是Object，如 http://www.mocky.io/v2/5bea7d792f0000df0bda3a4e 这个接口在浏览器用fetch调用返回的就是字符串）。
wx.request应当能正常处理含有U+2028 等字符的Response，应当原样保留这些特殊字符并反馈 JSON.parse 出的结果
但是通过调试可以发现，wx.request对U+2028 等字符进行了错误的处理，在返回的 String 中将其替换成了 \n （注意不是 \\n，前者是一个字符，后者是两个字符），这进一步导致了用户难以通过 JSON.parse 手动解析String数据：