首次准备网站时,域名和URL这两个词几乎会同时出现。它们相关但回答的是不同的问题,混淆它们会让规划变得不必要地复杂。本文通过一个假设地址,逐一展示每个部分的含义,并说明如何做一份简单的记录。

用一个假设地址来阅读

假设你正在规划一个小型个人项目,并为其中一个页面草拟了一个示例地址:https://example.org/notes/first-page?view=compact#intro。这个地址并不指向一个真实存在的页面,它只是作为一段可以被拆解和标注的字符串。在上线之前仔细阅读它,有助于理解每个部分的作用以及它们为什么在你最终搭建自己的网站时很重要。

域名是互联网基础设施的关键部分,因为它们为互联网上任何可用的网络服务器提供了人类可读的地址。计算机之间通过IP地址相互通信,而IP地址对人类来说难以记忆且可能随时间变化,因此域名通过为服务器提供一个稳定、可读的标签来解决这个问题。在我们的示例中,域名部分是example.org。1

URL是互联网上某个唯一资源的地址。域名标识的是服务器,而完整的URL标识的是该服务器上的某个特定资源,例如一个HTML页面、一张图片或一个样式表。上面的示例是一个完整的URL,因为它包含了定位某个特定资源所需的全部内容,而不仅仅是托管该资源的服务器。2

标注示例地址的各个部分

标注示例地址的各个部分,先把完整地址写在纸上或纯文本文件中:https://example.org/notes/first-page?view=compact#intro。现在逐段标记。第一段https是协议方案,它告诉浏览器请求资源时应使用哪种协议。第二段example.org是域名,同时也充当URL的主机部分。协议方案和主机共同构成了该服务器上每个页面共享的基础。21

下一段/notes/first-page是路径。URL由不同的部分组成,有些是必需的,有些是可选的,路径告诉服务器正在请求哪个资源。路径之后是一个问号,后面跟着view=compact;问号标志着查询字符串的开始,查询字符串为服务器提供额外的参数。最后,井号引出片段标识符,在本例中是intro。片段充当资源内部的书签,并且永远不会随请求一起发送到服务器。2

总结一下分隔符的规律:问号总是引出查询部分,井号总是引出片段部分。知道这两个分隔符,就能阅读任何URL并识别一个部分在哪里结束、下一个部分从哪里开始。协议方案、域名、路径、查询和片段各自承担不同的角色,能够辨认它们是自信管理自己网站地址的第一步。2

相同主机、不同路径与查询

保持示例的主机部分不变:https://example.org。现在想象同一项目上的另外两个页面。一个可能是https://example.org/gallery/photos?sort=date,另一个可能是https://example.org/notes/first-page?view=full#summary。在所有情况下,域名保持不变,但路径、查询和片段各不相同。这说明一个域名可以承载许多不同的资源,每个资源由各自的路径和可选参数的组合来标识。

注意哪些部分在变化、哪些部分保持固定。协议方案和域名构成了项目上每个地址共享的前缀。路径是从一个页面到另一个页面变化最大的部分,它指明了正在请求的具体资源。查询字符串可能存在也可能不存在;当它存在时,会在问号之后添加额外信息。片段如果存在,总是位于最后,指向资源内部的一个位置,而不是指向另一个不同的资源。

重要的是,不要仅凭字符串的外观来推断服务器实际会如何处理这些内容。两个路径不同的URL可能返回相同的内容,或者某个查询参数可能被服务器忽略。字符串的结构告诉你浏览器发送了什么,但服务器决定如何处理它。就规划而言,关键在于你能够区分字符串的每个部分并清楚地描述其角色。

为项目制作一张地址说明卡

记录一张简短的说明卡来描述这个假设项目。说明卡应包含四项内容:页面的用途、完整地址,以及各部分的标注分解。对于我们的示例,用途可能是个人笔记集合中第一篇笔记的阅读友好视图。完整地址是https://example.org/notes/first-page?view=compact#intro。分解列出协议方案为https,域名为example.org,路径为/notes/first-page,查询为view=compact,片段为intro。

这张说明卡有两个实用功能。第一,它提供了一个单一参考,无论你在文档中写到这个页面、与协作者分享,还是排查链接问题时都可以查阅。第二,填写每个字段的过程会迫使你注意到是否有某个部分缺失或不明确。例如,如果你说不出查询字符串的用途,那就是一个值得在上线前调查的信号。

选择一种适合你工作流程的格式。纯文本文件效果很好,因为以后容易复制和搜索。如果你要跟踪多个页面,电子表格中的表格也可以使用。关键是一致性:每次使用相同的字段名称,这样未来的你或团队成员可以快速浏览说明卡,而不需要重新学习你的记法。

手工核对说明卡

在依赖说明卡之前,对照实际字符串进行验证。这是一个简单的手工检查,可以捕捉拼写错误、缺失的分隔符和标注错误的部分。以下步骤是作者建议,用于培养可靠的习惯,并非来自任何外部来源的要求。

如果出现任何不匹配,先修正说明卡,然后从头重新标注一遍。缺少一个斜杠或问号放错位置这类小错误在快速阅读时很容易被忽略,所以第二遍通常能发现第一遍遗漏的问题。

检查片段标注是否与你在说明卡上写的用途一致。如果说明卡上写着片段指向引言部分,就确认片段值确实读作intro。这最后的比对闭合了地址所包含的内容与你期望它实现的功能之间的循环。

步骤 1

从说明卡中复制完整地址到一个新的空白文本行。不要凭记忆输入;使用复制粘贴,这样你验证的字符串就是你记录的那个。

步骤 2

在原地标注每个片段。在https上方写协议方案,在example.org上方写域名,在/notes/first-page上方写路径,在view=compact上方写查询,在intro上方写片段。如果有助于看清边界,可以为每个标注使用不同的颜色或括号样式。

步骤 3

将你的标注与说明卡字段逐一比较。如果说明卡上写着查询是view=compact,但字符串显示的是view=full,你就发现了一个需要在继续之前修正的差异。

保留说明供以后使用

说明卡验证完成后,把它存放在你以后真正会再看的地方。项目目录中的一个文件夹、你常用的写作工具中的一条笔记,或者维基中的一个专门页面都可以。重点不在于工具,而在于养成在撰写文档、分享链接或为同一项目规划新页面时回来看说明卡的习惯。

随着项目增长,你可能会积累多张说明卡。按一致的顺序保存它们,也许按路径字母排序,也许按网站的板块分组。当你添加新页面时,复制一张现有说明卡的格式并填入新的值。这保持整套记录统一,也让你在日后回顾时更容易发现异常。

你可能还会发现,在说明卡旁边记录自己的选择理由很有用。例如,你可以写明选择view=compact作为查询是因为想要一个精简的阅读布局,或者片段intro标记的是页面的第一个标题。这些简短的注释是个人决定而非技术要求,但它们为未来的你提供了每个选择的理由,使更新时不容易困惑。

常见问题

片段部分会被发送到服务器吗?

不会。片段标识符出现在井号之后,永远不会随请求一起发送到服务器。它由浏览器使用,在资源加载完成后滚动到资源内部的特定位置。2

一个域名可以对应多个不同的URL吗?

可以。域名标识的是服务器,而该服务器上路径、查询和片段的每一种唯一组合都构成一个不同的URL。在我们的示例中,将路径从/notes/first-page改为/gallery/photos就产生了一个不同的URL,而域名保持不变。

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

对于别人可以直接粘贴到浏览器中的完整URL,包含https等协议方案是最稳妥的选择。浏览器通常能自动补全缺失的方案,但完整写出可以消除歧义,也与说明卡中记录的格式一致。