URI - Linux手册页
Linux程序员手册 第7部分
更新日期： 2020-08-13
名称
uri, url, urn——统一资源标识符(uri)，包括url或urn
语法
URI = [ absoluteURI | relativeURI ] [ "#" fragment ]
absoluteURI = scheme ":" ( hierarchical_part | opaque_part )
relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ]
scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
"file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...
hierarchical_part = ( net_path | absolute_path ) [ "?" query ]
net_path = "//" authority [ absolute_path ]
absolute_path = "/" path_segments
relative_path = relative_segment [ absolute_path ]
说明
统一资源标识符(URI)是标识抽象资源或物理资源(例如，web页面)的短字符串。统一资源定位符(URL)是一个URI，它通过资源的主要访问机制(例如，它的网络"位置")来标识资源，而不是通过资源的名称或其他属性。统一资源名(URN)是一个必须保持全局惟一和持久的URI，即使资源停止存在或变得不可用。
uri是为web浏览器等工具命名超文本链接目的地的标准方法。字符串"http://www.kernel.org"是一个URL(因此它也是一个URI)。许多人松散地使用术语URL作为URI的同义词(尽管从技术上讲URL是URI的子集)。
uri可以是绝对的，也可以是相对的。绝对标识符是指独立于上下文的资源，而相对标识符是通过描述与当前上下文的区别来指资源。在相对路径引用中，完整的路径段"."和".."分别具有特殊的含义:"当前层次层"和"此层次层之上的层次"，就像它们在类unix系统中所做的那样。包含冒号的路径段不能用作相对URI路径的第一个段(例如，"this:that")，因为它会被误认为方案名;在这些片段之前加上。/(例如，"./this:that")。注意MS-DOS的后代(例如Microsoft Windows)在uri中将devicename冒号替换为竖条("|")，因此"C:"变成了"C|"。
片段标识符(如果包括在内)指资源的特定命名部分(片段);aq#aq后面的文本标识片段。以aq#aq开头的URI引用当前资源中的那个片段。
Usage
有许多不同的URI方案，每个方案都有特定的附加规则和含义，但它们都有意尽可能地相似。例如，许多URL方案允许权限采用以下格式，在这里称为ip_server(方括号显示可选格式):
- ip_server = [user[ : password] @ ] host[ : port]
is the name of the host computer, either its name as determined by DNS
or an IP address (numbers separated by periods).
Thus the URI
<http://fred:[email protected]:8080/>
logs into a web server on host example.com
as fred (using fredpassword) using port 8080.
Avoid including a password in a URI if possible because of the many
security risks of having a password written down.
If the URL supplies a username but no password, and the remote
server requests a password, the program interpreting the URL
should request one from the user.
下面是类unix系统中使用的一些最常见的方案，许多工具都能理解这些方案。注意，许多使用uri的工具也有内部方案或专门方案;有关这些方案的信息，请参阅这些工具的文档。
http - Web (http)服务器
http://ip_server/path
http://ip_server/path?query
这是一个访问web (HTTP)服务器的URL。默认端口是80。如果路径指向一个目录，web服务器将选择返回什么;通常如果有一个名为"index"的文件。html"或"索引。否则，将生成并返回当前目录中的文件列表(带有适当的链接)。举个例子。
查询可以采用古老的"isindex"格式，由一个单词或短语组成，不包含等号(=)。查询也可以采用较长的"GET"格式，该格式有一个或多个查询项，形式为key=value，用与号(&)分隔。注意，这个键可以重复多次，但是要由web服务器及其应用程序来确定它是否有任何意义。与HTML/XML/SGML和GET查询格式之间存在不愉快的交互;当这种具有多个键的uri嵌入SGML/XML文档(包括HTML)时，必须将与号(&)重写为&。请注意，并非所有查询都使用这种格式;较大的表单可能太长而不能存储为URI，因此它们使用不同的交互机制(称为POST)，该机制不包含URI中的数据。有关更多信息，请参阅公共网关接口规范。
文件传输协议(ftp)
ftp://ip_server/path
这是一个通过文件传输协议(FTP)访问文件的URL。默认端口(用于控制)是21。如果不包含用户名，则提供用户名"anonymous"，在这种情况下，许多客户端提供请求者的Internet电子邮件地址作为密码。举个例子。
gopher服务器
gopher://ip_server/gophertype selector
gopher://ip_server/gophertype selector%09 search
gopher://ip_server/gophertype selector%09 search%09 gopher+_string
gopher的默认端口是70。gophertype是一个单字符字段，用于表示URL引用的资源的地鼠类型。整个路径也可能是空的，在这种情况下，分隔符"/"也是可选的，而且gophertype默认为"1"。
selector是Gopher selector字符串。在Gopher协议中，Gopher选择器字符串是一个八进制序列，它可以包含除09十六进制(US-ASCII HT或tab)、0A十六进制(US-ASCII字符LF)和0D (US-ASCII字符CR)之外的任何八进制。
mailto -电子邮件地址
mailto:电子邮件地址
这是一个电子邮件地址，通常采用name@hostname的形式。有关电子邮件地址的正确格式的更多信息，请参见mailaddr(7)。注意，任何%字符都必须重写为%25。举个例子。
新闻-新闻组或新闻消息
新闻:newsgroup-name
新闻:问题
新闻组名称是由句点分隔的层次结构名称，如"comp.infosystems.www.misc"。如果是"*"(如in)，它用来指"所有可用的新闻组"。举个例子。
消息id对应于IETF RFC 1036的消息id，不包含"";它采用unique@full_domain_name的形式。消息标识符可以通过出现"@"字符与新闻组名称相区别。
telnet - telnet登录
telnet: / / ip_server /
Telnet URL方案用于指定可通过Telnet协议访问的交互式文本服务。最后的"/"字符可以省略。默认端口是23。举个例子。
文件-普通文件
file://ip_server/path_segments
文件:path_segments
表示本地可访问的文件或目录。作为特例，ip_server可以是字符串"localhost"或空字符串;这被解释为"解析URL的机器"。如果路径是指向某个目录的，则查看器应该显示该目录的内容，并带有到每个容器的链接;并不是所有的观众都这样做。KDE支持通过URL生成文件。如果没有找到给定的文件，浏览器编写者可能希望通过文件名通配符来扩展文件名(参见glob(7)和glob(3))。
第二种格式(例如)是引用本地文件的正确格式。但是，旧的标准不允许这种格式，并且一些程序不将其识别为URI。更可移植的语法是使用一个空字符串作为服务器名，例如，;此表单执行相同的操作，并且很容易被模式匹配器和较早的程序识别为URI。注意，如果您真的想说"从当前位置开始"，就不要指定scheme;使用类似的相对地址，其副作用是与模式无关。该方案的一个例子是。
手册-手册页文档
男:命令名
男:命令名(部分)
这指的是本地联机手册(man)的参考页面。命令名后面可以有选择地加上括号和节号;请参阅man(7)以获得有关章节编号含义的更多信息。这个URI方案对于类unix系统(如Linux)是唯一的，并且目前没有由IETF注册。举个例子。
info - info页面文档
信息:virtual-filename
信息:virtual-filename #节点名
信息:(virtual-filename)
信息:节点名(virtual-filename)
该方案引用了在线信息参考页面(由texinfo文件生成)，这是一种供GNU工具等程序使用的文档格式。这个URI方案对于类unix系统(如Linux)是唯一的，并且目前没有由IETF注册。在撰写本文时，GNOME和KDE的URI语法不同，不接受对方的语法。前两种格式是GNOME格式;在节点名中，所有空格都写成下划线。第二种格式是KDE格式;节点名中的空格必须写成空格，尽管URI标准禁止这样做。希望将来大多数工具能够理解所有这些格式，并在节点名中始终接受空格为下划线。在GNOME和KDE中，如果使用没有节点名的表单，则假定节点名为"Top"。GNOME格式的例子是and。KDE格式的例子是和。
whatis -文档搜索
原因:字符串
该方案搜索命令的简短(单行)描述的数据库，并返回包含该字符串的描述列表。只返回完全匹配的单词。看到whatis(1)。这个URI方案对于类unix系统(如Linux)是唯一的，并且目前没有由IETF注册。
GNOME帮助文档
ghelp: name-of-application
这将为给定的应用程序加载GNOME帮助。注意，目前这种格式的文档并不多。
轻量级目录访问协议
ldap://hostport
ldap://hostport/
ldap://hostport/dn
ldap://hostport/dn?attributes
ldap://hostport/dn?attributes?scope
ldap://hostport/dn?attributes?scope?filter
ldap://hostport/dn?attributes?scope?filter?extensions
该方案支持对轻量级目录访问协议(LDAP)的查询，该协议用于查询一组服务器，以获得分层组织的信息(如人员和计算资源)。有关LDAP URL模式的更多信息，请参见RFC 2255。此URL的组成部分是:
- hostport
要查询的LDAP服务器，编写为主机名，可选后跟冒号和端口号。默认的LDAP端口是TCP端口389。如果为空，则客户端决定使用哪个LDAP服务器。
- dn
LDAP专有名称，它标识LDAP搜索的基本对象(请参阅RFC 2253第3节)。
- attributes
要返回的属性列表，以逗号分隔;请参阅RFC 2251第4.1.5节。如果省略，则应返回所有属性。
- scope
指定搜索的范围，可以是"base"(用于基本对象搜索)、"one"(用于一级搜索)或"sub"(用于子树搜索)之一。如果忽略范围，则假设"base"。
- filter
指定搜索筛选器(要返回的条目的子集)。如果省略，所有条目应被返回。参见RFC 2254第4节。
- extensions
用逗号分隔的类型=值对列表，对于不需要的选项，可以省略=值部分。前缀为aq的扩展名!aq是关键的(必须得到支持才能有效)，否则它是非关键的(可选的)。
通过示例来解释LDAP查询是最容易的。下面的查询询问ldap.it .umich.edu以获取关于美国密歇根大学的信息:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
要获取其邮政地址属性，请请求:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
向6666端口的host.com查询有关普通姓名(cn)的人的信息"Babs Jensen"在密歇根大学，请求:
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
wais -广域信息服务器
极冰原:/ / hostport /数据库
极冰原:/ / hostport /数据库?搜索
极冰原:/ / hostport /数据库/ wtype / wpath
该方案指定了一个WAIS数据库、搜索或文档(有关WAIS的更多信息，请参阅IETF RFC 1625)。Hostport是主机名，后面可选跟着冒号和端口号(默认端口号是210)。
第一个表单指定一个用于搜索的WAIS数据库。第二种形式指定了对WAIS数据库数据库的特定搜索。第三种表单指定要检索的WAIS数据库中的特定文档。wtype是对象类型的WAIS指定，而wpath是WAIS文档id。
其他方案
还有许多其他URI方案。大多数接受uri的工具都支持一组内部uri(例如，Mozilla有about: scheme来表示内部信息，而GNOME help浏览器有toc: scheme来表示不同的起始位置)。有许多方案已经被定义，但在当前没有被广泛使用(例如，prospero)。nntp:方案被弃用，取而代之的是news:方案。urn:方案支持urn，具有层次结构的名称空间(例如urn:ietf:…)将识别IETF文档);目前骨灰盒还没有得到广泛的应用。并非所有工具都支持所有方案。
Character encoding
uri使用有限数量的字符，以便可以在各种情况下输入和使用它们。
以下字符是保留的，也就是说，它们可能出现在URI中，但它们的使用仅限于保留用途(在形成URI之前必须对冲突数据进行转义):
; / ?: @ & = + $，
URI中可以包含无保留字符。无保留字符包括大写和小写的英文字母，十进制数字，以及下列有限的标点符号和符号:
- _ . ! ti * ' ()
所有其他字符必须转义。转义的八位元被编码为字符三个一，由百分比字符"%"后跟表示八位元代码的两个十六进制数字组成(可以使用大写或小写字母表示十六进制数字)。例如，空格必须转义为"%20"，制表符必须转义为"%09"，"&"必须转义为"%26"。由于%字符始终具有作为转义指示器的保留用途，因此必须将其转义为"%25"。在查询文本中，常用的做法是将空格字符转义为加号(+);相关的rfc(推荐%20)中没有统一定义这种做法，但是任何接受带有查询文本的uri的工具都应该为此做好准备。URI总是以"转义"形式显示。
可以在不改变URI语义的情况下对无保留字符进行转义，但除非在不允许出现未转义字符的上下文中使用URI，否则不应该这样做。例如，有时在HTTP URL路径中使用"%7e"而不是"ti"，但这两个对于HTTP URL来说是等效的。
对于必须处理美国ASCII字符集以外的字符的uri, HTML 4.01规范(section B.2)和IETF RFC 2718 (section 2.2.5)建议采用以下方法:
- 1.
将字符序列转换为UTF-8 (IETF RFC 2279)——参见utf-8(7)——然后
- 2.
使用URI转义机制，即对不安全的八进制使用%HH编码。
Writing a URI
在编写时，uri应该放在双引号中(例如"http://www.kernel.org")，用尖括号括起来(例如)，或者单独放在一行中。对于使用双引号的人的警告:永远不要在URI中移动无关的标点(例如句子结束的句点或列表中的逗号)，因为这会改变URI的值。相反，应该使用尖括号，或者切换到从不在引号内包含无关字符的引号系统。后一种系统，被"哈特规则"和"牛津作家和编辑词典"称为"新"或"逻辑"引用系统，是英国和世界各地黑客的首选做法(详见"行话文件"中关于黑客写作风格的部分，了解更多信息)。较早的文档建议在URI前面插入前缀"URL:"，但这种形式从未流行起来。
URI语法被设计为明确的。然而，随着URI变得越来越普遍，传统媒体(电视、广播、报纸、广告牌等)越来越多地使用缩写的URI引用，这些引用只包含所标识资源的权限和路径部分(例如)。这些引用主要用于人工解释，而不是机器解释，因为假定基于上下文的启发式方法足以完成URI(例如，以"www"开头的主机名很可能具有"http://"的URI前缀，而以"ftp"开头的主机名很可能具有"ftp://"的前缀)。许多客户端实现启发式地解析这些引用。这种启发式可能会随着时间而改变，特别是当引入新的方案时。由于缩写URI与相对URL路径具有相同的语法，因此不能在允许使用相对URI的地方使用缩写URI引用，只能在没有定义基时使用(比如在对话框中)。不要在文档中使用缩写的uri作为超文本链接;使用这里描述的标准格式。
遵循规范
(IETF RFC 2396) (HTML 4.0)
备注
Linux系统上任何接受uri的工具(例如web浏览器)都应该能够(直接或间接地)处理这里描述的所有方案，包括man:和info:方案。通过调用其他程序来处理它们是可以的，而且实际上是被鼓励的。
从技术上讲，片段不是URI的一部分。
有关如何在数据格式中嵌入uri(包括url)的信息，请参阅有关该格式的文档。HTML使用格式文本。Texinfo文件使用@uref{uri}格式。Man和mdoc有最近添加的UR宏，或者只是在文本中包含uri(查看器应该能够检测到://是URI的一部分)。
GNOME和KDE桌面环境目前接受的uri不同，特别是在各自的帮助浏览器中。要列出手册页，GNOME使用而KDE使用;要列出信息页，GNOME使用而KDE使用(此手册页的作者在这里更喜欢使用KDE方法，不过更常规的格式会更好)。通常，KDE使用一组生成文件的前缀。KDE更喜欢HTML格式的文档，通过。GNOME更喜欢使用ghelp方案来存储和查找文档。在撰写本文时，这两种浏览器都不处理对目录的引用，因此很难使用可浏览的URI引用整个目录。如上所述，这些环境在处理info: scheme的方式上有所不同，这可能是最重要的变化。预计GNOME和KDE将聚合为通用的URI格式，这个手册页的未来版本将描述聚合的结果。鼓励努力促进这种融合。
Security
URI本身并不构成安全威胁。不能保证曾经定位过给定资源的URL会继续这样做。也不能保证URL不会在以后的某个时间点定位到不同的资源;这样的保证只能从控制该名称空间和相关资源的人员那里获得。
有时，在构造一个URL时，可能会试图执行一些看似无害的操作(例如检索与资源关联的实体)，但实际上却会导致可能造成损害的远程操作发生。不安全的URL通常是通过指定一个端口号来构造的，而不是为相关网络协议保留的端口号。客户端不知情地联系实际运行不同协议的站点。URL的内容包含一些指令，这些指令根据另一个协议进行解释时，会导致一个意外的操作。一个例子是使用gopher URL导致通过SMTP服务器发送非预期的或模拟的消息。
在使用指定协议默认端口号以外的其他端口号的URL时，特别是当它是保留空间中的一个数字时，应该谨慎使用。
当URI包含给定协议的转义分隔符(例如，用于telnet协议的CR和LF字符)时，应注意这些分隔符在传输之前没有进行非转义。这可能会违反协议，但可以避免使用这些字符来模拟协议中的额外操作或参数，这些操作或参数可能会导致执行意外的、可能有害的远程操作。
显然，使用包含机密密码的URI是不明智的。特别是，强烈建议在URI的"userinfo"组件中使用密码，除非在"password"参数是公共的极少数情况下。
BUGS
文档可能被放置在不同的位置，因此对于任意格式的通用在线文档，目前还没有一个好的URI方案。由于不同的发行版和本地安装需求可能会将文件放在不同的目录中(可能在/usr/doc中，或在/usr/local/doc中，或在/usr/share中，或在其他位置)，所以无法对表单进行引用。此外，目录ZZZ通常在版本更改时发生更改(尽管文件名通配符可以部分克服这一点)。最后，使用file: scheme不容易支持从Internet动态加载文档(而不是将文件加载到本地文件系统)的人。可能会添加一个未来的URI方案(例如，"userdoc:")来允许程序包含对更详细文档的交叉引用，而不必知道文档的确切位置。另外，文件系统规范的未来版本可以充分地指定文件位置，以便file: scheme能够定位文档。
许多程序和文件格式没有包含使用uri合并或实现链接的方法。
许多程序不能处理所有这些不同的URI格式;应该有一个标准的机制来加载一个任意的URI，它可以自动检测用户的环境(例如，文本或图形、桌面环境、本地用户首选项和当前执行的工具)，并为任何URI调用正确的工具。
出版信息
[段落]
