• 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html
  • 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html

了解 Web 及网络基础(1.6)URI 和 URL

极客笔记 Geekerstar 10个月前 (06-14) 294次浏览 已收录 0个评论 扫描二维码
文章目录[隐藏]

与 URI(统一资源标识符)相比,我们更熟悉 URL(Uniform Resource Locator,统一资源定位符)。

URL 正是使用 Web 浏览器等访问 Web 页面时需要输入的网页地址。

比如,下图的 https://www.jikewenku.com/ 就是 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(统一资源标识符方案)

URI 用字符串标识某一互联网资源,而 URL 表示资源的地点(互联网上所处的位置)。

可见 URL 是 URI 的子集。

“RFC3986:统一资源标识符(URI)通用语法”中列举了几种 URI 例子,如下所示。

接下来的章节中会频繁出现 URI 这个术语,在充分理解的基础上,也可用 URL 替换 URI。

1.7.2 URI 格式

表示指定的 URI,要使用涵盖全部必要信息的绝对 URI、绝对 URL 以及相对 URL。

相对 URL,是指从浏览器中基本 URI 处指定的 URL,形如 /image/logo.gif。

让我们先来了解一下绝对 URI 的格式。

使用 http: 或 https: 等协议方案名获取访问资源时要指定协议类型。

不区分字母大小写,最后附一个冒号(:)。

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

登录信息(认证)

指定用户名和密码作为从服务器端获取资源时必要的登录信息(身份
认证)。

此项是可选项。

服务器地址

使用绝对 URI 必须指定待访问的服务器地址。地址可以是类似jikewenku.com 这种 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 是互联网的设计文档,要是不按照 RFC 标准执行,就有可能导致无法通信的状况。

比如,有一台 Web 服务器内的应用服务没有遵照RFC 的标准实现,那 Web 浏览器就很可能无法访问这台服务器了。

由于不遵照 RFC 标准实现就无法进行 HTTP 协议通信,所以基本上客户端和服务器端都会以 RFC 为标准来实现 HTTP 协议。

但也存在某些应用程序因客户端或服务器端的不同,而未遵照 RFC 标准,反而将自成一套的“标准”扩展的情况。

不按 RFC 标准来实现,当然也不必劳心费力让自己的“标准”符合其他所有的客户端和服务器端。

但设想一下,如果这款应用程序的使用者非常多,那会发生什么情况?

不难想象,其他的客户端或服务器端必然都不得不去配合它。

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

说不定它们会与本书介绍的 HTTP 协议的实现情况不一样。

接下来要介绍的 HTTP 协议内容,除去部分例外,基本上都以RFC 的标准为准。


丨极客文库, 版权所有丨如未注明 , 均为原创丨
本网站采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行授权
转载请注明原文链接:了解 Web 及网络基础(1.6)URI 和 URL
喜欢 (0)
[247507792@qq.com]
分享 (0)
Geekerstar
关于作者:
本站技术支持

您必须 登录 才能发表评论!

  • 精品技术教程
  • 编程资源分享
  • 问答交流社区
  • 极客文库知识库

客服QQ


QQ:2248886839


工作时间:09:00-23:00