跳到正文

URL 解析与参数编辑

URL Parser & Query Editor

把网址拆成各个部分,用可编辑的表格展示查询参数,改完再拼回一条完整网址。

把 URL 拆成各个部分,把查询串变成可编辑的表格,边改边重新拼出 URL。后一半是人们不知道自己需要的那一半:一个面板说明解析器悄悄改了什么,这通常就是"curl 里能用、浏览器里不能用"的答案。

🔒 完全在你的浏览器里运行urlparsequerydebug

只填主机名也行 —— 会按 https:// 补上,补了什么在下面写明。

协议

https:

主机

example.com

端口

(默认)

源

https://example.com

路径

/products/42

片段

#reviews

路径片段

  1. products
  2. 42

查询参数 (4个,其中跟踪参数 2个)

  • Google Analytics campaign source
  • Google Analytics campaign medium
  • 原文:price+desc

规范化后的 URL

https://example.com/products/42?utm_source=newsletter&utm_medium=email&id=42&sort=price%20desc#reviews

编码与解码
  • 查询串的值

    a%20b%2Fc%2Bd%26e%3Df

    所有保留字符都会转义,连 encodeURIComponent 放过的 !'()* 也不例外。空格是 %20。

  • 表单正文(application/x-www-form-urlencoded)

    a+b%2Fc%2Bd%26e%3Df

    规则一样,只是空格变成 +,所以表单值里的 + 必须写成 %2B 发出去。

  • 路径片段

    a%20b%2Fc%2Bd%26e%3Df

    斜杠不转义就会把路径切开;这里的加号就是加号,不是空格。

  • 片段(#…)

    a%20b/c+d&e=f

    URL 里最宽松的部分:? / : @ 等等不转义也合法。

  • 整个 URL(encodeURI)

    a%20b/c+d&e=f

    保留起结构作用的字符。只有当输入真的是一整个 URL 时才对。

URL 只在这个页面里解析,从不发出请求。不会去取,也不会跟随重定向,所以带会话令牌或签名链接的地址就留在这个标签页里。

怎么用

  1. 粘贴 URL

    只输入主机也接受,默认补上 https://——这个假设会被报告出来而不是藏起来。data: URL 会被描述而不是解析。

  2. 按行编辑查询参数

    十五个追踪参数挤在一行里没法读,拆成十五行一目了然。追踪参数按名字标出,一个按钮全部去掉。

  3. 读解析器改了什么

    转成小写的主机名、转成 punycode 的国际化域名、被归一掉的 .. 段——全都悄无声息,在你粘贴的 URL 里看不见,全都能让同一个字符串在两个客户端里表现不同。

  4. 签名对不上时用编码面板

    同一个字符串按每一种编码规则同时显示。查询值里的加号和路径段里的加号编码方式不同,并排看到两者才能看出这一点。

常见问题

会抓取这个 URL 吗?

不会。它在页面里解析,从不请求——不抓取,不跟随重定向。带会话令牌或签名的链接留在这个标签页里。

去掉 utm_ 参数安全吗?

对目的页面来说安全——这些是分析工具读的,不是应用读的。例外是参数带签名、或页面确实需要其中某个 id 的链接,所以分享前看一眼剩下了什么。

"编码了两次"是什么意思?

这个值经过了两个各自好心做百分号编码的系统,所以 %2520 是一个空格先变成 %20、然后它的 % 又被编码了一次。这是重定向目标到达时已经损坏的常见原因。

我的大写主机名为什么变成了小写?

主机名不区分大小写,URL 标准会把它归一。路径不会——/Page 和 /page 是不同的资源——所以 URL 只有一半变了。

可以从这些接进来

接下来

这些工具吃得下当前工具的产出,结果可以直接送过去。