查询字符串转 JSON:把 ?a=1&b=2 解析成对象的完整方法

每次我在浏览器 DevTools 的 Network 面板里盯着一长串 ? 后面的参数,都得眯着眼一个一个数 & 符号。一段稍微复杂的链接，肉眼读起来又慢又容易看漏。把它转成 JSON 对象之后，结构一下子就立体了:哪个键有值、哪个键是空的、哪个键出现了两次，全摆在面上。这篇就把查询字符串(query string)到 JSON 的转换讲透。

查询字符串到底是什么

一个 URL 里 ? 后面那段就是查询字符串。它的结构非常简单:整段先按 & 切成一个个键值对，每个键值对再按第一个 = 拆成 key 和 value。比如 ?a=1&b=2，按 & 分成 a=1 和 b=2 两段，每段拆开就是 key a 配 value 1、key b 配 value 2，组装起来就是 JSON 对象 {"a": "1", "b": "2"}。

注意一个细节:value 里本身可能含 =(比如 base64 结尾的 ==)，所以只按第一个 = 拆，后面的 = 留给 value。这是手写解析最容易写错的地方。

一个真实的输入输出例子

拿 ?name=tom&age=20 来说，转成 JSON 是这样:

{
  "name": "tom",
  "age": "20"
}

这里有个坑要先点破:age 的值是字符串 "20"，不是数字 20。查询字符串没有类型概念，一切都是文本。如果工具自作主张把它猜成数字，遇到前导零(007)或者超大整数就可能悄悄把数据改坏。所以默认保留字符串，后端真要数字，解析完自己转一次最稳妥。

百分号编码和 + 号空格

查询字符串里不能直接放空格和特殊字符，于是有两套转义:%XX 百分号编码，以及历史遗留的 + 代表空格。解析时这两套都要还原。name=Ada+Lovelace 应该读成 Ada Lovelace，q=%E4%BD%A0%E5%A5%BD 应该解码成 你好。反过来生成查询字符串时，每个值要用 encodeURIComponent 重新编码，空格输出成 %20，这是认得最广的安全形式。来回转一遍数据不能坏，这是判断一个转换工具靠不靠谱的硬指标。如果只想单独编解码一段文本，可以用 /zh/t/url-encoder/ 这个更专一的工具。

重复参数:同名键变数组

这是手写解析最容易丢数据的地方。tag=red&tag=blue 里 tag 出现了两次，如果简单地往对象里塞，后一个会盖掉前一个，red 就没了。正确的做法是同名键合并成数组:

{
  "tag": ["red", "blue"]
}

只出现一次的键保持普通字符串，出现多次的才升级成数组。这跟 PHP、Rails、qs 这些库用的是同一套约定。还有 list[]=x&list[]=y 这种带方括号的写法，约定上也是数组。再进一步，user[name]=ada 和 user[address][city]=oslo 这种嵌套方括号，可以展开成真正的多层对象，这在解析框架生成的复杂请求时特别管用。

日志分析和调试里的实际用法

我自己用得最多的是排查跳转丢参数。登录跳转本应带着 ?return_to=/dashboard&plan=pro&promo=WELCOME，但用户落地后没有 promo。把服务器实际产生的 URL 转成 JSON，跟预期 URL 的 JSON 并排比，缺哪个键一眼就看出来。如果 promo 的值变成了 WELCOME%2F，那就是双重编码问题，重新编码后的输出会让它无所遁形。

日志分析也是同理。日志里一行行带着查询字符串的访问记录，逐个转成结构化 JSON 后，就能进一步喂给别的处理流程。如果你拿到的是一整批 URL 想批量审计，/zh/t/url-query-params-extractor/ 更合适，它一次吃很多链接、出一张扁平表格。而单条查询字符串要拆成可编辑的 JSON 树、改完再拼回去，就用 /zh/t/query-string-to-json/ 这个双向转换工具。

小结

查询字符串转 JSON 的核心就三步:按 & 拆键值对、按第一个 = 分 key 和 value、把同名键合并成数组。再叠上百分号解码、+ 号空格、嵌套方括号这几个约定，就能覆盖绝大多数真实场景。处理过程全在浏览器本地跑，带 token 或签名跳转的字符串不会外泄。下次再面对一长串看不懂的参数，别再手数 & 了。

---

Made by Toolora · Updated 2026-06-13