URL Anatomy · 一条网址是怎么拆开的
日常见到的 https://shop.example.co.uk:8443/cart?id=42#top,其实是 scheme · userinfo · host · port · path · query · fragment 七块拼起来的。本系列把它逐段拆开,并且全程不手写正则 —— 解析依靠浏览器内置的 URL / URLSearchParams,host 里「注册域名 vs 公共后缀」这件 URL 接口不负责的事,交给带 Public Suffix List 的 tldjs。
每节都可修改输入、查看真实运行结果(底层即 new URL(...) 与 tld.parse(...) 当场运行得出)。
拆解一条 URL:从 URI 到 slug
一条信息最全的 URL 拆成 scheme·userinfo·host·port·path·query·fragment 七段;host 再拆三段;query 串、percent-encoding、slug 各成一节。全程用原生 URL / URLSearchParams,不手写正则。
扩展:nanoid——path 里那段「机器读的 id」
当资源没有适合派生 slug 的标题、或需要不透出内部信息的随机 id 时用 nanoid:现场跑 crypto.getRandomValues 生成,看它为何天生 URL 安全、熵与碰撞概率如何估算、为什么默认字母表取 64。
相关链接
-
URL Standard
WHATWG
当代权威规范:定义了
URL/URLSearchParams接口、解析算法、各组成部分的归一化规则。浏览器实现的依据。 -
whatwg-url
github.com/jsdom
对应「URL 拆解」节:用纯 JavaScript 完整实现 URL Standard 的库 —— 高层暴露
URL/URLSearchParams,底层暴露 parser / URL record / serializer 等规范内部算法。浏览器已内置URL时无需它;它服务于 jsdom 这类需要在纯 JS 环境实现规范本身(而非仅使用)的项目。 -
RFC 3986 · Uniform Resource Identifier (URI)
IETF
URI 通用语法的原始 RFC:
scheme://authority/path?query#fragment这套分段、percent-encoding、相对引用解析都源自这里。 -
MDN · URL / URLSearchParams
developer.mozilla.org
对应「URL 拆解」「query 串」两节:每个属性(
origin/host/search…)与方法的逐项说明、浏览器兼容性。 -
Can I use · URL API
caniuse.com
对应「URL 拆解」节:
URL构造器与各属性的实时浏览器支持矩阵。URLSearchParams另见 caniuse · URLSearchParams。 -
MDN · encodeURIComponent
developer.mozilla.org
对应「percent-encoding」节:列明
encodeURI与encodeURIComponent各自不编码的字符集合,并给出补齐!'()*的fixedEncodeURIComponent标准补丁。 - What's a slug? Dave Sag · ITNEXT 对应「扩展:slug」节:slug 的定义、在 API 路由 / SEO / 日志 / seed 数据里的用处、本地化时为何保持稳定,以及「好 slug」的判据。本节内容即脱胎于此。
-
slugify
github.com/simov
对应「扩展:slug」节:成熟的 JS slugify 库 —— 比本页的纯 ASCII 流水线多了一张转写表(把
&→and、各国文字罗马化),能更好处理非拉丁标题。其他语言对应实现:Pythonun33k/python-slugify、Gomozillazg/go-slugify等。 -
nanoid
github.com/ai
对应「扩展:nanoid」页:极小(压缩约 130 字节)、用
crypto随机源、URL-friendly 的唯一 id 生成器。本页的核心算法、64 字符默认字母表、掩码 + rejection 的无偏映射均与其实现一致;碰撞概率可参考其 README 链接的 collision calculator。