URL无法以当前形式携带JSON文档。大括号、引号、空格和ASCII以上的 所有字符在进入查询字符串或路径段之前都必须进行百分比编码。
使用JSON URL编码器和解码器
选择编码或解码，粘贴您的文档，然后按转换。编码遵循与
URIComponent相同的规则：安全集之外的每个UTF-8字节都变成
%XX转义。
{"q":"a b+c","clef":"𝄞"}编码为%7B%22q%22%3A%22a%20b%2Bc%22%2C%22clef%22%3A%22%F0%9D%84%9E%22%7D，
与encodeURIComponent为相同文档生成的结果完全匹配，包括音乐
符号𝄞作为四个单独的%XX转义，因为它在UTF-8中占用四个字节。
唯一选项，以及为什么存在
启用“空格是加号”，相同文档将空格编码为+而不是%20，而数据中
已有的字面量+仍然变成%2B。这个区别就是为什么这是一个切换
而不是假设的全部原因：URL的查询字符串和表单提交对裸露+的含义
意见不一致。在表单正文中，+表示空格。在URL的任何其他部分中，
+是字面量加号。错误猜测会将数据中的每个加号变为空格，或将每个
编码的空格留为字面量加号，这是编码文档在另一端悄悄损坏的最常见
方式之一。
解码，以及为什么它在一次传递中发生
解码收集整个字符串中每个百分比转义的字节，并在最后一次性将它们
解码为UTF-8，而不是一次解码一个转义。像emoji这样的多字节字符
作为序列中的多个单独%XX转义到达，因此单独解码每个并将其视为
自己的字符会将一个emoji转换为多个替换字符。在最后解码一次是保持
多字节文本完整的方法，它还允许不是有效UTF-8的字节作为自己的
失败类型报告，这与百分比符号后没有有效十六进制数字不同，
encodeURIComponent无法自行区分。
往返过程
使用“空格是加号”编码上述示例然后解码回来，返回完全相同的原始
文档，"a b+c"和音乐符号都完整，这是加号和空格处理在两个方向
上一致的真正测试。