摘要

  • 相对引用省略已由基准地址提供的方案、权威或路径信息，既减少重复，也让一组文档能够整体搬迁。
  • 解析是确定性语法变换：选定绝对基准，按引用形式继承或替换组件，合并路径，移除完整的 . 与 .. 段，再重组目标。
  • 相对引用本身不是全球稳定标识符；证据、签名和审计必须保留有效基准或解析后的绝对目标。

文档已经知道地址的一部分

绝对定位符经常重复相同方案、网络位置和大部分路径。包含这些链接的文档本身来自某处，这个位置已经提供上下文。

Tim Berners-Lee 在 1994 年提出的 RFC 1630 描述了对象自身 URI 已知时的部分形式。它不只节省字符，还让相关对象保持本地引用，在整体迁移时无需改写每条边。上层命名变化可以对下层文档隐藏。

条件同样明确：引用离开受控上下文时，应使用完整形式。短链接没有携带它省略的信息；只有基准随它一起传播，或能在阅读处被重复确定，它才可移植。

早期规则已把斜杠与完整 .、.. 段视为层级语法。末尾斜杠表示空的最后一段，因此以目录位置结尾和以资源位置结尾的基准不会借出同一条路径。

相对 URL 成为标准化变换

1995 年 6 月的 RFC 1808 把相对 URL 定义为针对绝对基准的紧凑位置。基准可以提供方案、网络位置和部分路径，引用只表达变化。

这不是字符串拼接。自带方案的引用已经绝对；自带网络位置会替换权威；以斜杠开头会从根替换路径；普通相对路径与基准末段合并；查询和片段按自己的组件规则处理。

保持局部层级的一组文档搬到新主机或前缀后，相对边会跟随新基准，绝对边则继续指向旧权威。两者声明的是不同依赖，没有一种普遍更好。

HTML 让文档携带缺失上下文

1995 年 HTML 2.0 的 RFC 1866 把相对目标用于锚点、链接、图像、输入与表单。文档脱离获取上下文时，可选的 BASE 元素能提供绝对基准。

这种便利也集中控制。一项嵌入基准就能重新解释文档中所有相对目标。正因为它避免重复前缀，改变该前缀才会影响整张依赖图。

基准不是展示元数据，而是资源身份的输入。移除、替换，或在另一阶段应用它，都在改变决策。

通用 URI 语法按组件分配继承

1998 年的 RFC 2396 把 URL 解析推广到 URI 引用。方案、权威、路径、查询和片段先被拆分，再按引用形式提供、继承或替换。

相对路径会去掉基准路径的最后一段，接上引用，再处理点段，所以末尾斜杠仍然重要。但 URI 路径并不自动等同文件系统；只有作为完整段的 . 与 .. 具有通用作用，名称内部的点仍是普通数据。

解析也不会访问服务器。它只生成目标标识符，解引用、重定向、授权和资源存在性都是后续独立决定。

现行契约先选择唯一基准

RFC 3986 要求相对引用拥有已知基准，狭窄的仅片段情形除外。基准必须是绝对 URI，且在充当基准前移除自身片段。

基准来源按优先级排列：内容内部嵌入、封装实体提供、获取 URI，再到应用默认值。这个层级把多个可能上下文压成一个有效输入。

带方案的引用提供自己的主要组件；// 形式借用方案但提供权威；一个 / 开头会借用方案与权威并替换路径；相对路径与基准除最后一段外的部分合并。若基准有权威而路径为空，则在引用路径前加 /。

空引用路径继承基准路径；若未提供查询，也继承基准查询；引用片段成为目标片段。这些是逐组件判断，不是“空文本永远不做事”。

点段是解析时指令，不是持久层级

remove_dot_segments 在路径提取和合并后运行。完整 . 不增加层级，完整 .. 在存在时移除前一输出段。过多父段按算法处理，而不是穿越某个想象中的通用文件系统根。

该变换只处理语法，不询问服务器是否存在目录。实现可以用栈代替规范中的缓冲区，但对接受的输入应得到同一重组路径。

“同一文档”也在解析后确定：比较绝对结果与基准，而不是仅凭引用表面是否很短。

可移植性是一种受控依赖

相对链接让文档集可以替换，因为内部关系不绑定单一永久主机或前缀。但它从未脱离上下文；缺失地址来自文档、容器、获取过程或应用。

只写 ../source 的来源记录一旦与原基准分开，就无法指认公共来源。只签署短文本而不签基准的清单，留下了一部分未签名目标。只记录解析结果的日志，则无法说明是哪项上下文决策产生它。

持久证据应同时保存原始引用、选定基准，以及发生动作时的解析目标。

来源

这些规范证明历史理由与解析算法，不证明今天浏览器的细节或某个应用部署的安全性。