Internet Engineering Task Force (IETF) M. Kerwin
Request for Comments: 8089 QUT
Updates: 1738 February 2017
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kerwin
Request for Comments: 8089 QUT
Updates: 1738 February 2017
Category: Standards Track
ISSN: 2070-1721
The "file" URI Scheme
“文件”URI方案
Abstract
摘要
This document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.
本文档提供了“文件”统一资源标识符（URI）方案的更完整规范，并取代RFC 1738第3.10节中非常简短的定义。
It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs.
它定义了一种通用语法，旨在跨广泛的现有用法进行互操作。同时，本文还介绍了一些关于使用文件URI的其他当前实践。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8089.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8089.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operations Involving <file> URIs . . . . . . . . . . . . . . 5
4. File System Name Encoding . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Differences from Previous Specifications . . . . . . 10
Appendix B. Example URIs . . . . . . . . . . . . . . . . . . . . 10
Appendix C. Similar Technologies . . . . . . . . . . . . . . . . 10
Appendix D. System-Specific Operations . . . . . . . . . . . . . 11
D.1. POSIX Systems . . . . . . . . . . . . . . . . . . . . . . 11
D.2. DOS- and Windows-Like Systems . . . . . . . . . . . . . . 11
D.3. Mac OS X Systems . . . . . . . . . . . . . . . . . . . . 12
D.4. OpenVMS Files-11 Systems . . . . . . . . . . . . . . . . 12
Appendix E. Nonstandard Syntax Variations . . . . . . . . . . . 12
E.1. User Information . . . . . . . . . . . . . . . . . . . . 12
E.2. DOS and Windows Drive Letters . . . . . . . . . . . . . . 13
E.2.1. Relative Resolution . . . . . . . . . . . . . . . . . 13
E.2.2. Vertical Line Character . . . . . . . . . . . . . . . 14
E.3. UNC Strings . . . . . . . . . . . . . . . . . . . . . . . 15
E.3.1. <file> URI with Authority . . . . . . . . . . . . . . 15
E.3.2. <file> URI with UNC Path . . . . . . . . . . . . . . 16
E.4. Backslash as Separator . . . . . . . . . . . . . . . . . 17
Appendix F. Collected Nonstandard Rules . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operations Involving <file> URIs . . . . . . . . . . . . . . 5
4. File System Name Encoding . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Differences from Previous Specifications . . . . . . 10
Appendix B. Example URIs . . . . . . . . . . . . . . . . . . . . 10
Appendix C. Similar Technologies . . . . . . . . . . . . . . . . 10
Appendix D. System-Specific Operations . . . . . . . . . . . . . 11
D.1. POSIX Systems . . . . . . . . . . . . . . . . . . . . . . 11
D.2. DOS- and Windows-Like Systems . . . . . . . . . . . . . . 11
D.3. Mac OS X Systems . . . . . . . . . . . . . . . . . . . . 12
D.4. OpenVMS Files-11 Systems . . . . . . . . . . . . . . . . 12
Appendix E. Nonstandard Syntax Variations . . . . . . . . . . . 12
E.1. User Information . . . . . . . . . . . . . . . . . . . . 12
E.2. DOS and Windows Drive Letters . . . . . . . . . . . . . . 13
E.2.1. Relative Resolution . . . . . . . . . . . . . . . . . 13
E.2.2. Vertical Line Character . . . . . . . . . . . . . . . 14
E.3. UNC Strings . . . . . . . . . . . . . . . . . . . . . . . 15
E.3.1. <file> URI with Authority . . . . . . . . . . . . . . 15
E.3.2. <file> URI with UNC Path . . . . . . . . . . . . . . 16
E.4. Backslash as Separator . . . . . . . . . . . . . . . . . 17
Appendix F. Collected Nonstandard Rules . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
A file URI identifies an object (a "file") stored in a structured object naming and accessing environment on a host (a "file system"). The URI can be used in discussions about the file, and if other conditions are met it can be dereferenced to directly access the file.
文件URI标识存储在主机（文件系统）上的结构化对象命名和访问环境中的对象（文件）。URI可以用于有关文件的讨论，如果满足其他条件，则可以取消对该URI的引用以直接访问该文件。
This document specifies a syntax based on the generic syntax of [RFC3986] that is compatible with most existing usages. Where incompatibilities arise, they are usually in parts of the scheme that were underspecified in earlier definitions and have been tightened up by more recent specifications. Appendix A lists significant changes to syntax.
本文档指定了基于[RFC3986]通用语法的语法，该语法与大多数现有用法兼容。当出现不兼容时，它们通常出现在方案的某些部分，这些部分在早期定义中未得到明确规定，并且在最近的规范中得到了加强。附录A列出了对语法的重大更改。
Extensions to the syntax that might be encountered in practice are listed in Appendix E; these extensions are listed for informational purposes and are not a requirement of implementation.
附录E中列出了实践中可能遇到的语法扩展；列出这些扩展是为了提供信息，不是实现的要求。
The file URI scheme is not coupled with a specific protocol nor with a specific media type [RFC6838]. See Section 3 for a discussion of operations that can be performed on the object identified by a file URI.
文件URI方案既不与特定协议耦合，也不与特定媒体类型耦合[RFC6838]。有关可对文件URI标识的对象执行的操作的讨论，请参见第3节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”在所有大写字母中出现时，应按照[RFC2119]中的说明进行解释。它们也可能以小写或混用形式出现在英语单词中，没有规范意义。
Throughout this document, the term "local file" is used to describe files that can be accessed through the local file system API using only the information included in the file path, not relying on other information (such as network addresses). It is important to note that a local file may not be physically located on the local machine, for example, if a networked file system is transparently mounted into the local file system.
在本文档中，术语“本地文件”用于描述仅使用文件路径中包含的信息，而不依赖于其他信息（如网络地址）通过本地文件系统API访问的文件。需要注意的是，本地文件可能不在本地计算机上物理定位，例如，如果网络文件系统透明地装入本地文件系统中。
The term "local file URI" is used to describe file URIs that have no "authority" component or where the authority is the special string "localhost" or a fully qualified domain name that resolves to the machine from which the URI is being interpreted (Section 2).
术语“本地文件URI”用于描述没有“权限”组件的文件URI，或者权限是特殊字符串“localhost”或解析为解释URI的机器的完全限定域名（第2节）。
The file URI syntax is defined here in Augmented Backus-Naur Form (ABNF) [RFC5234], importing the "host" and "path-absolute" rules from [RFC3986] (as updated by [RFC6874]).
文件URI语法在这里以扩充的Backus Naur表单（ABNF）[RFC5234]定义，从[RFC3986]（由[RFC6874]更新）导入“主机”和“绝对路径”规则。
The generic syntax in [RFC3986] includes "path" and "authority" components, for each of which only a subset is used in the definition of the file URI scheme. The relevant subset of "path" is "path-absolute", and the subset of "authority" is "file-auth", given below.
[RFC3986]中的通用语法包括“路径”和“权限”组件，对于每个组件，在文件URI方案的定义中仅使用一个子集。“路径”的相关子集是“绝对路径”，而“权限”的子集是“文件验证”，如下所示。
The syntax definition below is different from those given in [RFC1630] and [RFC1738] as it is derived from the generic syntax of [RFC3986], which postdates the previous file URI specifications. Appendix A enumerates significant differences.
下面的语法定义不同于[RFC1630]和[RFC1738]中给出的语法定义，因为它是从[RFC3986]的通用语法派生而来的，该语法晚于先前的文件URI规范。附录A列举了显著差异。
file-URI = file-scheme ":" file-hier-part
文件URI=文件方案“：“文件hier部分
file-scheme = "file"
file-scheme = "file"
file-hier-part = ( "//" auth-path )
/ local-path
file-hier-part = ( "//" auth-path )
/ local-path
auth-path = [ file-auth ] path-absolute
auth-path = [ file-auth ] path-absolute
local-path = path-absolute
local-path = path-absolute
file-auth = "localhost" / host
文件auth=“localhost”/host
The "host" is the fully qualified domain name of the system on which the file is accessible. This allows a client on another system to know that it cannot access the file system, or perhaps that it needs to use some other local mechanism to access the file.
“主机”是可访问文件的系统的完全限定域名。这允许另一个系统上的客户端知道它无法访问文件系统，或者可能需要使用其他一些本地机制来访问文件。
As a special case, the "file-auth" rule can match the string "localhost" that is interpreted as "the machine from which the URI is being interpreted," exactly as if no authority were present. Some current usages of the scheme incorrectly interpret all values in the authority of a file URI, including "localhost", as non-local. Yet others interpret any value as local, even if the "host" does not resolve to the local machine. To maximize compatibility with previous specifications, users MAY choose to include an "auth-path" with no "file-auth" when creating a URI.
作为一种特殊情况，“file auth”规则可以匹配字符串“localhost”，该字符串被解释为“从中解释URI的机器”，就像没有权限一样。该方案的某些当前用法错误地将文件URI权限中的所有值（包括“localhost”）解释为非本地值。还有一些人将任何值解释为本地值，即使“主机”不解析为本地计算机。为了最大限度地与以前的规范兼容，用户可以选择在创建URI时包含一个没有“文件验证”的“验证路径”。
The path component represents the absolute path to the file in the file system. See Appendix D for some discussion of system-specific concerns including absolute file paths and file system roots.
path组件表示文件系统中文件的绝对路径。有关系统特定问题的一些讨论，包括绝对文件路径和文件系统根，请参见附录D。
Some file systems have case-sensitive file naming and some do not. As such, the file URI scheme supports case sensitivity in order to retain the case as given. Any transport-related handling of the file URI scheme MUST retain the case as given. Any mapping to or from a case-insensitive form is solely the responsibility of the implementation processing the file URI on behalf of the referenced file system.
有些文件系统具有区分大小写的文件命名，有些则没有。因此，文件URI方案支持区分大小写，以便保留给定的大小写。任何与传输相关的文件URI方案处理都必须保留给定的大小写。与不区分大小写的表单之间的任何映射完全由代表引用的文件系统处理文件URI的实现负责。
Also see Appendix E, which lists some nonstandard syntax variations that can be encountered in practice.
另请参见附录E，其中列出了在实践中可能遇到的一些非标准语法变体。
See the POSIX file and directory operations [POSIX] for examples of standardized operations that can be performed on files.
有关可对文件执行的标准化操作的示例，请参阅POSIX文件和目录操作[POSIX]。
A file URI can be dependably dereferenced or translated to a local file path only if it is local. A file URI is considered "local" if it has no "file-auth", or the "file-auth" is the special string "localhost", or a fully qualified domain name that resolves to the machine from which the URI is being interpreted (Section 2).
只有当文件URI是本地文件路径时，才能可靠地将其解引用或转换为本地文件路径。如果文件URI没有“文件身份验证”，或者“文件身份验证”是特殊字符串“localhost”，或者是解析为从中解释URI的计算机的完全限定域名，则该文件URI被视为“本地”（第2节）。
This specification neither defines nor forbids any set of operations that might be performed on a file identified by a non-local file URI.
此规范既不定义也不禁止对非本地文件URI标识的文件执行任何操作集。
File systems use various encoding schemes to store file and directory names. Many modern file systems store file and directory names as arbitrary sequences of octets, in which case the representation as an encoded string often depends on the user's localization settings or defaults to UTF-8 [STD63].
文件系统使用各种编码方案来存储文件名和目录名。许多现代文件系统将文件名和目录名存储为八位字节的任意序列，在这种情况下，表示为编码字符串通常取决于用户的本地化设置或默认设置为UTF-8[STD63]。
When a file URI is produced that represents textual data consisting of characters from the Unicode Standard coded character set [UNICODE], the data SHOULD be encoded as octets according to the UTF-8 character encoding scheme [STD63] before percent-encoding is applied (as per Section 2.5 of [RFC3986]).
当生成表示由Unicode标准编码字符集[Unicode]中的字符组成的文本数据的文件URI时，在应用百分比编码之前（根据[RFC3986]第2.5节），应根据UTF-8字符编码方案[STD63]将数据编码为八位字节。
A decision not to use percent-encoded UTF-8 is outside the scope of this specification. It will typically require the use of heuristics or explicit knowledge about the way the string will be processed.
不使用百分比编码UTF-8的决定不在本规范的范围内。它通常需要使用启发式或关于字符串处理方式的明确知识。
There are many security considerations for URI schemes discussed in [RFC3986].
[RFC3986]中讨论了URI方案的许多安全注意事项。
File access and the granting of privileges for specific operations are complex topics, and the use of file URIs can complicate the security model in effect for file privileges.
文件访问和为特定操作授予权限是一个复杂的主题，使用文件URI会使文件权限的有效安全模型复杂化。
Historically, user agents have granted content from the file URI scheme a tremendous amount of privilege. However, granting all local files such wide privileges can lead to privilege escalation attacks. Some user agents have had success granting local files directory-based privileges, but this approach has not been widely adopted. Other user agents use globally unique identifiers as the origin for each file URI [RFC6454], which is the most secure option.
历史上，用户代理为文件URI方案中的内容授予了大量特权。但是，授予所有本地文件如此广泛的权限可能会导致权限升级攻击。一些用户代理已成功授予本地文件基于目录的权限，但这种方法尚未被广泛采用。其他用户代理使用全局唯一标识符作为每个文件URI[RFC6454]的源，这是最安全的选项。
Treating a non-local file URI as local, or otherwise attempting to perform local operations on a non-local URI, can result in security problems.
将非本地文件URI视为本地，或尝试对非本地URI执行本地操作，可能会导致安全问题。
File systems typically assign an operational meaning to special characters, such as the "/", "\", ":", "[", and "]" characters, and to special device names like ".", "..", "...", "aux", "lpt", etc. In some cases, merely testing for the existence of such a name will cause the operating system to pause or invoke unrelated system calls, leading to significant security concerns regarding denial of service and unintended data transfer. It would not be possible for this specification to list all such significant characters and device names. Implementers should research the reserved names and characters for the types of storage devices that may be attached to their application and restrict the use of data obtained from URI components accordingly.
文件系统通常为特殊字符（如“/”、“\”、“：”、“[”、“]”和“]”等）以及特殊设备名称（如“.”、“…”、“…”、“aux”、“lpt”等）分配操作含义。在某些情况下，仅测试此类名称的存在将导致操作系统暂停或调用不相关的系统调用，导致对拒绝服务和意外数据传输的重大安全问题。本规范不可能列出所有此类重要字符和设备名称。实现者应该研究可能附加到其应用程序的存储设备类型的保留名称和字符，并相应地限制使用从URI组件获得的数据。
File systems vary in the way they handle case. Care must be taken to avoid issues resulting from possibly unexpected aliasing from case-only differences between file paths or URIs or from mismatched encodings or Unicode equivalences [UAX15] (see Section 4).
文件系统处理案件的方式各不相同。必须注意避免由于文件路径或URI之间的大小写差异或不匹配的编码或Unicode等价物[UAX15]可能产生意外的别名而导致的问题（参见第4节）。
This document defines the following permanent URI scheme. The "Uniform Resource Identifier (URI) Schemes" registry has been updated accordingly. This registration complies with [BCP35].
本文档定义了以下永久URI方案。“统一资源标识符（URI）方案”注册表已相应更新。此注册符合[BCP35]。
Scheme name: file
方案名称：文件
Status: permanent
地位：永久
Applications/protocols that use this scheme name: Commonly used in hypertext documents to refer to files without depending on network access. Supported by major browsers.
使用此方案名称的应用程序/协议：通常用于超文本文档中，用于引用文件而不依赖于网络访问。主要浏览器支持。
Used in development libraries, such as:
在开发库中使用，例如：
* Windows Shell (PathCreateFromUrl, UrlCreateFromPath)
* Windows Shell（路径CreateFromURL、UrlCreateFromPath）
* libwww-perl - The World-Wide Web library for Perl
* libwww-perl-perl的万维网库
Contact:
Applications and Real-Time Area <art@ietf.org>
Contact:
Applications and Real-Time Area <art@ietf.org>
Change Controller:
IETF <ietf@ietf.org>
Change Controller:
IETF <ietf@ietf.org>
References: This RFC
参考：本RFC
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 6454，DOI 10.17487/RFC6454，2011年12月<http://www.rfc-editor.org/info/rfc6454>.
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, February 2013, <http://www.rfc-editor.org/info/rfc6874>.
[RFC6874]Carpenter，B.，Cheshire，S.和R.Hinden，“以地址文本和统一资源标识符表示IPv6区域标识符”，RFC 6874，DOI 10.17487/RFC6874，2013年2月<http://www.rfc-editor.org/info/rfc6874>.
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/std63>.
[STD63]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 36292003年11月<http://www.rfc-editor.org/info/std63>.
[Bash-Tilde] Free Software Foundation, Inc, "Bash Reference Manual: Tilde Expansion", September 2016, <http://www.gnu.org/software/bash/manual/html_node/ Tilde-Expansion.html>.
[ Bash Trd]自由软件基金会，Inc.，“BASH参考手册：TeldDebug”，2016年9月，<http://www.gnu.org/software/bash/manual/html_node/ Tilde Expansion.html>。
[BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, June 2015, <http://www.rfc-editor.org/info/bcp35>.
[BCP35]Thaler，D.，Ed.，Hansen，T.和T.Hardie，“URI方案的指南和注册程序”，BCP 35，RFC 75952015年6月<http://www.rfc-editor.org/info/bcp35>.
[Bug107540] Bugzilla@Mozilla, "Bug 107540", October 2001, <https://bugzilla.mozilla.org/show_bug.cgi?id=107540>.
[Bug107540]Bugzilla@Mozilla“Bug 107540”，2001年10月<https://bugzilla.mozilla.org/show_bug.cgi?id=107540>.
[MS-DTYP] Microsoft, "Windows Data Types: 2.2.57 UNC", October 2015, <http://msdn.microsoft.com/en-us/library/gg465305.aspx>.
[MS-DTYP]微软，“Windows数据类型：2.2.57 UNC”，2015年10月<http://msdn.microsoft.com/en-us/library/gg465305.aspx>.
[POSIX] IEEE, "IEEE Std 1003.1, 2013 Edition - Standard for Information Technology-- Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", DOI 10.1109/IEEESTD.2013.6506091, April 2013.
[POSIX]IEEE，“IEEE标准1003.12013版-信息技术标准-便携式操作系统接口（POSIX（R））基本规范，第7期”，DOI 10.1109/IEEESTD.2013.65060912013年4月。
[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, DOI 10.17487/RFC1630, June 1994, <http://www.rfc-editor.org/info/rfc1630>.
[RFC1630]Berners Lee，T.，“万维网中的通用资源标识符：万维网中使用的网络对象名称和地址表达的统一语法”，RFC 1630，DOI 10.17487/RFC1630，1994年6月<http://www.rfc-editor.org/info/rfc1630>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, December 1994, <http://www.rfc-editor.org/info/rfc1738>.
[RFC1738]Berners Lee，T.，Masinter，L.，和M.McCahill，“统一资源定位器（URL）”，RFC 1738，DOI 10.17487/RFC1738，1994年12月<http://www.rfc-editor.org/info/rfc1738>.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, DOI 10.17487/RFC2396, August 1998, <http://www.rfc-editor.org/info/rfc2396>.
[RFC2396]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，DOI 10.17487/RFC2396，1998年8月<http://www.rfc-editor.org/info/rfc2396>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<http://www.rfc-editor.org/info/rfc6838>.
[UAX15] Davis, M., Ed. and K. Whistler, Ed., "Unicode Standard Annex #15: Unicode Normalization Forms", February 2016, <http://www.unicode.org/reports/tr15/tr15-44.html>.
[UAX15]Davis，M.，Ed.和K.Whistler，Ed.，“Unicode标准附录#15：Unicode规范化格式”，2016年2月<http://www.unicode.org/reports/tr15/tr15-44.html>.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 9.0.0", ISBN 978-1-936213-13-9, June 2016, <http://www.unicode.org/versions/Unicode9.0.0/>.
[UNICODE]UNICODE联盟，“UNICODE标准，9.0.0版”，ISBN 978-1-936213-13-9，2016年6月<http://www.unicode.org/versions/Unicode9.0.0/>.
[WHATWG-URL] WHATWG, "URL Living Standard", January 2017, <https://url.spec.whatwg.org/>.
[WHATWG-URL]WHATWG，“URL生活标准”，2017年1月<https://url.spec.whatwg.org/>.
[Win32-Namespaces] Microsoft Developer Network Blogs, "Naming Files, Paths, and Namespaces", June 2013, <https://msdn.microsoft.com/ en-us/library/windows/desktop/aa365247(v=vs.85).aspx>.
[Win32命名空间]Microsoft开发者网络博客，“命名文件、路径和命名空间”，2013年6月<https://msdn.microsoft.com/ en us/library/windows/desktop/aa365247（v=vs.85）.aspx>。
[Zsh-Tilde] "The Z Shell Manual: 14.7 Filename Expansion", December 2015, <http://zsh.sourceforge.net/Doc/Release/ Expansion.html#Filename-Expansion>.
[Zsh Tilde]“Zshell手册：14.7文件名扩展”，2015年12月<http://zsh.sourceforge.net/Doc/Release/ Expansion.html#Filename Expansion>。
The syntax definition in Section 2 inherits incremental differences from the general syntax of [RFC1738], as described by Appendix G of [RFC2396] and Appendix D of [RFC3986].
第2节中的语法定义继承了[RFC1738]的一般语法的增量差异，如[RFC2396]的附录G和[RFC3986]的附录D所述。
According to the definition in [RFC1738], a file URL always started with the token "file://", followed by an (optionally blank) host name and a "/". The syntax given in Section 2 makes the entire authority component, including the double slashes "//", optional.
根据[RFC1738]中的定义，文件URL始终以标记“file://”开头，后跟主机名（可选为空）和“/”。第2节中给出的语法使整个权限组件（包括双斜杠“/”）成为可选的。
The syntax in Section 2 is intended to support file URIs that take the following forms:
第2节中的语法旨在支持采用以下形式的文件URI：
Local files:
本地文件：
o A traditional file URI for a local file with an empty authority. This is the most common format in use today. For example:
o 具有空权限的本地文件的传统文件URI。这是目前最常用的格式。例如：
* "file:///path/to/file"
* "file:///path/to/file"
o The minimal representation of a local file with no authority field and an absolute path that begins with a slash "/". For example:
o 本地文件的最小表示形式，没有权限字段和以斜杠“/”开头的绝对路径。例如：
* "file:/path/to/file"
* "file:/path/to/file"
Non-local files:
非本地文件：
o A non-local file with an explicit authority. For example:
o 具有明确权限的非本地文件。例如：
* "file://host.example.com/path/to/file"
* "file://host.example.com/path/to/file"
o The WHATWG URL specification [WHATWG-URL] defines browser behavior for a variety of inputs, including file URIs. As a living document, it changes to reflect updates in browser behavior. As a result, its algorithms and syntax definitions may or may not be consistent with this specification. Implementors should be aware of this possible discrepancy if they expect to share file URIs with browsers that follow the WHATWG specification.
o WHATWG URL规范[WHATWG-URL]定义了各种输入的浏览器行为，包括文件URI。作为一个活动文档，它会更改以反映浏览器行为中的更新。因此，其算法和语法定义可能与本规范一致，也可能不一致。如果实现者希望与遵循WHATWG规范的浏览器共享文件uri，他们应该意识到这种可能的差异。
o The Universal Naming Convention (UNC) [MS-DTYP] defines a string format that can perform a similar role to the file URI scheme in describing the location of files, except that files located by UNC filespace selector strings are typically stored on a remote
o 通用命名约定（UNC）[MS-DTYP]定义了一种字符串格式，该格式在描述文件位置时可以执行与文件URI方案类似的作用，但UNC文件空间选择器字符串定位的文件通常存储在远程服务器上
machine and accessed using a network protocol. Appendix E.3 lists some ways in which UNC filespace selector strings are currently made to interoperate with the file URI scheme.
使用网络协议访问计算机。附录E.3列出了当前使UNC文件空间选择器字符串与文件URI方案互操作的一些方法。
o The Microsoft Windows API defines Win32 Namespaces [Win32-Namespaces] for interacting with files and devices using Windows API functions. These namespaced paths are prefixed by "\\?\" for Win32 File Namespaces and "\\.\" for Win32 Device Namespaces. There is also a special case for UNC file paths in Win32 File Namespaces, referred to as "Long UNC", using the prefix "\\?\UNC\". This specification does not define a mechanism for translating namespaced paths to or from file URIs.
o Microsoft Windows API定义Win32命名空间[Win32命名空间]，用于使用Windows API函数与文件和设备进行交互。对于Win32文件名称空间，这些名称空间路径的前缀为“\\？\”，对于Win32设备名称空间，前缀为“\\.\”。Win32文件名称空间中的UNC文件路径也有一种特殊情况，称为“长UNC”，使用前缀“\\？\UNC\”。本规范未定义将命名空间路径转换为文件URI或从文件URI转换为文件URI的机制。
This appendix is not normative. It highlights some observed behaviors and provides system-specific guidance for interacting with file URIs and paths. This is not an exhaustive list of operating or file systems; rather, it is intended to illustrate certain types of interactions that might be encountered.
本附录不规范。它突出显示了一些观察到的行为，并为与文件URI和路径交互提供了特定于系统的指导。这不是操作系统或文件系统的详尽列表；相反，它旨在说明可能遇到的某些类型的交互。
In a POSIX file system, the root of the file system is represented as a directory with a zero-length name, usually written as "/"; the presence of this root in a file URI can be taken as given by the initial slash in the "path-absolute" rule.
在POSIX文件系统中，文件系统的根目录表示为具有零长度名称的目录，通常写为“/”；文件URI中是否存在此根可以视为“绝对路径”规则中的初始斜杠。
Common UNIX shells such as the Bourne-Again SHell (bash) and Z SHell (zsh) provide a function known as "tilde expansion" [Bash-Tilde] or "filename expansion" [Zsh-Tilde], where a path that begins with a tilde character "~" can be expanded out to a special directory name. No such facility exists using the file URI scheme; a tilde in a file URI is always just a tilde.
常见的UNIX SHell，如Bourne SHell（bash）和Z SHell（zsh）提供了一个称为“tilde扩展”[bash tilde]或“文件名扩展”[zsh tilde]的函数，其中以tilde字符“~”开头的路径可以扩展到一个特殊的目录名。不存在使用文件URI方案的此类设施；文件URI中的波浪号始终只是波浪号。
When mapping a DOS- or Windows-like file path to a file URI, the drive letter (e.g., "c:") is typically mapped into the first path segment.
将DOS或类似Windows的文件路径映射到文件URI时，驱动器号（例如，“c:”）通常映射到第一个路径段。
Appendix E lists some nonstandard techniques for interacting with DOS- or Windows-like file paths and URIs.
附录E列出了一些与DOS或Windows交互的非标准技术，如文件路径和URI。
The Hierarchical File System Plus (HFS+) uses a nonstandard normalization form, similar to Normalization Form D [UAX15]. Take care when transforming HFS+ file paths to and from URIs (Section 4).
分层文件系统升级版（HFS+）使用非标准规范化表单，类似于规范化表单D[UAX15]。在将HFS+文件路径转换为URI和从URI转换HFS+文件路径时要小心（第4节）。
When mapping a Virtual Memory System (VMS) file path to a file URI, the device name is mapped into the first path segment. Note that the dollars sign "$" is a reserved character per the definition in Section 2.2 of [RFC3986], so it should be percent-encoded if present in the device name.
将虚拟内存系统（VMS）文件路径映射到文件URI时，设备名称映射到第一个路径段。请注意，根据[RFC3986]第2.2节中的定义，美元符号“$”是一个保留字符，因此如果设备名称中存在，则应采用百分比编码。
If the VMS file path includes a node reference, that reference is used as the authority. Where the original node reference includes a user name and password in an access control string, they can be transcribed into the authority using the nonstandard syntax extension in Appendix E.1.
如果VMS文件路径包含节点引用，则该引用将用作权限。如果原始节点引用在访问控制字符串中包含用户名和密码，则可以使用附录E.1中的非标准语法扩展将其转录到授权机构中。
These variations may be encountered by existing usages of the file URI scheme but are not supported by the normative syntax of Section 2.
文件URI方案的现有用法可能会遇到这些变化，但第2节的规范语法不支持这些变化。
This appendix is not normative.
本附录不规范。
It might be necessary to include user information such as a user name in a file URI, for example, when mapping a VMS file path with a node reference that includes an access control string.
例如，当使用包含访问控制字符串的节点引用映射VMS文件路径时，可能需要在文件URI中包含用户名等用户信息。
To allow user information to be included in a file URI, the "file-auth" rule in Section 2 can be replaced with the following:
为了允许用户信息包含在文件URI中，第2节中的“文件身份验证”规则可以替换为以下内容：
file-auth = "localhost" / [ userinfo "@" ] host
file auth=“localhost”/[userinfo”@“]host
This uses the "userinfo" rule from [RFC3986].
这使用[RFC3986]中的“用户信息”规则。
As discussed in the HP OpenVMS Systems Documentation
<http://h71000.www7.hp.com/doc/84final/ba554_90015/ch03s09.html>,
"access control strings include sufficient information to allow
someone to break in to the remote account, [therefore] they create
serious security exposure." In a similar vein, the presence of a
As discussed in the HP OpenVMS Systems Documentation
<http://h71000.www7.hp.com/doc/84final/ba554_90015/ch03s09.html>,
"access control strings include sufficient information to allow
someone to break in to the remote account, [therefore] they create
serious security exposure." In a similar vein, the presence of a
password in a "user:password" userinfo field is deprecated by [RFC3986]. Take care when dealing with information that can be used to identify a user or grant access to a system.
[RFC3986]不推荐使用“用户：密码”用户信息字段中的密码。在处理可用于识别用户或授予系统访问权限的信息时要小心。
On Windows- or DOS-like file systems, an absolute file path can begin with a drive letter. To facilitate this, the "local-path" rule in Section 2 can be replaced with the following:
在类似Windows或DOS的文件系统上，绝对文件路径可以以驱动器号开头。为便于此，第2节中的“本地路径”规则可替换为以下内容：
local-path = [ drive-letter ] path-absolute
local-path = [ drive-letter ] path-absolute
drive-letter = ALPHA ":"
驱动器号=字母“：”
The "ALPHA" rule is defined in [RFC5234].
[RFC5234]中定义了“阿尔法”规则。
This is intended to support the minimal representation of a local file in a DOS- or Windows-like environment, with no authority field and an absolute path that begins with a drive letter. For example:
这是为了在DOS或类似Windows的环境中支持本地文件的最小表示，没有权限字段和以驱动器号开头的绝对路径。例如：
o "file:c:/path/to/file"
o "file:c:/path/to/file"
URIs of the form "file:///c:/path/to/file" are already supported by the "path-absolute" rule.
“形式的URI”file:///c:/path/to/file“绝对路径”规则已支持。
Note that comparison of drive letters in DOS or Windows file paths is case insensitive. In some usages of file URIs, drive letters are canonicalized by converting them to uppercase; other usages treat URIs that differ only in the case of the drive letter as identical.
请注意，DOS或Windows文件路径中驱动器号的比较不区分大小写。在文件URI的某些用法中，通过将驱动器号转换为大写来规范化驱动器号；其他用法将仅在驱动器号的情况下不同的URI视为相同。
To mimic the behavior of DOS- or Windows-like file systems, relative references beginning with a slash "/" can be resolved relative to the drive letter when present; resolution of ".." dot segments (per Section 5.2.4 of [RFC3986]) can be modified to not ever overwrite the drive letter.
为了模仿DOS或类似Windows的文件系统的行为，以斜杠“/”开头的相对引用可以在存在时相对于驱动器号进行解析；“.”点段的分辨率（根据[RFC3986]第5.2.4节）可以修改为永远不会覆盖驱动器号。
For example:
例如：
base URI: file:///c:/path/to/file.txt
rel. ref.: /some/other/thing.bmp
resolved: file:///c:/some/other/thing.bmp
base URI: file:///c:/path/to/file.txt
rel. ref.: /some/other/thing.bmp
resolved: file:///c:/some/other/thing.bmp
base URI: file:///c:/foo.txt
rel. ref.: ../bar.txt
resolved: file:///c:/bar.txt
base URI: file:///c:/foo.txt
rel. ref.: ../bar.txt
resolved: file:///c:/bar.txt
A relative reference starting with a drive letter would be interpreted by a generic URI parser as a URI with the drive letter as its scheme. Instead, such a reference ought to be constructed with a leading slash "/" character (e.g., "/c:/foo.txt").
以驱动器号开头的相对引用将由通用URI解析器解释为以驱动器号作为其方案的URI。相反，这种引用应该用前导斜杠“/”字符（例如“/c:/foo.txt”）构造。
Relative references with a drive letter followed by a character other than a slash (e.g., "/c:bar/baz.txt" or "/c:../foo.txt") might not be accepted as dereferenceable URIs in DOS- or Windows-like systems.
在DOS或类似Windows的系统中，驱动器号后跟斜杠以外的字符（例如“/c:bar/baz.txt”或“/c:../foo.txt”）的相对引用可能不被接受为可取消引用的URI。
Historically, some usages of file URIs have included a vertical line character "|" instead of a colon ":" in the drive letter construct. [RFC3986] forbids the use of the vertical line; however, it may be necessary to interpret or update old URIs.
历史上，文件URI的某些用法在驱动器号构造中包含了垂直线字符“|”，而不是冒号“：”。[RFC3986]禁止使用垂直线；但是，可能需要解释或更新旧URI。
For interpreting such URIs, the "auth-path" and "local-path" rules in Section 2 and the "drive-letter" rule above can be replaced with the following:
为了解释此类URI，第2节中的“身份验证路径”和“本地路径”规则以及上面的“驱动器号”规则可以替换为以下内容：
auth-path = [ file-auth ] path-absolute
/ [ file-auth ] file-absolute
auth-path = [ file-auth ] path-absolute
/ [ file-auth ] file-absolute
local-path = [ drive-letter ] path-absolute
/ file-absolute
local-path = [ drive-letter ] path-absolute
/ file-absolute
file-absolute = "/" drive-letter path-absolute
文件绝对值=“/”驱动器号路径绝对值
drive-letter = ALPHA ":" / ALPHA "|"
驱动器号=ALPHA:“/ALPHA”|”
This is intended to support regular DOS or Windows file URIs with vertical line characters in the drive letter construct. For example:
这是为了支持驱动器号结构中带有垂直线字符的常规DOS或Windows文件URI。例如：
o "file:///c|/path/to/file"
o "file:///c|/path/to/file"
o "file:/c|/path/to/file"
o "file:/c|/path/to/file"
o "file:c|/path/to/file"
o "file:c|/path/to/file"
To update such an old URI, replace the vertical line "|" with a colon ":".
要更新这样的旧URI，请将垂直线“|”替换为冒号“：”。
Some usages of the file URI scheme allow UNC filespace selector strings [MS-DTYP] to be translated to and from file URIs, either by mapping the equivalent segments of the two schemes (hostname to authority, sharename+objectnames to path), or by mapping the entire UNC string to the path segment of a URI.
文件URI方案的某些用法允许将UNC文件空间选择器字符串[MS-DTYP]转换为文件URI或从文件URI转换为文件URI，方法是将两个方案的等效段（主机名到权限，共享名+对象名到路径）映射，或将整个UNC字符串映射到URI的路径段。
The following is an algorithmic description of the process of translating a UNC filespace selector string to a file URI by mapping the equivalent segments of the two schemes:
以下是通过映射两个方案的等效段将UNC文件空间选择器字符串转换为文件URI的过程的算法描述：
1. Initialize the URI with the "file:" scheme identifier.
1. 使用“file:”方案标识符初始化URI。
2. Append the authority:
2. 授权：
1. Append the "//" authority sigil to the URI.
1. 将“/”权限标志附加到URI。
2. Append the host-name field of the UNC string to the URI.
2. 将UNC字符串的主机名字段追加到URI。
3. Append the share-name:
3. 附加共享名：
1. Transform the share-name to a path segment (see Section 3.3 of [RFC3986]) to conform to the encoding rules of Section 2 of [RFC3986].
1. 将共享名转换为路径段（参见[RFC3986]第3.3节），以符合[RFC3986]第2节的编码规则。
2. Append a delimiting slash character "/" and the transformed segment to the URI.
2. 将分隔斜杠字符“/”和转换的段附加到URI。
4. For each object-name:
4. 对于每个对象名称：
1. Transform the objectname to a path segment as above.
1. 如上所述，将objectname转换为路径段。
The colon character ":" is allowed as a delimiter before stream-name and stream-type in the file-name, if present.
允许冒号“：”作为文件名中流名称和流类型之前的分隔符（如果存在）。
2. Append a delimiting slash character "/" and the transformed segment to the URI.
2. 将分隔斜杠字符“/”和转换的段附加到URI。
For example, the UNC String:
例如，UNC字符串：
UNC String: \\host.example.com\Share\path\to\file.txt
UNC字符串：\\host.example.com\Share\path\to\file.txt
would be transformed into the URI:
将转换为URI：
URI: file://host.example.com/Share/path/to/file.txt
URI: file://host.example.com/Share/path/to/file.txt
The inverse algorithm for translating a file URI to a UNC filespace selector string is left as an exercise for the reader.
将文件URI转换为UNC文件空间选择器字符串的反向算法留给读者作为练习。
It is common to encounter file URIs that encode entire UNC strings in the path, usually with all backslash "\" characters replaced with slashes "/".
通常会遇到对路径中的整个UNC字符串进行编码的文件URI，通常所有反斜杠“\”字符都替换为斜杠“/”。
To interpret such URIs, the "auth-path" rule in Section 2 can be replaced with the following:
要解释此类URI，可将第2节中的“验证路径”规则替换为以下内容：
auth-path = [ file-auth ] path-absolute
/ unc-authority path-absolute
auth-path = [ file-auth ] path-absolute
/ unc-authority path-absolute
unc-authority = 2*3"/" file-host
unc-authority = 2*3"/" file-host
file-host = inline-IP / IPv4address / reg-name
file-host = inline-IP / IPv4address / reg-name
inline-IP = "%5B" ( IPv6address / IPvFuture ) "%5D"
内联IP=“%5B”（IPV6地址/IPvFuture）”%5D
This syntax uses the "IPv4address", "IPv6address", "IPvFuture", and "reg-name" rules from [RFC3986].
此语法使用[RFC3986]中的“IPv4address”、“IPv6地址”、“IPvFuture”和“reg name”规则。
Note that the "file-host" rule is the same as "host" but with percent-encoding applied to "[" and "]" characters.
请注意，“文件主机”规则与“主机”规则相同，但对“[”和“]”字符应用了百分比编码。
This extended syntax is intended to support URIs that take the following forms, in addition to those in Appendix B:
此扩展语法旨在支持除附录B中的URI外，还采用以下形式的URI：
Non-local files:
非本地文件：
o The representation of a non-local file with an empty authority and a complete (transformed) UNC string in the path. For example:
o 具有空权限和路径中完整（转换）UNC字符串的非本地文件的表示形式。例如：
* "file:////host.example.com/path/to/file"
* "file:////host.example.com/path/to/file"
o As above, with an extra slash between the empty authority and the transformed UNC string, as per the syntax defined in [RFC1738]. For example:
o 如上所述，根据[RFC1738]中定义的语法，在空权限和转换后的UNC字符串之间加一个斜杠。例如：
* "file://///host.example.com/path/to/file"
* "file://///host.example.com/path/to/file"
This representation is notably used by the Firefox web browser. See Bugzilla#107540 [Bug107540].
Firefox web浏览器尤其使用这种表示。参见Bugzilla#107540[Bug107540]。
It also further limits the definition of a "local file URI" by excluding any file URI with a path that encodes a UNC string.
它还通过排除具有编码UNC字符串路径的任何文件URI，进一步限制了“本地文件URI”的定义。
Historically, some usages have copied entire file paths into the path components of file URIs. Where DOS or Windows file paths were thus copied, the resulting URI strings contained unencoded backslash "\" characters, which are forbidden by both [RFC1738] and [RFC3986].
历史上，有些用法将整个文件路径复制到文件URI的路径组件中。在这样复制DOS或Windows文件路径的情况下，生成的URI字符串包含未编码的反斜杠“\”字符，这是[RFC1738]和[RFC3986]都禁止的。
It may be possible to translate or update such an invalid file URI by replacing all backslashes "\" with slashes "/" if it can be determined with reasonable certainty that the backslashes are intended as path separators.
如果可以合理确定反斜杠用作路径分隔符，则可以通过将所有反斜杠“\”替换为斜杠“/”来翻译或更新此类无效的文件URI。
Here are the collected syntax rules for all optional appendices, presented for convenience. This collected syntax is not normative.
以下是为方便起见，为所有可选附录收集的语法规则。这种语法不规范。
file-URI = file-scheme ":" file-hier-part
文件URI=文件方案“：“文件hier部分
file-scheme = "file"
file-scheme = "file"
file-hier-part = ( "//" auth-path )
/ local-path
file-hier-part = ( "//" auth-path )
/ local-path
auth-path = [ file-auth ] path-absolute
/ [ file-auth ] file-absolute
/ unc-authority path-absolute
auth-path = [ file-auth ] path-absolute
/ [ file-auth ] file-absolute
/ unc-authority path-absolute
local-path = [ drive-letter ] path-absolute
/ file-absolute
local-path = [ drive-letter ] path-absolute
/ file-absolute
file-auth = "localhost" / [ userinfo "@" ] host
file auth=“localhost”/[userinfo”@“]host
unc-authority = 2*3"/" file-host
unc-authority = 2*3"/" file-host
file-host = inline-IP / IPv4address / reg-name
file-host = inline-IP / IPv4address / reg-name
inline-IP = "%5B" ( IPv6address / IPvFuture ) "%5D"
内联IP=“%5B”（IPV6地址/IPvFuture）”%5D
file-absolute = "/" drive-letter path-absolute
文件绝对值=“/”驱动器号路径绝对值
drive-letter = ALPHA ":" / ALPHA "|"
驱动器号=ALPHA:“/ALPHA”|”
This collected syntax is intended to support file URIs that take the following forms:
此收集的语法旨在支持采用以下形式的文件URI：
Local files:
本地文件：
o A traditional file URI for a local file with an empty authority. For example:
o 具有空权限的本地文件的传统文件URI。例如：
* "file:///path/to/file"
* "file:///path/to/file"
o The minimal representation of a local file with no authority field and an absolute path that begins with a slash "/". For example:
o 本地文件的最小表示形式，没有权限字段和以斜杠“/”开头的绝对路径。例如：
* "file:/path/to/file"
* "file:/path/to/file"
o The minimal representation of a local file in a DOS- or Windows-based environment with no authority field and an absolute path that begins with a drive letter. For example:
o 在基于DOS或Windows的环境中，本地文件的最小表示形式，没有权限字段和以驱动器号开头的绝对路径。例如：
* "file:c:/path/to/file"
* "file:c:/path/to/file"
o Regular DOS or Windows file URIs with vertical line characters in the drive letter construct. For example:
o 驱动器号结构中带有垂直线字符的常规DOS或Windows文件URI。例如：
* "file:///c|/path/to/file"
* "file:///c|/path/to/file"
* "file:/c|/path/to/file"
* "file:/c|/path/to/file"
* "file:c|/path/to/file"
* "file:c|/path/to/file"
Non-local files:
非本地文件：
o The representation of a non-local file with an explicit authority. For example:
o 具有明确权限的非本地文件的表示形式。例如：
* "file://host.example.com/path/to/file"
* "file://host.example.com/path/to/file"
o The "traditional" representation of a non-local file with an empty authority and a complete (transformed) UNC string in the path. For example:
o 非本地文件的“传统”表示形式，路径中有一个空权限和一个完整的（转换的）UNC字符串。例如：
* "file:////host.example.com/path/to/file"
* "file:////host.example.com/path/to/file"
o As above, with an extra slash between the empty authority and the transformed UNC string. For example:
o 如上所述，在空权限和转换后的UNC字符串之间加一个斜杠。例如：
* "file://///host.example.com/path/to/file"
* "file://///host.example.com/path/to/file"
Acknowledgements
致谢
Contributions from many members of the IETF and W3C communities -- notably Dave Crocker, Graham Klyne, Tom Petch, and John Klensin -- are greatly appreciated.
我们非常感谢IETF和W3C社区的许多成员的贡献，特别是Dave Crocker、Graham Klyne、Tom Petch和John Klensin。
Additional thanks to Dave Risney, author of the informative IEBlog article <http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx>, and Dave Thaler for their early comments and suggestions; and to Paul Hoffman, whose earlier work served as an inspiration for this undertaking.
还要感谢Dave Risney，这篇信息丰富的IEBlog文章的作者<http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx>，以及Dave Thaler的早期评论和建议；保罗·霍夫曼（Paul Hoffman），他早期的工作为这项事业提供了灵感。
Author's Address
作者地址
Matthew Kerwin Queensland University of Technology Victoria Park Road Kelvin Grove, QLD 4059 Australia
Matthew Kerwin昆士兰科技大学维多利亚公园路Kelvin Grave，QLD 4059澳大利亚
Email: matthew.kerwin@qut.edu.au
Email: matthew.kerwin@qut.edu.au