RFC3986 - 版本历史

2014年1月8日 (三) 08:49 Admin

2014-01-08T08:49:32Z

Admin: /* 作者地址 */

2014-01-08T08:48:33Z

作者地址

Admin: /* D.2. 变更 */

2014-01-08T08:46:35Z

D.2. 变更

Admin: /* D.2. 变更 */

2013-12-31T09:10:08Z

D.2. 变更

Admin: /* D.2. 变更 */

2013-12-31T08:47:01Z

D.2. 变更

Admin: /* D.2. 变更 */

2013-12-25T16:26:07Z

D.2. 变更

Admin: /* D.2. 修改 */

2013-12-18T04:47:45Z

D.2. 修改

Admin: /* 附录D. 对RFC 2396的改变 */

2013-12-17T06:10:38Z

附录D. 对RFC 2396的改变

Admin: /* 附录C. 在上下文中限定一个URI */

2013-12-13T08:33:17Z

附录C. 在上下文中限定一个URI

Admin: /* 附录C. 在上下文中限定一个URI */

2013-12-13T08:01:18Z

附录C. 在上下文中限定一个URI

@@ 第1行： / 第1行： @@
 '''本文的英文原文来自[http://tools.ietf.org/html/rfc3986 Uniform Resource Identifier (URI): Generic Syntax]'''
@@ 第1,459行： / 第1,456行： @@
     Funding for the RFC Editor function is currently provided by the
     Internet Society.

@@ 第1,414行： / 第1,414行： @@
     URI:   http://larry.masinter.net/
+==完整版权声明==
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-Berners-Lee, et al.         Standards Track                    [Page 60]
-−
-RFC 3986                   URI Generic Syntax               January 2005
-−
-−
-Full Copyright Statement
     Copyright (C) The Internet Society (2005).
@@ 第1,449行： / 第1,430行： @@
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Intellectual Property
+==知识产权==
     The IETF takes no position regarding the validity or scope of any
@@ 第1,474行： / 第1,455行： @@
-Acknowledgement
+==鸣谢==
     Funding for the RFC Editor function is currently provided by the
     Internet Society.

@@ 第1,218行： / 第1,218行： @@
 :* 恢复了[http://tools.ietf.org/html/rfc1808 RFC1808]的行为, 如果引用包含空路径和一个已定义的查询部件, 目标URI继承该基础URI的路径部件.
-:* 确定一个URI引用是不是一个相同文档引用已经被从URI解析中解耦, 简化应用程序的URI处理接口，以和已部署的URI处理实现的内部系统架构一致的方式.  The determination is now based on comparison to
+:* 确定一个URI引用是不是一个相同文档引用已经被从URI解析中解耦, 简化应用程序的URI处理接口，以和已部署的URI处理实现的内部系统架构一致的方式. 确认行为现在是基于在把引用转换成绝对表格之后的基础URI的比较而不是引用本身的格式比较. 这个变更导致在本协议之下会比在[http://tools.ietf.org/html/rfc2396 RFC 2396]给定的规则下有更多的引用被认为是 "同文" , 特别是当正规化被用于减少别名时. 无论如何, 它不改变现有的同文引用的状态.
-      the base URI after transforming a reference to absolute form,
-      rather than on the format of the reference itself.  This change
-      may result in more references being considered "same-document"
-      under this specification than there would be under the rules given
-      in RFC 2396, especially when normalization is used to reduce
-      aliases.  However, it does not change the status of existing
-      same-document references.
-   o  Separated the path merge routine into two routines: merge, for
+:* 把路径合并程序分成两个程序: 合并, 用于描述带有相对路径引用的基础URI的组合, 并移除点片段, 描述如何从一个组合的路径中移除特定的 "." 和 ".." 片段. 移除点片段算法现在适用于所有 URI引用路径以在实践中匹配通用实现并提升URIs的正规化. 这一变更只影响那些基础URI有一个非层次路径的异常引用和同格式引用.
-      describing combination of the base URI path with a relative-path
-      reference, and remove_dot_segments, for describing how to remove
-      the special "." and ".." segments from a composed path.  The
-      remove_dot_segments algorithm is now applied to all URI reference
-      paths in order to match common implementations and to improve the
-      normalization of URIs in practice.  This change only impacts the
-      parsing of abnormal references and same-scheme references wherein
-      the base URI has a non-hierarchical path.
-Index
+==索引==
+    A
@@ 第1,255行： / 第1,240行： @@
        characters  8, 11
        coded character set  4
+    D
@@ 第1,311行： / 第1,289行： @@
        path-absolute  16, 22, 26
        path-empty  16, 22, 26
        path-rootless  16, 22
        pchar  23
@@ 第1,367行： / 第1,337行： @@
           fragment  24
           gen-delims  13
           h16  20
           HEXDIG  11
@@ 第1,415行： / 第1,377行： @@
        userinfo  18
+==作者地址==
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-Berners-Lee, et al.         Standards Track                    [Page 59]
-−
-RFC 3986                   URI Generic Syntax               January 2005
-−
-−
-Authors' Addresses
     Tim Berners-Lee

@@ 第1,214行： / 第1,214行： @@
-   o  [RFC2396] section 5.2, step 6a, failed to account for a base URI
+:* [http://tools.ietf.org/html/rfc2396#section-5.2 RFC2396第5.2章] , 步骤6a, 无法认定一个没有路径的基础URI.
-      with no path.
-   o  Restored the behavior of [RFC1808] where, if the reference
+:* 恢复了[http://tools.ietf.org/html/rfc1808 RFC1808]的行为, 如果引用包含空路径和一个已定义的查询部件, 目标URI继承该基础URI的路径部件.
-      contains an empty path and a defined query component, the target
-      URI inherits the base URI's path component.
-   o  The determination of whether a URI reference is a same-document
+:* 确定一个URI引用是不是一个相同文档引用已经被从URI解析中解耦, 简化应用程序的URI处理接口，以和已部署的URI处理实现的内部系统架构一致的方式.  The determination is now based on comparison to
-      reference has been decoupled from the URI parser, simplifying the
-      URI processing interface within applications in a way consistent
-      with the internal architecture of deployed URI processing
-      implementations.  The determination is now based on comparison to
        the base URI after transforming a reference to absolute form,
        rather than on the format of the reference itself.  This change

@@ 第1,203行： / 第1,203行： @@
 [[RFC3986#字符|第二章]], 在字符方面, 已经重写以解释什么字符是保留的, 什么时候它们被保留, 以及为什么它们被保留, 甚至什么时候它们不被通用语法用作分隔符. 典型的对于解码不安全的标点符号, 包括感叹号 ("!"), 星号 ("*"), 单引号 ("'"), 以及打开和关闭括号 ("(" 和 ")"), 已经被移到保留集合以澄清保留的和非保留的之间的唯一性, 并期望, 解答格式定义者的大部分常见问题. 同样, 百分号编码字节那一章已经被重写, 且URI常规化现在允许解码任何对应非保留字符的百分号字节. 通常, 术语 "escaped" 和 "unescaped" 已经被 "percent-encoded" 和 "decoded" 分别替换, 来减少和其他格式逃逸机制的混淆.
-用于URI和URI引用的ABN已经被重新涉及以使它们对LALR解析器更加友好并减少复杂度. 结果是, 语法描述的布局格式已经被移除, 包括 uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path, path_segments, rel_segment, 以及 mark rules. 所有对 "不透明" URIs的引用已经被替换成一个更好的描述，路径部件如何被隐藏在层次中. 相对URI规则已经被替换成 relative-ref 以避免对它是否一个URI的子集产生不必要的混淆. The ambiguity regarding the
+用于URI和URI引用的ABN已经被重新涉及以使它们对LALR解析器更加友好并减少复杂度. 结果是, 语法描述的布局格式已经被移除, 包括 uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path, path_segments, rel_segment, 以及 mark rules. 所有对 "不透明" URIs的引用已经被替换成一个更好的描述，路径部件如何被隐藏在层次中. 相对URI规则已经被替换成 relative-ref 以避免对它是否一个URI的子集产生不必要的混淆. 关于第一个segment中带有冒号的URI引用是解析成一个URI还是一个相对引用的模糊已经被使用五个分离的路径匹配规则解决了.
-   parsing of URI-reference as a URI or a relative-ref with a colon in
-   the first segment has been eliminated through the use of five
-   separate path matching rules.
-   The fragment identifier has been moved back into the section on
+片段标识符已经被移回到通用语法部件章节并包括URI和相对引用规则, 尽管它仍被排除在绝对URI之外. 井号 ("#") 字符已经被移回到保留集合从而重返片段语法.
-   generic syntax components and within the URI and relative-ref rules,
-   though it remains excluded from absolute-URI.  The number sign ("#")
-   character has been moved back to the reserved set as a result of
-   reintegrating the fragment syntax.
-   The ABNF has been corrected to allow the path component to be empty.
+ABNF已经被修正以允许路径部件为空. 这也允许一个绝对URI在 "scheme:" 之后不包含任何东西, 因为目前实践中 "dav:" 命名空间 [http://tools.ietf.org/html/rfc2518 RFC2518] 和 "about:" 格式被很多WWW浏览器实现内部使用. 关于机构和路径之间的边界的模糊已经通过使用五个分离的路径匹配规则解决了.
-   This also allows an absolute-URI to consist of nothing after the
-   "scheme:", as is present in practice with the "dav:" namespace
-   [RFC2518] and with the "about:" scheme used internally by many WWW
-   browser implementations.  The ambiguity regarding the boundary
-   between authority and path has been eliminated through the use of
-   five separate path matching rules.
-   Registry-based naming authorities that use the generic syntax are now
+使用通用语法的基于注册的命名机构现在被定义在主机规则里. 这一变化允许现有的实现, 无论提供了什么名称，都被简单地馈送到本地名称解析机制, 以和协议保持一致. 它也消除了这里重新指定DNS名称格式的需要. 而且, 它允许主机部件包含百分号编码字节, 它是必要的，它使得国际化域名能被URIs提供, 能在URI处理之上的应用层被处理成它们的本地字符编码, 并被以UTF-8字符编码传递给一个IDNA库作为一个注册名称. server, hostport, hostname, domainlabel, toplabel, 和 alphanum 规则已经被移除.
-   defined within the host rule.  This change allows current
-   implementations, where whatever name provided is simply fed to the
-   local name resolution mechanism, to be consistent with the
-   specification.  It also removes the need to re-specify DNS name
-   formats here.  Furthermore, it allows the host component to contain
-   percent-encoded octets, which is necessary to enable
-   internationalized domain names to be provided in URIs, processed in
-   their native character encodings at the application layers above URI
-   processing, and passed to an IDNA library as a registered name in the
-   UTF-8 character encoding.  The server, hostport, hostname,
-   domainlabel, toplabel, and alphanum rules have been removed.
-   The resolving relative references algorithm of [RFC2396] has been
+相对引用解析算法 [http://tools.ietf.org/html/rfc2396 RFC2396] 已经在本修订版被以伪码重写以提高澄清和解决以下问题:
-   rewritten with pseudocode for this revision to improve clarity and
-   fix the following issues:
-−
-−
-−
-Berners-Lee, et al.         Standards Track                    [Page 55]
-−
-RFC 3986                   URI Generic Syntax               January 2005

@@ 第1,199行： / 第1,199行： @@
 </source>
-   Use of the above obsolete rules for the definition of scheme-specific
+以上用于格式特有的语法的定义的过时规则被弃用了.
-   syntax is deprecated.
-   Section 2, on characters, has been rewritten to explain what
+[[RFC3986#字符|第二章]], 在字符方面, 已经重写以解释什么字符是保留的, 什么时候它们被保留, 以及为什么它们被保留, 甚至什么时候它们不被通用语法用作分隔符. 典型的对于解码不安全的标点符号, 包括感叹号 ("!"), 星号 ("*"), 单引号 ("'"), 以及打开和关闭括号 ("(" 和 ")"), 已经被移到保留集合以澄清保留的和非保留的之间的唯一性, 并期望, 解答格式定义者的大部分常见问题. 同样, 百分号编码字节那一章已经被重写, 且URI常规化现在允许解码任何对应非保留字符的百分号字节. 通常, 术语 "escaped" 和 "unescaped" 已经被 "percent-encoded" 和 "decoded" 分别替换, 来减少和其他格式逃逸机制的混淆.
-   characters are reserved, when they are reserved, and why they are
-   reserved, even when they are not used as delimiters by the generic
-   syntax.  The mark characters that are typically unsafe to decode,
-   including the exclamation mark ("!"), asterisk ("*"), single-quote
-   ("'"), and open and close parentheses ("(" and ")"), have been moved
-   to the reserved set in order to clarify the distinction between
-   reserved and unreserved and, hopefully, to answer the most common
-   question of scheme designers.  Likewise, the section on
-   percent-encoded characters has been rewritten, and URI normalizers
-   are now given license to decode any percent-encoded octets
+用于URI和URI引用的ABN已经被重新涉及以使它们对LALR解析器更加友好并减少复杂度. 结果是, 语法描述的布局格式已经被移除, 包括 uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path, path_segments, rel_segment, 以及 mark rules. 所有对 "不透明" URIs的引用已经被替换成一个更好的描述，路径部件如何被隐藏在层次中. 相对URI规则已经被替换成 relative-ref 以避免对它是否一个URI的子集产生不必要的混淆. The ambiguity regarding the
-−
-Berners-Lee, et al.         Standards Track                    [Page 54]
-−
-RFC 3986                   URI Generic Syntax               January 2005
-−
-−
-   corresponding to unreserved characters.  In general, the terms
-   "escaped" and "unescaped" have been replaced with "percent-encoded"
-   and "decoded", respectively, to reduce confusion with other forms of
-   escape mechanisms.
-−
-   The ABNF for URI and URI-reference has been redesigned to make them
-   more friendly to LALR parsers and to reduce complexity.  As a result,
-   the layout form of syntax description has been removed, along with
-   the uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path,
-   path_segments, rel_segment, and mark rules.  All references to
-   "opaque" URIs have been replaced with a better description of how the
-   path component may be opaque to hierarchy.  The relativeURI rule has
-   been replaced with relative-ref to avoid unnecessary confusion over
-   whether they are a subset of URI.  The ambiguity regarding the
     parsing of URI-reference as a URI or a relative-ref with a colon in
     the first segment has been eliminated through the use of five

@@ 第1,157行： / 第1,157行： @@
 [[RFC3986#正规化和比较|第六章]], 在URI正规化和和比较上, 已经完全重写并扩展，使用了来自Tim Bray的输入，以及W3C技术架构组中的讨论.
-===D.2. 修改===
+===D.2. 变更===
-   The ad-hoc BNF syntax of RFC 2396 has been replaced with the ABNF of
+[http://tools.ietf.org/html/rfc2396 RFC 2396]的的特定BNF语法已经被替换成[http://tools.ietf.org/html/rfc2234 RFC2234]的ABNF. 这个变更要求所有以前包含了下划线字符的规则名称被改名为一个长划. 此外, 一些语法规则已经被淘汰或简化以使整体的语法更容易理解. 参考了过时的语法规则的协议可以根据下表替换掉那些规则从而让人可以理解:
-   [RFC2234].  This change required all rule names that formerly
-   included underscore characters to be renamed with a dash instead.  In
-   addition, a number of syntax rules have been eliminated or simplified
-   to make the overall grammar more comprehensible.  Specifications that
-   refer to the obsolete grammar rules may be understood by replacing
-   those rules according to the following table:
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-Berners-Lee, et al.         Standards Track                    [Page 53]
-−
-RFC 3986                   URI Generic Syntax               January 2005
     +----------------+--------------------------------------------------+
@@ 第1,217行： / 第1,196行： @@
     | alphanum       | ALPHA / DIGIT                                    |
     +----------------+--------------------------------------------------+
     Use of the above obsolete rules for the definition of scheme-specific

@@ 第1,147行： / 第1,147行： @@
 ==附录D. 对[http://tools.ietf.org/html/rfc2396 RFC 2396]的改变==
-D.1.  Additions
+===D.1. 添加===
-   An ABNF rule for URI has been introduced to correspond to one common
+引入了一个用于URI的ABNF规则来对应该术语的一个常规用途: 一个带有可选的片段的绝对URI.
-   usage of the term: an absolute URI with optional fragment.
-   IPv6 (and later) literals have been added to the list of possible
+IPv6 (以及后面的) 文字被加到可能的标识符的列表中，用于一个机构部件的主机部分, 如[http://tools.ietf.org/html/rfc2732 RFC2732]所述, 并且在保留设置中留有额外的 "[" 和 "]" ，以及一个版本标记给预期的IP文字的未来版本. 在机构部件中方括号现在被定义成保留的并且不允许把它们用作一个主机的IP文字的分隔符来用. 为了实现这个改变而不用修改路径,查询,和片段部件的技术定义, 那些规则被重定义成直接定义允许的字符集.
-   identifiers for the host portion of an authority component, as
-   described by [RFC2732], with the addition of "[" and "]" to the
-   reserved set and a version flag to anticipate future versions of IP
-   literals.  Square brackets are now specified as reserved within the
-   authority component and are not allowed outside their use as
-   delimiters for an IP literal within host.  In order to make this
-   change without changing the technical definition of the path, query,
-   and fragment components, those rules were redefined to directly
-   specify the characters allowed.
-   As [RFC2732] defers to [RFC3513] for definition of an IPv6 literal
+因为[http://tools.ietf.org/html/rfc2732 RFC2732]为了一个IPv6文字地址而推迟到[http://tools.ietf.org/html/rfc3513 RFC3513], 它很不幸的缺少了一个IPv6地址的ABNF描述, 我们为IPv6地址创建了一个新的ABNF规则来匹配[http://tools.ietf.org/html/rfc3513#section-2.2 RFC3513的2.2章]定义的文本展示. 同样的, IPv4地址的定义已经被提升以限制每个十进制字节的范围在0-255.
-   address, which, unfortunately, lacks an ABNF description of
-   IPv6address, we created a new ABNF rule for IPv6address that matches
-   the text representations defined by Section 2.2 of [RFC3513].
-   Likewise, the definition of IPv4address has been improved in order to
-   limit each decimal octet to the range 0-255.
-   Section 6, on URI normalization and comparison, has been completely
+[[RFC3986#正规化和比较|第六章]], 在URI正规化和和比较上, 已经完全重写并扩展，使用了来自Tim Bray的输入，以及W3C技术架构组中的讨论.
-   rewritten and extended by using input from Tim Bray and discussion
-   within the W3C Technical Architecture Group.
-D.2.  Modifications
+===D.2. 修改===
     The ad-hoc BNF syntax of RFC 2396 has been replaced with the ABNF of

@@ 第1,108行： / 第1,108行： @@
 ==附录C. 在上下文中限定一个URI==
-URIs经常被发送的格式没有提供为它们的解释提供清晰的上下文.  For example, there are many
+URIs经常被发送的格式没有提供为它们的解释提供清晰的上下文. 例如, 很多情况下一个URi被包含在纯文本中; 例如包含在email, USENET新闻, 和 打印的纸张的文本中发送. 在每种情况下, 重要的是能限定从文本的其他部分, 特别是对该URi中可能被误解的部分的标点符号来限定该URI.
-   occasions when a URI is included in plain text; examples include text
-   sent in email, USENET news, and on printed paper.  In such cases, it
-   is important to be able to delimit the URI from the rest of the text,
-   and in particular from punctuation marks that might be mistaken for
-   part of the URI.
-−
-   In practice, URIs are delimited in a variety of ways, but usually
-   within double-quotes "http://example.com/", angle brackets
-   <http://example.com/>, or just by using whitespace:
-−
-−
-−
-Berners-Lee, et al.         Standards Track                    [Page 51]
-−
-RFC 3986                   URI Generic Syntax               January 2005
        http://example.com/
-   These wrappers do not form part of the URI.
+这些封装不是该URI格式的一部分.
-   In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may
+在某些情况下, 可能不得不添加额外的空白(空格, 换行符, tabs符, 等等)来打断一个跨行的长URI. 当该URI被提取的时候空白应该被忽略.
-   have to be added to break a long URI across lines.  The whitespace
-   should be ignored when the URI is extracted.
-   No whitespace should be introduced after a hyphen ("-") character.
+空白不应该被放在一个连字符("-")符号后面. 因为一些排版和打印机可能(错误地)在中断它的时候把一个连字符放在行的末尾, 一个URI对于在一个连字符后面立刻包含一个行中断的解释应该忽略所有行中断附近的空白并且应该注意连字符可能或可能不一定是该URI的一部分.
-   Because some typesetters and printers may (erroneously) introduce a
-   hyphen at the end of line when breaking it, the interpreter of a URI
-   containing a line break immediately after a hyphen should ignore all
-   whitespace around the line break and should be aware that the hyphen
-   may or may not actually be part of the URI.
-   Using <> angle brackets around each URI is especially recommended as
+特别推荐在每个URI附近使用 <> 尖括号作为对一个包含了内嵌空白的引用的一个限定样式.
-   a delimiting style for a reference that contains embedded whitespace.
-   The prefix "URL:" (with or without a trailing space) was formerly
+前缀 "URL:" (携带或不带一个尾随的空格) 是以前推荐的一个帮助从其他括号代号中识别出一个URI的方法, 尽管在实践中它不经常被使用并且不再被推荐了.
-   recommended as a way to help distinguish a URI from other bracketed
-   designators, though it is not commonly used in practice and is no
-   longer recommended.
-   For robustness, software that accepts user-typed URI should attempt
+为了鲁棒性, 接受用户手工输入URI的软件应该尝试识别和剔出分隔符和内嵌的空白.
-   to recognize and strip both delimiters and embedded whitespace.
-   For example, the text
+例如, 文本
        Yes, Jim, I found it under "http://www.w3.org/Addressing/",
        but you can probably pick it up from <ftp://foo.example.
        com/rfc/>.  Note the warning in <http://www.ics.uci.edu/pub/
        ietf/uri/historical.html#WARNING>.
-   contains the URI references
+包含URI引用
        http://www.w3.org/Addressing/
        ftp://foo.example.com/rfc/
        http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING
+==附录D. 对[http://tools.ietf.org/html/rfc2396 RFC 2396]的改变==
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-−
-Berners-Lee, et al.         Standards Track                    [Page 52]
-−
-RFC 3986                   URI Generic Syntax               January 2005
-−
-−
-Appendix D.  Changes from RFC 2396
 D.1.  Additions