URL 参数解析器 - 在线 Query String 工具

1. 怎么用

1. 粘贴完整 URL（或直接粘贴 ?a=1&b=2 这样的查询串）。
2. 工具把参数拆成键值表，逐行编辑 key 和 value。
3. 新增或删除参数、调整顺序，上方实时生成新的完整 URL，一键复制。

2. 典型场景

• 调试 API：把长查询串拆开，定位哪个参数传错，改完直接复制新 URL 重试。
• 埋点与跳转链：拼接带多个参数的回调地址时，可视化表格比手拼字符串不容易漏 & 和 =。
• 对照文档逐个核对参数名和取值，比在地址栏里肉眼数强得多。

3. 一个高频疑问：值要不要编码

表格里展示的是解码后的可读值，生成 URL 时工具负责正确编码。这意味着你在 value 里直接写中文、空格、& 或 = 都不会破坏参数结构——这正是手拼 URL 最常翻车的地方。如果某个参数的值本身就是一段 URL（回调场景），保持它作为整体值填入即可，编码由工具统一处理。

4. 重复键与数组参数的语义分岔

查询串里表达数组有两种流派：重复键（a=1&a=2，RFC 3986 本义）与括号后缀（a[]=1&a[]=2，PHP/Rails 约定）。发送端选错流派，接收端就解析不出数组——跨团队联调时这经常表现为「服务端只收到最后一个值」。本工具按重复键语义展示数组，并在检测到 a[] 形态时提示这是接收端约定。另一个分岔是空值三态：a=（空串）、a（无等号，URLSearchParams 里值是空串）、以及键不存在（null）——三种在业务判断里意义不同。

5. 操作参数后的编码陷阱

• searchParams.set 会自动编码值，但直接拼接 search 字符串不会——混用两种方式改参数，编码态会不一致。
• 对已编码字符串再调 set 会二次编码（%20 变 %2520）：先 decode 再交给 API 管理。
• 删除参数用 searchParams.delete 后必须重新赋值（url.search = url.searchParams），旧引用不会自动同步。

6. 签名串、追踪参数与「改完打不开」

带签名的跳转链接（支付回调、SSO、CDN 鉴权）通常把 query 的规范化字符串纳入 HMAC：你改动任意参数名、值、顺序或编码风格，签名立即失效。排查时应先在本工具里看清有哪些键，再回到业务文档确认「参与签名的字段集合」与「排序规则」，而不是凭感觉删 utm_ 参数。反之，纯营销追踪参数（utm_source 等）一般不进签名；删它们只影响归因，不影响鉴权——先分清链接属于哪一类，再动手。

7. 从表格改回 URL 后的人工核对

• 复制前扫一眼键名是否被误改（大小写敏感的签名字段最常见）。
• 空值三态不要凭感觉补等号：业务若区分「缺键」与「空串」，表格里删行 vs 留空值含义不同。
• 回调 URL 作为某个 value 时，确认它在表格里仍是单行值，而不是被 & 拆成多个键。
• 需要百分号细节时，把生成结果丢进 URL 编码工具做 peel，确认没有意外双重编码。