URL 解析器

关于 URL 解析器

拿到一条长长的地址需要拆解时就会用到它：排查「参数没传到后端」要看清查询串到底解析成了哪几个键值、对接第三方回调要确认路径与查询串的分界、分析推广链接要取出全部跟踪参数、写爬虫前要确认相对地址如何与基地址拼接。手工数斜杠与问号既慢又容易出错，交给解析器几秒钟就能得到结构化的结果。 解析原理基于 URL 标准：一条地址被拆成协议、主机、端口、路径、查询串与片段六部分，其中查询串再按与号分隔成键值对，片段（井号之后的部分）不会发送给服务器。理解这个结构能直接解释很多现象——例如井号之后的内容永远不出现在服务端日志里，这就是单页应用早期用井号做路由、以及某些统计参数写在井号后必然失效的原因。 使用要点：先区分绝对地址与相对地址，相对地址必须配合基地址才能解析，否则会得到错误结果；路径里的百分号编码需要解码才能看到真实的目录名，但要小心解码后的斜杠会改变路径层级，做安全判断时应先解码再校验、而不是先校验再解码。查询串里同一个键出现多次在标准中是合法的（例如多选筛选），用「转成对象」的方式解析会丢掉重复项，需要保留全部值时应解析成键值对数组。此外加号在查询串里表示空格，这一点与路径不同。 边界与限制：URL 标准（WHATWG）与早期的 RFC 3986 在若干细节上不一致，例如反斜杠的处理、空前缀的路径归一化、以及用户名与口令出现在主机之前时的解析方式，不同语言与浏览器可能给出不同结果；如果解析结果用于安全判断（域名白名单、重定向目标校验），必须使用与目标运行时一致的实现，或干脆不依赖解析而是用白名单固定目标。国际化域名在展示时是 Unicode、传输时是 punycode（形如 xn-- 前缀），做域名比对前必须统一形式，否则会把同一个域名判成两个。还有一类坑是端口与默认端口的等价性：显式写出的默认端口与省略写法在字符串上不同但语义相同，比对时需归一化。 数据与隐私：要解析的地址常带签名参数、访问令牌、会话标识或用户身份信息，分享出去等于泄露访问权。本工具在浏览器内完成解析与解码，不请求任何服务，也不会上传地址；排查完成后如果地址里带令牌，建议顺手在服务端轮换一次。

在日志分析里，把请求地址解析成结构化字段后按主机与路径聚合，能快速看出爬虫与真实用户的比例、以及哪些接口在被高频调用；做重定向安全校验时，则应按「先解码、再比较」的顺序，并且比较归一化之后的形式（统一小写主机名、去掉默认端口、把 punycode 与 Unicode 统一），否则精心构造的绕过地址会通过白名单。解析结果建议直接落成结构化记录，避免下游再次用字符串截取，减少二次误判。