当你第一次准备网站时,地址栏里那串字符看起来像一整段标签。实际上它由几个不同的部分组成,每个部分回答不同的问题。本文用一个假设地址来展示这些部分是什么,以及你如何在上线前把它们记录清楚。

域名与完整URL分别回答什么问题

假设你正在规划一个小型个人项目,在便签上写下了地址 https://example.org/notes/first-page?view=compact#intro。这个字符串完全是假设的,不需要对应任何真实存在的页面。首先要注意的是,这个字符串包含两层信息,分别回答不同的问题。域名部分 example.org 标识你想访问互联网上的哪台服务器。域名之所以存在,是因为计算机使用数字形式的IP地址,而人很难记住这些数字,所以需要一个人类可读的名称作为该数字地址的别名。12

完整URL回答的是一个更具体的问题:浏览器应该从该服务器上获取哪一个特定资源?URL是互联网上某个唯一资源的地址,它包含域名以及指向特定页面、文件或页面内某个位置的其他部分。换句话说,域名带你到达正确的建筑,而URL的其余部分告诉浏览器该进哪个房间、看哪个书架。3

对于第一次建站的人来说,这个区分很重要,因为在搭建项目时你会同时遇到这两个术语。当别人问你的域名时,他们只指主机部分。当别人问某个具体页面的URL时,他们期望得到包含路径、查询和片段的完整字符串。从一开始就把这两个概念分开,能避免之后分享链接或填写配置表单时产生混淆。

在本例中标出地址的各个部分

回到假设字符串 https://example.org/notes/first-page?view=compact#intro,从左到右阅读。第一段 https 是协议方案,它告诉浏览器请求资源时应使用哪种协议。对于普通网站,协议方案是HTTPS或其未加密版本HTTP,浏览器知道如何处理这两种。3

在协议方案和分隔符 :// 之后,下一段是 example.org。这是域名,也称为主机名,它标识将处理请求的Web服务器。在这个假设示例中,主机部分在整个练习过程中保持不变,只有它后面的部分会发生变化。13

/notes/first-page 这一段是路径,它指向服务器上的一个特定资源。路径后面的问号引导查询字符串,在这里是 view=compact。查询参数是键值对,在服务器返回资源之前向其提供额外指令。最后,井号引导片段标识符,在本例中是 intro。片段的作用类似于资源内部的书签,它指引浏览器定位到页面中的某个特定位置,而不是指向另一个不同的资源。3

保持主机不变,对比不同路径与查询

现在保持主机 example.org 和协议方案 https 不变,设想两个变体。第一个是原始字符串 https://example.org/notes/first-page?view=compact#intro。第二个是 https://example.org/notes/second-page?view=full。两者的主机完全相同,但路径不同:一个指向 first-page,另一个指向 second-page。查询也不同:一个携带 view=compact,另一个携带 view=full。第二个变体完全没有片段。

将这两个字符串并排观察,你可以发现:改变路径会产生一个不同的地址,指向同一服务器上的不同资源位置。改变查询会产生一组随请求传递的不同指令。去掉片段则意味着没有指定页内书签。这些观察都不能告诉你服务器实际上会如何处理每个变体,它们只描述字符串本身所传达的信息。

这种区分在上线前很有用,因为你可能需要为不同目的分享不同的链接。在通讯中分享的链接可能包含一个设定首选显示模式的查询参数,而嵌入文档中的链接可能包含一个让读者跳转到特定标题的片段。识别你正在改变字符串的哪个部分,能帮助你向协作者准确描述差异。

为假设项目制作地址说明卡

记录一张简短的说明卡,在公开分享任何链接之前完成。说明卡不需要很复杂,一个纯文本块或笔记应用中的表格就足够了。至少记录三件事:用一句话说明页面目的、你希望地址呈现的完整形式、以及地址各部分的简短标签。

以本文使用的示例为例,说明卡可以这样写:目的是以紧凑视图显示项目笔记的第一页,并滚动到引言部分。完整地址是 https://example.org/notes/first-page?view=compact#intro。协议方案是 https。主机是 example.org。路径是 /notes/first-page。查询是 view=compact。片段是 intro。每个标签直接对应字符串中的一个段落,阅读说明卡的人可以看出每个部分的作用。

把说明卡存放在你实际会回看的地方,比如项目的 readme 文件或共享文档中。说明卡的价值不在于格式,而在于明确命名每个部分的习惯。当协作者之后问为什么某个链接和他们预期的不一样时,你可以指向说明卡并指出哪个段落发生了变化。

通过复制与标记核对说明卡

检查你的说明卡是否与实际字符串一致,方法是执行一次手动复制与标记练习。这一步能发现拼写错误和标签错位,而这些问题在只是匆匆一瞥地址时很容易被忽略。

以下练习是作者建议,不是任何工具或标准的要求。根据你的项目需要调整遍数即可。

如果在任何一遍中发现不匹配,先修正说明卡,然后从该步骤的开头重新执行该遍。不要只修补你注意到的那一个字符,重新阅读完整段落以确保附近没有第二个错误。

步骤 1

从说明卡中将完整地址复制到一个空白文本文件中。不要凭记忆重新输入,使用粘贴操作以确保字符与你记录的内容完全一致。

步骤 2

在复制出的字符串中用可见的分隔符标记每个边界。在协议方案前、主机后、路径前、问号处和井号处分别放置空格或方括号。结果应该看起来像一个分段列表,而不是一个连续的字符串。

步骤 3

将每个分段逐一与说明卡上的标签进行对比。确认协议方案标签与协议方案文本匹配,主机标签与主机文本匹配,依此类推直到片段。

保留这份记录供日后参考

将完成的说明卡与其他项目文档存放在一起,这样在你撰写公告、更新链接或引入新协作者时仍然可以方便地访问。说明卡充当一个共享参考点:与其把一长串URL粘贴到聊天消息中让别人猜测哪部分重要,不如直接引用已标注的段落。

选择一个与你项目已有信息组织方式匹配的存储位置。如果你维护一个 readme 文件,就把说明卡作为靠近开头的一个简短小节添加进去。如果你使用任务看板,就把它附在上线检查清单项上。具体工具不如把说明卡放在地址相关问题实际会出现的上下文中这个决定重要。

随着时间推移,你可能为同一个项目添加更多地址。每个新页面或变体都可以按照相同格式获得自己的说明卡。在多张说明卡之间保持一致的结构,使得直接比较两个地址并准确识别哪个段落不同变得简单,无需每次从头解析字符串。

常见问题

如果我只改变URL中的片段,是否指向不同的页面?

不是。片段标识的是同一资源内部的书签位置。改变片段会让浏览器定位到该资源内的不同位置,但本身并不表示服务器上的另一个页面或文件。3

分享地址时是否需要包含协议方案?

在日常分享中,大多数浏览器会在你省略协议方案时自动补全。不过在说明卡上记录完整的协议方案可以消除歧义,尤其是当地址出现在浏览器之外的纯文本环境中时。

查询字符串可以包含多个参数吗?

可以。查询参数是以与号分隔的键值对。一个URL可以携带多个参数,每个参数在服务器返回资源之前向其提供一条单独的额外信息。3