1次下午输给了一个看起来还不错的URL,一个OAuth回调一直失败,重定向URI "匹配"那个在提供者注册的,看不出为什么握手会坏掉,答案,当我最后把东西粘贴到解析器里,一个地方路径上的尾随斜线,另一个地方没有,再加上一个 state 参数已被双编码 %20 已经成为 %2520。对人眼来说两个网址是相同的,对OAuth服务器来说是不同的字符串,拒绝不匹配是对的。
URL的问题就在于此:它们很密集,很容易被误读,而破坏事物的细节- 编码的斜杠,杂散端口,重复的查询密钥,你期望路径的片段- 正是隐藏在字符墙中的我构建了[toolz。dev](/,而且我在调试时花了足够的时间盯着查询字符串,我构建了一个 网址解析器 做盯着我看。粘贴一个链接,让每个被标记的组件和每个被解码的查询参数都放在一个表中。本指南解释了那些组件是什么,为什么区别很重要,以及如何使用它们。
TL;博士: URL是由一个方案构成的(
https),可选凭证(user:pass@),一个主机(example.com)与可选端口,路径(/blog/post),一个查询字符串(?id=42),以及一个片段(#section)。 X 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 100 = 网址解析器 使用浏览器将任何链接分割成这些部分'自己的 WHATWG URL 引擎,将查询解码为有序的键值表(重复的键保持分开),显示该方案的有效端口,并假设https://paste一个裸域的话。它完全在你的浏览器中运行,所以与令牌的链接保持私密。
网址的部分是什么？
URL都遵循相同的语法,由WHATWG URL标准定义 - 规范浏览器实际上实现,一旦你能命名零件,大多数URL错误就会变得明显,这里是完整的解剖结构,使用一个故意忙碌的例子:
https://john:[email protected]:8443/catalog/shoes?color=red&size=42#reviews
└─┬─┘ └──┬──┘└─┬──┘└──────┬────────┘└─┬─┘└──────┬──────┘└──────┬──────┘ └──┬──┘
scheme user pass hostname port path query fragment
打破这个:
| 组件 | 示例值 | 它是什么 |
|---|---|---|
| 计划 | https |
的协议。决定默认端口以及如何提出请求。 |
| 用户名 | john |
可选凭证,之前 @。 |
| 密码 | s3cret |
可选凭证,之后 : 在用户信息中。 |
| 主机名 | shop.example.co.uk |
域或 IP 地址,无端口。 |
| 港口 | 8443 |
Optional。省略时会回落到方案默认值。 |
| 主持人 | shop.example.co.uk:8443 |
当存在端口时,主机名加端口。 |
| 起源 | https://shop.example.co.uk:8443 |
方案加主机 - 用于安全的单位浏览器。 |
| 路径 | /catalog/shoes |
主机上的资源位置。 |
| 查询 | ?color=red&size=42 |
键值参数之后 ?。 |
| 片段 | #reviews |
之后的客户端锚 #的, 从未发送到服务器。 |
Parser 将这些中的每一个都作为自己的行放置一个复制按钮,所以你再也不用从怪物 URL 中手工提取主机名了,它还标记了原始字符串隐藏的几件事:显示的端口是显式的还是方案'的默认值,以及主机是命名域还是原始 IP。
主机名、主机和源的区别是什么？
这三个人不断地往上走,混乱导致了真正的错误--CORS 故障、cookie 范围界定错误、重定向不匹配。它们不是同义词。 WHATWG URL 标准 是定义浏览器实际实现,它是解决关于什么算作起源的争论的地方。
主机名 是只是域或IP: shop.example.co.uk、没有端口,没有方案,这是你会在DNS查找中放的。
主持人 是主机名加上端口, 但仅当 URL 中存在端口时.为了 shop.example.co.uk:8443 主持人是 shop.example.co.uk:8443.对于平原 https://shop.example.co.uk/ host 和 hostname 相同,因为默认端口 443 是隐含的而不是写入的。that "只有当存在"规则是微妙的,也是为什么同一个站点可以看起来有两个不同的主机。
起源 是方案加主机: https://shop.example.co.uk:8443。这是浏览器最关心的一个,因为同源策略- Web安全的基础- 比较源,而不是主机名。两个URL共享一个源只有当他们的方案,主机名, 並 端口全部匹配。 http://example.com 並 https://example.com 是不同的起源,因为方案不同。 https://example.com 並 https://example.com:8443 是不同的起源,因为端口不同,即使主机名相同。如果获取失败,CORS 错误,在解析器中并排比较两个起源通常是发现不匹配的最快方法。
如何解析查询字符串？
查询字符串是大多数日常疼痛的所在,因为它是一个扁平的、看起来没有逃避的 blob,实际上是结构化的和百分比编码的。解析器为您分割:之后的一切 ?,断开 &、与每个 key=value 对解码并按原始顺序列在表格中。
2种行为在这里很重要,首先, 解码。写成 的参数 q=trail%20runner 电线上显示为 trail runner 在值列中,因为 %20 是一个百分比编码的空间。原始的 search string 仍然显示在组件列表中未触及,因此您可以比较编码和解码的形式 - 当您怀疑双重编码时非常宝贵,就像我的 %2520 OAuth 错误。
第二, 重复键。一个网址可以合法地携带同一密钥不止一次: ?tag=react&tag=typescript&tag=node。许多天真的解析器会崩溃这些,只保留第一个或最后一个值,并默默地丢失数据。那是错误的 - 重复键是 HTML 表单如何提交多选字段以及大量 API 如何表达数组。解析器将每次出现都保留为自己的行,按顺序,因此您将所有三个标签都看到。当您将查询复制为 JSON 时,重复键变成数组,这是大多数代码期望的形状。
URL都不需要完整的URL就可以使用这个,只粘贴一个查询字符串- color=red&size=42 - 而且工具会自行解析它,这是我所知道的最快方法,可以理解 webhook 有效负载或有人转发给您的跟踪链接。
如何使用 URL 解析器?
该工具旨在让开您的方式。将 URL 粘贴到单个输入中,并在输入时实时解析 - 无需按下按钮。预加载示例链接,以便您可以立即看到完整的分解,并且清除按钮会清空字段。
您不必键入该方案。像这样粘贴裸主机 example.com/pricing 解析器在前面 https:// automatic,然后用小纸条告诉你它这么做了,所以你永远不会对方案来自哪里感到困惑粘贴显式方案- http://、 ftp://、 ssh:// - 相反,它尊重这一点。
输出有四个区域。在顶部, 标准化 URL - 规范形式浏览器's引擎制作,带复制按钮,方便抓取细微规范化差异,下面,the 组件 table,每部分一个被标记的行,每个可以独立复制。然后 路径段,分解成索引芯片,所以是一条很深的路径 /api/v2/users/42/orders 一眼就看得懂了。最后 查询参数 表格,解码并排序,带有 "复制为 JSON"将整个查询变成干净对象的操作。
Everything 使用其原生 URL 引擎在您的浏览器中运行。那是一个刻意的选择:URL 通常包含访问令牌、会话 ID、签名参数和内部主机名,这些都不应运送到服务器上只是为了读取。您粘贴的任何内容都不会离开您的设备,并且该工具会保持离线工作。它是整个工具包背后相同的隐私优先方法,我在 2017 年 12 月 12 日 讨论过 web开发人员工具包指南。
我什么时候可以访问 URL 解析器?
在我自己的工作中,一些情况一次又一次地出现。 调试重定向和回调 是最大的一个 - OAuth流,支付返回URL,SSO握手,所有这些都失败了微小的不匹配,只有当你分解两个URL时才可见。 审计跟踪链接 是另一个:营销网址通常是一个基页加上十几个UTM和广告平台参数,当作表格阅读它们胜过斜视300个字符的字符串,如果你正在构建那些链接而不是阅读它们, 中海外空建设者 是同一工作流程的另一半。
然后是 API 工作 - 检查客户端实际发送的查询参数,或对端点期望其过滤器的方式进行逆向工程。和 安全审查:电子邮件或日志中的陌生链接通过解析其部分(主机执行此操作)来理解要安全得多 真的 point at?那台主机名是ip吗?)比点它解析器曝光真主机名并标记ip-literal主机,这正是你在信任链接之前想要的信息,我写的更多关于在里面组装这种检测试剂盒 API调试工具指南。
解析与编码和slugs有何关系?
URL解析器是一个链接工具小家族的一个角落,知道你需要哪一个可以节省时间。解析 读 现有的 URL 并将其拆开。 编码 在字符级别上做相反的方向 - 将空格和特殊字符转换为百分比编码形式,以便它们在 URL 内保存,然后再返回。当您需要将值安全地嵌入到查询字符串中,或解码被破坏的值时,即 URL编码器/解码器并且它与解析器自然配对:解析以查看结构,编码以修复损坏的值。
Slug一代 是第三项相关的工作 - 采用像 " 10 个更快构建技巧 " 这样的人类头衔并将其变成干净的 10-tips-for-faster-builds 路径段。这就是什么 Slug 生成器 手柄,这就是整洁的产生 path component 解析器后来读回。把它当作一个管道: slugify 构建好的路径,编码使值 URL 安全,解析检查完成的链接。每个工具都执行 URL 生命周期的一部分,并在浏览器中执行。
IP地址和国际化域呢?
并非每个主人都很整洁 example.com。有些 URL 指向原始 IP 地址,解析器识别这两种形式。 IPv4 字面意思是 http://192.168.1.10:3000/ 有主机名 192.168.1.10(intern),并且该工具将其标记为 IP 而不是域 - 当您正在审核链接并希望立即知道它针对的是指定站点还是裸地址时,这很有用,这是可疑链接中常见的信号。IPv6 字面值被包裹在 URL 中的方括号中,如 http://[2001:db8::1]:8080/并且括号是主机语法的一部分,而不是装饰;解析器正确处理括号内的形式,而不是扼住冒号,否则冒号看起来像端口分隔符。
国际化域名是另一种边缘情况。用非 ASCII 字符编写的主机(例如带有重音字母或非拉丁字母的域)由浏览器's URL 引擎转换为其 Punycode xn-- 实际请求的表单,因为 DNS 只说 ASCII。看到标准化 href in 解析器中向您准确地展示了浏览器将解析的内容,这偶尔会让那些期望自己的漂亮 Unicode 域保持不变的人感到惊讶,对于顶级域,解析器提取命名主机的最终标签,因此 shop.example.co.uk 报告 TLD uk。那是一个故意简单的规则- 它不会像那样尝试解开多部分后缀 .co.uk into 可注册域,因为正确地做到这一点需要公共后缀列表,这是一个大型移动数据集,为了快速检查,最后一个标签是有用的信号,对于任何更严格的东西,您将达到专用库。
1个工作例把它绑在一起,说一个支付提供商一直拒绝你的退货网址,你注册了 https://app.example.com/checkout/return 但失败的请求显示 https://app.example.com:443/checkout/return/。解析两者。解析器显示第一个有主机 app.example.com (默认端口,路径上没有尾随斜杠),第二个有主机 app.example.com 也--但它的路径是 /checkout/return/ 带有尾部斜杠,其端口明确写为 :443。两个差异眼睛滑过,两者都是致命的精确匹配检查,一旦你可以看到它们作为单独的标记组件,修复是显而易见的:标准化尾部斜杠和掉落冗余显式端口。
URL时常见的错误
反复出现的错误值得命名。 将片段与路径或查询混淆 - 一切之后 # 是片段,它完全由浏览器处理,永远不会发送到服务器,所以你放了一个参数 # 不会到达您的后端。 假设缺失端口意味着没有端口 - 省略的端口意味着该方案 默认 (https 为 443,http 为 80),解析器会明确说明这一点,以便您知道请求真正会击中哪个端口。
忽略双编码 - 如果一个值看起来像 %2520 代替 %20,它被编码了两次;解析它,如果解码的值仍然包含百分比序列,则再次解码。 信任链接的可见文本 - 您看到的文本和实际的文本 href can完全不同,这是钓鱼背后的整个机制;解析揭示了真正的目的地主机。和 将重复的查询键视为要丢弃的重复项 - 它们通常是有意义的数组,丢弃它们会丢失数据。
常见问题
网址的部分是什么？
URL 具有一个方案 (HTTPS)、可选凭证 (user:pass@)、具有可选端口的主机 (example.com)、路径 (/blog/post)、可选查询字符串 (?id=42) 和可选片段 (#section)。 此解析器分隔和标记每一个。
如何解析查询字符串？
URL 完整粘贴并读取查询表,或者只粘贴查询字符串本身,解析器将其拆分在安培数上,对百分比编码进行解码,并按顺序列出每个键值对,重复的键如 tag=a&tag=b 保留为单独的行。
主机名、主机和源的区别是什么？
Hostname只是域或IP(例网),主机在有时加端口(例网:8443),起源是方案加主机(https://example.com:8443的),并且是浏览器用于同源安全检查的内容。
当 URL 没有端口号时，使用什么端口？
方案决定。 HTTPS 默认为 443，HTTP 为 80，SSH 为 22，FTP 默认为 21。 此解析器显示有效端口并将其标记为默认端口，因此您知道请求将实际使用哪个端口。
解析器是否解码百分比编码字符？
是的,对于查询值。表中显示 name=John%20Doe 这样的参数解码为 "John Doe"。原始搜索字符串也显示为未触及的,因此您可以比较编码和解码的形式。
我可以在不输入https部分的情况下解析网址吗？
是的。 如果您粘贴裸主机或路径，例如 example.com/pricing，解析器会自动添加 https:// 并注意它假设了该方案。 明确粘贴一个方案，例如 http:// 或 ftp:// 以覆盖该假设。
为什么我的网址无法解析？
通常主机丢失或格式错误，方案写错，或字符串包含在 URL 中非法且未被百分比编码的字符。 检查方案后是否有空格、未转义的括号或缺少的斜线。
用令牌或会话 ID 粘贴 URL 是否安全？
是的。 使用其本机 URL 引擎在浏览器中完全运行解析。 链接永远不会发送到服务器，从未记录过，也从未存储过，因此包含访问令牌、API 密钥或内部主机名的 URL 将保留在您的设备上。
