标签：1.7 服务器端 URL URI RFC 标识符 资源
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 协议的一些服务器端和客户端里就存在上述情况。
标签：1.7,服务器端,URL,URI,RFC,标识符,资源 来源： https://www.cnblogs.com/wslxq/p/15422502.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。