工作原理
URL 按形式化文法解析，各组件之间是层级关系。协议决定其余部分的解释方式；授权部分包含可选的用户信息、主机和可选端口；路径是一串分段，其含义取决于协议——对 http 和 https 它对应类似文件系统的层级，而对 mailto 或 data 则完全是另一回事；查询从第一个问号开始，片段从第一个井号开始——而片段永远不会被发送给服务端，这是一整类缺陷的根源：单页应用的路由参数对后端而言根本不可见。
查询字符串有自己的结构，而 URL 文法并未描述它。惯例是键值对以 & 分隔，但规范并不要求如此，而且同一个键完全可能合法地出现多次。各语言对此的暴露方式并不一致：PHP 取最后一次出现，Go 的 url.Values 给出整个切片，许多框架则给出数组。本工具把每一对都保留为独立行并标出重复键，而不是静默覆盖，因为服务端实际读到哪个值取决于一个语言层面的决定，你应当知道它。
百分号解码只用于展示，原始形式从不丢失。参数值 a%20b 与 a+b 在表单编码语境下是同一个值，在路径中却是不同的值，因此解码列显示可读文本，而重建 URL 时仍然使用编码后的形式。这正是让重定向参数里的嵌套 URL 变得可理解的原因：编码后的值含有自己的问号和 &，全都被转义了，解一次码就能毫无歧义地暴露真实结构。
重建是同样的规则反向应用，并顺带完成规范化。默认端口会被丢弃，主机会转为小写，对于相对输入会按你提供的基准地址解析路径，空参数会被保留而不是丢弃。结果与输入在含义上逐字节等价，形式上却是规范的——如果这个 URL 将被比较、缓存或签名，这正是你想要的；签名方案会哈希确切的字符串，因此与原串相差一个字符的“规范化”URL 会导致验签失败。
常见应用场景
- 拆解一条很长的跟踪链接，找出隐藏在重定向参数里的真实目的地。
- 修改查询字符串里的筛选条件或页码，而不必手工处理编码。
- 排查前端设置的参数为什么没有到达后端——通常是片段或未编码的 & 造成的。
- 把 URL 拆成主机与路径，用于编写防火墙规则或 CORS 配置。
- 把相对 URL 按基准地址解析，看浏览器实际会请求的绝对形式。
- 检查查询字符串是否存在重复键，因为不同框架对它的处理方式并不相同。
最后更新: 2026-10-14