1.7 URI 和 URL

​ 与URI（统一资源标识符）相比，我们更熟悉URL（Uniform Resource Locator，统一资源定位符）。URL 正是使用 Web 浏览器等访问 Web 页面时需要输入的网页结构。比如，http://hackr.jp/ 就是URL

1.7.1 统一资源标识符

​ URI 是 Uniform Resource Identifier 的缩写。RFC2396 分别对这 3 个单词进行了如下定义。

Uniform

规定统一的格式可方便处理多种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式。另外，加入新增的协议方案（如 http: 或 ftp: ）也更容易

Resource

资源的定义是“可标识的任何东西”。除了文档文件、图像或服务（例如当天的天气预报）等能够区别于其他类型的，全都可作为资源。另外，资源不仅可以是单一的，也可以是多数的集合体。

Identifier

表示可标识的对象。也称为标识符。

---

综上所述，URI 就是某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。

​ 采用 HTTP 协议时，协议方案就是 http。除此之外，还有 ftp、mailto、telnet、file等。标准的 URI 协议方案有 30 种左右，由隶属于国际互联网资源管理的非盈利社团 ICANN（Internet Corporation for Assigned Names and Numbers，互联网名称与数字地址分配机构）的 IANA （Internet Assigned Numbers Authority，互联网号码分配局）管理颁布。

• IANA - Uniform Resource Identifier （URI）SCHEMES（统一资源标识符方案）
  http://www.iana.org/assignments/uri-schemes

URI 用字符串标识某一互联网资源，而 URL 标识资源的地点（互联网上的位置）。可见 URL 是 URI 的子集。

“RFC3986：统一资源标识符（URI）通用语法”中列举了几种 URI 例子，如下所示。

ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:John.Doe@example.com
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2

1.7.2 URI 格式

​ 表示指定的URI，要使用涵盖全部必要信息的绝对 URI、绝对 URL 以及相对 URL 。相对 URL，是指从浏览器中基本 URI处指定的 URL ，形如 /image/logo.gif。

​ 使用 http: 或https: 等协议方案名获取资源时要指定协议类型。不区分字母大小写，最后附一个冒号（ : ）

​ 也可使用data: 或 javascript: 这类指定数据或脚本程序的方案名

登录信息（认证）

指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。此项是可选项。

服务器地址

使用绝对 URI 必须指定待访问的服务器地址。地址可以是类似 hackr.jp 这种 DNS 可解析的名称，或是 192.168.1.1 这类 IPv4 地址名，还可以是[0:0:0:0:0:0:0:1] 这种用方括号括起来的 IPv6 地址名。

服务器端口名

指定服务器连接的网络端口号。此项也是可选项，若用户省略则自动使用默认端口号。

带层次的文件路径

指定服务器上的文件路径来定位特指的资源。这与 UNIX 系统的文件目录结构相似。

查询字符串

针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数。此项可选。

片段标识符

使用片段标识符通常可标记出已获取资源中的子资源（文档内的某个位置）。但在 RFC 中并没有明确规定其使用方法。该项也为可选项。

---

并不是所有的应用程序都符合 RFC

​ 有一些用来制定 HTTP 协议技术标准的文档，它们被称为 RFC（Request for Comments，征求修正意见书）。

​ 通常，应用程序会遵照有 RFC 确定的标准实现。可以说， RFC是互联网的设计文档，钥匙不按照 RDC标准执行，就有可能导致无法通信的状况。比如，有一台 Web 服务器内的应用服务没有遵照 RFC 的标准实现，那 Web 浏览器就很可能无法访问这台服务器。

​ 由于不遵照 RFC 标准实现就无法进行 HTTP 协议通信，所以基本上客户端和服务器端都会以 RFC 为标准来实现 HTTP 协议。但也存在某些应用因客户端或服务器端的笔筒，而未遵照 RFC 标准，反而将自成一套的“标准”扩展的情况。

​ 不按 RFC 标准来实现，当然也不必劳心费力让自己的“标准”符合其他所有的客户端和服务器端。但设想一下，如果这款应用程序的使用者非常多，那会发生什么情况？不难想象，其他的客户端或服务器端必然都不得不去配合它。

​ 实际在互联网上，已经实现了 HTTP 协议的一些服务器端和客户端里就存在上述情况。

​