image.png

image.png

我们可以把因特网当作一个巨大的正在扩张的城市，里面充满了各种可看的东西，
可做的事情。你和其他居民，以及到这个正在蓬勃发展的社区旅游的游客都要为这
个城市大量的景点和服务使用标准命名规范。博物馆、饭店和家庭住址要使用街道
地址，消防局、老板的秘书，以及抱怨你太少打电话给她的母亲要使用电话号码。
所有的东西都有-一个标准化的名字，以帮助人们寻找城市中的各种资源。书籍有
ISBN号，公交车有线路号，银行账户有账户编码，个人有社会保险号码。明天，
你要到机场的31号出口去接你的生意伙伴。每天早上你都要乘坐红线火车，并在
Kendall广场站出站。
所有人都对这些名字的标准达成了-致，所以才能方便地共享这座城市的宝藏。你
告诉出租车司机把你载到McAllister大街246号，他就知道你是什么意思了(即使
他走的是- -条很远的路)。
URL就是因特网资源的标准化名称。URL 指向每- - 条电子信息，告诉你它们位于何
处，以及如何与之进行交互。
本章，我们将介绍以下内容:
●URL 语法，以及各种URL组件的含义及其所做的工作:
●很多Web客户端都支持的URL快捷方式，包括相对URL和自动扩展URL;
●URL编码和字符规则，
●支持各种因特网信息系统的常见URL方案;
●URL的未来，包括URN一这种框架可以在对象从--处搬移到另--处时，保持
稳定的访问名称。

2.1浏览因特网资源

URL是浏览器寻找信息时所需的资源位置。通过URL，人类和应用程序才能找到、
使用并共享因特网上大量的数据资源。URL是人们对HTTP和其他协议的常用访问
点:一个人将浏览器指向一个URL，浏览器就会在幕后发送适当的协议报文来获取
人们所期望的资源。
URI是一类更通用的资源标识符，URL实际上是它的一个子集。URI是-一个通用的
概念，由两个主要的子集URL和URN构成，URL是通过描述资源的位置来标识资
源的，而URN (本章稍后会介绍)则是通过名字来识别资源的，与它们当前所处位
置无关。.
HTTP规范将更通用的概念URI作为其资源标识符，但实际上，HTTP应用程序处
理的只是URI的URL子集。本书有时会不加区分地使用URI和URL，但我们讲的
基本上都是URL。

比如说，你想要获取URL http://www.joes-hardware.com/seasonal/index-fall.html。
那么URL分以下三部分。
●URL 的第一- 部分(http) 是URL方案(scheme)。 方案可以告知Web客户端怎
样访问资源。在这个例子中，URL说明要使用HTTP协议。
●URL 的第二部分(www.joes-hardware.com) 指的是服务器的位置。这部分告知
Web客户端资源位于何处。
●URL 的第三部分(/seasonal/index-fall.html) 是资源路径。路径说明了请求的是
服务器上哪个特定的本地资源。
对此的说明请参见图2-1。

image.png

2.2 URL的语法

URL提供了--种定位因特网上任意资源的手段，但这些资源是可以通过各种不同的
方案(比如HTTP、FTP、SMTP)来访问的，因此URL语法会随方案的不同而有
所不同。
这是不是意味着每种不同的URL方案都会有完全不同的语法呢?实际上，不是的。
大部分URL都遵循通用的URL语法，而且不同URL方案的风格和语法都有不少重叠。
大多数URL方案的URL語法都建立在込个由9部分杓成的通用格式上:

<8cheme> ://<usero:cpassword>@<host>:cport>/ <path> ;<params>? query>#<frag>

几乎没有啣个URL中包含了所有込些組件。URL最重要的3个部分是方案(scheme) 、
主机(host)和路径(path)。 表2-1対各神組件迸行了息結。

image.png

2.2.1方案

使用什么协议
方案实际，上是规定如何访问指定资源的主要标识符，它会告诉负责解析URL的应用
程序应该使用什么协议。在我们这个简单的HTTP URL中所使用的方案就是http.
方案组件必须以-一个字母符号开始，由第一个“:”符号将其与URL的其余部分分
隔开来。方案名是大小写无关的，因此URL“http://www.joes-hardware.com” 和
“HTTP://www.joes-hardware.com”是等价的。

2.2.2主机与端口

要想在因特网上找到资源，应用程序要知道是哪台机器装载了资源，以及在那台机
器的什么地方可以找到能对目标资源进行访问的服务器。URL的主机和端口组件提
供了这两组信息。
主机组件标识了因特网上能够访问资源的宿主机器。可以用上述主机名(www.joes-
hardware.com)，或者IP地址来表示主机名。比如，下面两个URL就指向同一个资
第一个URL是通过主机名，第二个是通过IP地址指向服务器的:
http://www.joes-hardware.com: 80/index.html
http://161.58.228.45:80/index.html
端口组件标识了服务器正在监听的网络端口。对下层使用了TCP协议的HTTP来
说，默认端口号为80。

2.2.3 用户名和密码

更有趣的组件是用户和密码组件。很多服务器都要求输入用户名和密码才会允许用
户访问数据。FTP服务器就是这样-一个常见的实例。这里有几个例子:
ftp://ftp.prep.ai.mit.edu/pub/gnu
ftp://anonymous @ ftp.prep.ai.mit.edu/pub/gnu
ftp://anonymous:my_ passwd @ ftp.prep.ai.mit.edu/pub/gnu
http://joe:joespasswd@ www .joes-hardware.com/sales info.txt
第一个例子没有用户或密码组件，只有标准的方案、主机和路径。如果某应用程
序使用的URL方案要求输入用户名和密码，比如FTP,但用户没有提供，它通常
会插入一个默认的用户名和密码。比如，如果向浏览器提供一个FTP URL，但没
有指定用户名和密码，它就会插入anonymous (匿名用户)作为你的用户名，并发
送一个默认的密码(Internet Explorer会发送IEUser, Netscape Navigator则会发送
mozilla)。
第二个例子显示了-一个指定为anonymous的用户名。这个用户名与主机组件组合在
一起，看起来就像E-mail地址--样。字符“@"将用户和密码组件与URL的其余
部分分隔开来。
在第三个例子中，指定了用户名(anonymous) 和密码(my _passwd)，两者之间由
字符“:” 分隔。

2.2.4 路径

URL的路径组件说明了资源位于服务器的什么地方。路径通常很像-一个分级的文件
系统路径。比如:
http://www.joes-hardware.com:80/seasonal/index-fall.html
这个URL中的路径为/seasonal/index-fall.html,很像UNIX文件系统中的文件系统
路径。路径是服务器定位资源时所需的信息。2可以用字符“1”将HTTPURL的路
径组件划分成- -些路径段(path segment) (还是与UNIX文件系统中的文件路径类
似)。每个路径段都有自己的参数(param) 组件。

2.2.5 参数

对很多方案来说，只有简单的主机名和到达对象的路径是不够的。除了服务器正在
监听的端口，以及是否能够通过用户名和密码访问资源外，很多协议都还需要更多,
的信息才能工作。
负责解析URL的应用程序需要这些协议参数来访问资源。否则，另--端的服务器可
能就不会为请求提供服务，或者更糟糕的是，提供错误的服务。比如，像FTP这样
的协议，有两种传输模式，二进制和文本形式。你肯定不希望以文本形式来传送二
进制图片，这样的话，二进制图片可能会变得- -团糟。
为了向应用程序提供它们所需的输入参数，以便正确地与服务器进行交互，URL 中
有一个参数组件。这个组件就是URL中的名值对列表，由字符“;” 将其与URL的
其余部分(以及各名值对)分隔开来。它们为应用程序提供了访问资源所需的所有
附加信息。比如:
ftp://prep.ai.mit.edu/pub/gnu;type=d
在这个例子中，有一一个参数type=d,参数名为type,值为d。
如前所述，HTTP URL的路径组件可以分成若干路径段。每段都可以有自己的参:
数。比如:
http://www joes-hardware.com/hammers;sale=false/index.html;graphics: =true
这个例子就有两个路径段，hammers 和index.html。hammers 路径段有参数sale,其值
为false。index.html 段有参数graphics，其值为true。

2.2.6 查询字符串

很多资源，比如数据库服务，都是可以通过提问题或进行查询来缩小所请求资源类
型范围的。
假设Joe的五金商店在数据库中维护着-一个未售货物的清单，并可以对清单进行查
询，以判断产品是否有货，那就可以用下列URL来查询Web数据库网关，看看编
号为12731的条目是否有货: .
http://www. joes-hardware.com/inventory-check.cgi?item=12731
这个URL的大部分都与我们见过的其他URL类似。只有问号(?)右边的内容是
新出现的。这部分被称为查询(query) 组件。URL的查询组件和标识网关资源的
URL路径组件--起被发送给网关资源。基本上可以将网关当作访问其他应用程序的
访问点(第8章会对网关进行详细的讨论)。
图2-2中有一一个作为Joe的五金商店清单查询应用程序的网关的服务器，在这个
例子中向此服务器发送了一个查询组件。查询的目的是检查清单中是否有尺寸为
large、颜色为blue的条目12731。

image.png

2.2.7 片段

有些资源类型，比如HTML，除了资源级之外，还可以做进一一步的划分。比如，对
一个带有章节的大型文本文档来说，资源的URL会指向整个文本文档，但理想的情
况是，能够指定资源中的那些章节。
为了引用部分资源或资源的一个片段，URL支持使用片段(frag) 组件来表示-一个
资源内部的片段。比如，URL可以指向HTML文档中一个特定的图片或小节。
片段挂在URL的右手边，最前面有一个字符“#”。 比如:
http://www joes-hardware.com/tools.html#drills
在这个例子中，片段drills引用了Joe的五金商店Web服务器上页面/tools.html中的一
个部分。这部分的名字叫做drills。
HTTP服务器通常只处理整个对象，3而不是对象的片段，客户端不能将片段传送给
服务器(参见图2-3)。浏览器从服务器获得了整个资源之后，会根据片段来显示你
感兴趣的那部分资源。

image.png

2.3 URL快捷方式.

Web客户端可以理解并使用几种URL快捷方式。相对URL是在某资源内部指定-一
个资源的便捷缩略方式。很多浏览器还支持URL的“自动扩展”，也就是用户输入
URL的一个关键(可记忆的)部分，然后由浏览器将其余部分填充起来。2.3.2 节
对此进行了解释。

2.3.1 相对URL
URL有两种方式:绝对的和相对的。到目前为止，我们只见过绝对URL。绝对
URL中包含有访问资源所需的全部信息。
另一方面，相对URL是不完整的。要从相对URL中获取访问资源所需的全部信息，
就必须相对于另-一个，被称为其基础(base) 的URL进行解析。
相对URL是URL的一种便捷缩略记法。如果你手工写过HTML的话，可能就会发
现相对URL是多么便捷了。例2-1是一个嵌入了相对URL的HTML文档实例。

image.png

例2-1是资源:
http://www .joes-hardware.com/tools.html
的HTML文档。
在这个HTML文档中有-一个包含了URL ./hammers.html 的超链接。这个URL看起
来是不完整的，但实际上是个合法的相对URL。可以相对于它所在文档的URL对
其进行解释;在这个例子中，就是相对于Joe的五金商店Web服务器的资源/tools.
html。

2.4 各种令人头疼的字符

URL是可移植的(portable)。 它要统- -地命名因特网上所有的资源，这也就意味着
要通过各种不同的协议来传送这些资源。这些协议在传输数据时都会使用不同的机
制，所以，设计URL,使其可以通过任意因特网协议安全地传输是很重要的。
安全传输意味着URL的传输不能丢失信息。有些协议，比如传输电子邮件的简单邮
件传输协议(Simple Mail Transfer Protocol, SMTP)，所使用的传输方法就会剥去

• -些特定的字符。4为了避开这些问题，URL只能使用一些相对较小的、通用的安
  全字母表中的字符。
  除了希望URL可以被所有因特网协议进行传送之外，设计者们还希望URL是可读
  的。因此，即使不可见、不可打印的字符能够穿过邮件程序，从而成为可移植的，
  也不能在URL中使用。5
  URL还得是完整的，这就使问题变得更加复杂了。URL的设计者们认识到有时人们
  可能会希望URL中包含除通用的安全字母表之外的二进制数据或字符。因此，需要
  有一种转义机制，能够将不安全的字符编码为安全字符，再进行传输。
  本节总结了URL的通用字母表和编码规则。

2.5 方案的世界

本节将介绍更多Web常用方案格式。附录A给出了一个相当完整的方案列表，及
各种方案文档的参考文献。

image.png

image.png

2.6 未来展望

URL是一种强有力的工具。它可以用来命名所有现存对象，而且可以很方便地包含
一些新格式。URL还提供了一种可以在各种因特网协议间共享的统-命名机制。
但URL并不完美。它们表示的是实际的地址，而不是准确的名字。这就意味着
URL会告诉你资源此时处于什么位置。它会为你提供特定端口上特定服务器的名
字，告诉你在何处可以找到这个资源。这种方案的缺点在于如果资源被移走了，
URL也就不再有效了。那时，它就无法对对象进行定位了。

如果有了对象的准确名称，则不论其位于何处都可以找到这个对象，那该多完美啊。
就像人一样，只要给定了资源的名称和其他一些情况，无论资源移到何处，你都能
够追踪到它。
为了应对这个问题，因特网工程任务组(Internet Engineering Task Force, IETF)
已经对- -种名为统一资 源名(uniform resource name, URN)的新标准做了一段时
间的研究了。无论对象搬移到什么地方(在-一个Web服务器内或是在不同的Web
服务器间)，URN都能为对象提供-一个稳定的名称。
永久统一-资源定位符(persistent uniform resource locators, PURL)是用URL来实
现URN功能的一个例子。其基本思想是在搜索资源的过程中引入另-一个中间层，
通过-一个中间资源定位符(resource locator)服务器对资源的实际URL进行登记和
跟踪。客户端可以向定位符请求-一个永久URL，定位符可以以一一个资源作为响应，
将客户端重定向到资源当前实际的URL上去(参见图2-6)。更多有关PURL的信
息，请访问http://purl.oclc.org.

image.png

如果不是现在，那是什么时候
URN背后的思想已经提出一段时间了。实际上，如果去看看某些相关规范的发布日
期，你可能会问，为什么它们现在都还没有投入使用。,
从URL转换成URN是一项巨大的工程。标准化工作的进程很缓慢，而且通常都有
很充分的理由。支持URN需要进行很多改动-一标准主体的一致性，对各种HTTP
应用程序的修改等。做这种改动需要进行大量的工作，而且很不幸(或者可能很幸
运)的是URL还有很大的能量，还要等待更合适的时机才能进行这种转换。
在Web爆炸性增长的过程中，因特网用户一包括从计算机科学家到普通因特网用
户的每-一个人一都已经学会 使用URL了。在备受笨拙语法(对新手来说)和顽固
问题困扰的同时，人们已经学会了如何使用URL，以及如何对付它们的一些缺陷。
URL有一些限制，但这并不是Web开发社区所面临的最紧迫的问题。
目前看来，在可预见的未来，因特网资源仍然会以URL来命名。它们无处不在，而
且是Web的成功过程中-一个非常重要的部分。其他命名方案想要取代URL还要一
段时间。但是，URL确实有其局限型，可能会出现新的标准(可能就是URN),对
这种标准进行部署会解决其中的某些问题。