摘要:无方案方案是规定如何访问指定资源的主要标识符。比如指定文档中的某个章节。编码机制通过转义表示法,表示不安全字符。表示一台指定主机上可以直接访问的文件,省略主机名则默认为本机由定义,访问特定的文章或者新闻组。
URL概览
前面提到,URL资源是HTTP协议所使用的寻找资源位置的定位符。分为三个部分,主要的结构是:
方案://服务器/路径
这种结构使得网络上的每一个资源都只有唯一的命名方法,从而使得浏览器可以统一对不同的资源进行处理,而不是依赖不同的软件。
URL可以从以下几个部分去了解:
语法
快捷方式
特殊字符
方案
最后,我们还会展望未来,看看URN——URL的下一代。
URL语法是跟对方案而变化的,但是这些变化总是建立在URL语法的9个组件组成的通用格式之上的。这个通用格式是:
:// : @ : / ; ? #
这9个组件不需要全部包含,其中重要的三个部分是之间提到的:方案、主机 和 路径。其可总结如下:
方案 | 描述 | 默认值 |
---|---|---|
方案 | 使用的协议 | 无 |
用户 | 某些方案访问资源时要求的用户名 | 匿名 |
密码 | 在用户名之后,中间以冒号:隔开 | |
主机 | 服务器的主机名或者点分IP地址(如192.168.1.1) | 无 |
端口 | 服务器监听的端口,HTTP默认端口为80 | 方案特有 |
路径 | 服务器的资源本地名,路径组件语法和服务器、方案相关 | 无 |
参数 | 使用该组件指定输入参数。参数为名/值对,用分号隔开 | 无 |
查询 | 用于激活应用程序,没有通用格式 | 无 |
片段 | 部分资源名称,引用时不会传递给服务器,只使用于客户端内部。 | 无 |
方案
方案是规定如何访问指定资源的主要标识符。要求以字母开始,用:隔开URL其余部分,且大小写无关。
主机和端口
主机标志能访问资源的服务器。主机可以使用主机名或者IP地址来访问;端口则标识服务器监听的网络端口,默认为80。
用户名和密码
多用在FTP服务器上。如果URL方案要求提供用户名和密码,而用户没有输入,则应用程序会插入一个默认的用户名和密码,随浏览器而定
路径
其说明资源在服务器中的位置,是服务器定位资源时需要的信息,用/将路径划分为路径段(path segment),路径段还有各自的参数组件。
参数
服务器需要更多的信息,而不是简单的主机名和路径,而URL中的参数组件可以提供更多的协议参数。该组件是名值对列表,每个路径段可以有多个参数,形式类似:
http://www.baidu.com/pub/gnu;type=sb【并不存在,请勿当真】
这里的路径段gnu参数为type,值为sb。
查询字符串
用于缩小请求资源类型范围。如本专栏撰写时,网址为:
http://segmentfault.com/write?freshman=1
其中的freshman=1就是查询组件。我猜测,这个查询组件的意思是:在服务器的write路径中,是否一直保存着我的文章的草稿。查询组件会发送给网关,由网关做进一步处理。如果需要多个名值对,则使用&字符进行分割。
片段
HTML资源除了资源级,还可以进一步划分。比如指定文档中的某个章节。而这个就可以使用#
这个快捷方式是针对客户端的,可以分为相对URL和URL自动拓展。
相对URL前面提到的都是绝对URL,包含访问资源所需要的全部信息。而相对URL则是不完整的,必须相对另一个作为基础(base)的URL进行解析。这种便捷的缩略法为写网页的人省了不少心。如下面的HTML代码片段:
其中的问答、文章等超链接都是http://segmentfault.com/a/1190000004341687#articleHeader6为基础URL,从而推导出方案和主机名。
所以,相对URL优势有二:
可以保持HTML文档的可读性和书写便捷。
可以保持网页上一组资源的便携性。、
比如,可以在搬移一组文档时,保持链接的有效性。这样,就可以方便的搭载镜像服务器了。
使用相对URL的步骤有二:一是找出基础URL;二是解析相对引用。
找出基础URL
基础URL来源有二:一是网页显式指定,如在HTML网页中,使用
解析相对引用
对URL进行转换,需要将相对URL和基础URL划分成组件段,或者说“分解(decomposing)”。解析完URL后,可以获得一个个组件,根据相对URL的完整程度,逐步对其进行填充,直到组合成新的绝对URL。这个填充是使用的是一个在RFC2396中定义的算法。
浏览器会为用户提供一条捷径,使得用户不需要输入完整的URL,而交给浏览器填充。其方式有二:主机名拓展和历史拓展。
主机名拓展
根据主机名进行拓展,找到匹配站点则构建成功;失败则再次尝试其他可能。但是这种拓展可能会为一些其他HTTP应用程序(如代理)带来问题。
历史拓展
根据用户访问过的历史URL进行拓展,该拓展通过选择来完成。
为了保障URL的可移植性(即使用任何因特网协议都可以安全传输)和完整性,URL需要:
使用通用的安全字母表
对不可见字符进行编码以传送
包含不安全的字符
为了实现这点,URL使用了通用字母表,并增加了一些编码规则。
URL字符集URL中继承了ASCII字符集和转义序列,使得其可以使用优先子集对任意字符值进行编码。
编码机制通过“转义”表示法,表示不安全字符。其包含一个百分号(%)和两个表示字符ASCII码的十六进制数。示例如下:
字符 | ASCII码 | 示例URL |
---|---|---|
~ | 0x7E | http://www.joes-hardware.com/%7Ejoe |
(空格) | 0x20 | http://www.joes-hardware.com/more%20tools.html |
% | 0x25 | http://www.joes-hardware.com/100%25satisfaction.html |
在URL中,字符会因为有特殊含义、非ASCII可打印字符或者混淆协议和网关而被限制。下面是一些被限制的字符:
字符 | 保留/受限 |
---|---|
% | 保留为转义标志 |
/?#:; | 保留为定界符 |
. | 保留在路径组件中使用 |
.. | 同上 |
$+ | 保留(不需要理由) |
@&= | 在不同的方案的上下文中有特殊含义,保留 |
{}[]~^"| | 用于各种传输Agent代理,使用受限 |
<>" | 不安全,在URL范围之外是有意义的,需要进行编码 |
0x00-0x1F,0x7F | 受限,因为是不可打印字符 |
0x7F | 受限,因为不在US-ASCII字符集的7二进制位范围之内 |
对于不安全字符,最好进行编码。而判断是否进行编码则由从用户处获取URL的源端应用来做。URL中,可能有人故意对额外的字符进行编码,从而绕过对URL进行模式匹配的应用。所以,解释URL的应用必须在处理URL之间进行编码。
下面是Web常用方案的一些格式:
方案 | 描述 |
---|---|
http | 超文本传输协议。没有用户名和密码,除此之外符合通用URL,端口默认为80. |
https | 与http相对使用了网景的SSL,为HTTP提供端到端的加密机制,端口默认为443 |
mailto | 指向E-mail地址。标准格式与URL格式不同,其语法记录在RFC822中。 |
ftp | 文件传输协议、要求用户名和密码,可以上传、下载文件,并获取其目录结构内容 |
rtsp,rtspu | 通过实时流传输协议解析的多媒体资源标识符。除了方案部分,其余同上。 |
file | 表示一台指定主机上可以直接访问的文件,省略主机名则默认为本机 |
news | 由RFC036定义,访问特定的文章或者新闻组。其自身包含的信息不足以对资源进行定位,其实际上与位置无关,只保留字符@来区分指向新闻组和指向新闻文章的URL |
telnet | 访问交互式业务,表示可以通过telnet访问的交互式应用程序 |
实际上,由于URL表示的实际的地址,所以在资源被移动以后,无法定位对象。所以,下一代标准URN(统一资源名)开始研究,通过一个永久统一资源定位符PURL,使用URL实现URN的功能。可以在PURL中获取更多信息。
最后的彩蛋,猜猜这个是哪个网页的源代码?
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/49732.html
摘要:其中负载均衡那一节,基本上是参考的权威指南负载均衡的内容。开发指南读了一半,就是看这本书理解了的事件循环。哈哈创京东一本骗钱的书。 欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由腾讯IVWEB团队 发表于云+社区专栏作者:link 2014年一月以来,自己接触web前端开发已经两年多了,记录一下自己前端学习路上看过的,以及道听途说的一些书,基本上按照由浅入深来介绍...
摘要:其中负载均衡那一节,基本上是参考的权威指南负载均衡的内容。开发指南读了一半,就是看这本书理解了的事件循环。哈哈创京东一本骗钱的书。 欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由腾讯IVWEB团队 发表于云+社区专栏作者:link 2014年一月以来,自己接触web前端开发已经两年多了,记录一下自己前端学习路上看过的,以及道听途说的一些书,基本上按照由浅入深来介绍...
摘要:其中负载均衡那一节,基本上是参考的权威指南负载均衡的内容。开发指南读了一半,就是看这本书理解了的事件循环。哈哈创京东一本骗钱的书。欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由腾讯IVWEB团队发表于云+社区专栏 作者:link 2014年一月以来,自己接触web前端开发已经两年多了,记录一下自己前端学习路上看过的,以及道听途说的一些书,基本上按照由浅入深来介绍。...
阅读 2414·2019-08-30 15:52
阅读 2222·2019-08-30 12:51
阅读 2819·2019-08-29 18:41
阅读 2798·2019-08-29 17:04
阅读 788·2019-08-29 15:11
阅读 1667·2019-08-28 18:02
阅读 3582·2019-08-26 10:22
阅读 2496·2019-08-26 10:12