网络工作组 M. Duerst
征求意见稿：3987 W3C
类别：标准轨道 M. Suignard
Microsoft Corporation
2005 年 1 月
国际化资源标识符（IRIs）
本备忘录状态
本文档为 Internet 社区规定了一项 Internet 标准轨道协议，
并请求讨论和改进建议。关于本协议的标准化阶段和状态，
请参阅当前版本的“Internet 官方协议标准”（STD 1）。
本备忘录的分发不受限制。
Copyright Notice
Copyright (C) The Internet Society (2005).
摘要
本文档定义了一种新的协议元素：国际化资源标识符（IRI），
作为统一资源标识符（URI）的补充。IRI 是来自通用字符集
（Unicode/ISO 10646）的一串字符。本文定义了从 IRI 到 URI
的映射，这意味着在适当情况下，可以使用 IRI 代替 URI 来
标识资源。
选择定义一种新的协议元素，而不是扩展或更改 URI 的定义。
这样做是为了允许清晰地区分，并避免与现有软件不兼容。
本文还为在目前处理 URI 的各种协议、格式和软件组件中
使用和部署 IRI 提供了指南。
目录
1. 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 概述与动机 . . . . . . . . . . . . . . . . . . . . . 3
1.2. 适用性 . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. 定义 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. 记法 . . . . . . . . . . . . . . . . . . . . . . . . 5
2. IRI 语法 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. IRI 语法概要 . . . . . . . . . . . . . . . . . . . . 6
2.2. IRI 引用和 IRI 的 ABNF . . . . . . . . . . . . . . . . 7
Duerst & Suignard 标准轨道 [第 1 页]
RFC 3987 国际化资源标识符 2005 年 1 月
3. IRI 与 URI 的关系 . . . . . . . . . . . . . . . . . . . . . 10
3.1. IRI 到 URI 的映射 . . . . . . . . . . . . . . . . . 10
3.2. 将 URI 转换为 IRI . . . . . . . . . . . . . . . . . 14
3.2.1. 示例 . . . . . . . . . . . . . . . . . . . . . 15
4. 用于从右向左语言的双向 IRI. . . . . . . . . . . . . . . 16
4.1. 逻辑存储和视觉呈现 . . . . . . . . . . . . . . . . . 17
4.2. 双向 IRI 结构 . . . . . . . . . . . . . . . . . . . . 18
4.3. 双向 IRI 的输入 . . . . . . . . . . . . . . . . . . . 19
4.4. 示例 . . . . . . . . . . . . . . . . . . . . . . . . 19
5. 规范化与比较 . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. 等价性 . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. 比较前的准备 . . . . . . . . . . . . . . . . . . . . 22
5.3. 比较阶梯 . . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. 简单字符串比较 . . . . . . . . . . . . . . . . 23
5.3.2. 基于语法的规范化 . . . . . . . . . . . . . . . 24
5.3.3. 基于方案的规范化 . . . . . . . . . . . . . . . 27
5.3.4. 基于协议的规范化 . . . . . . . . . . . . . . . 28
6. IRI 的使用 . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. IRI 中允许的 UCS 字符限制 . . . . . . . . . . . . . 29
6.2. 软件接口和协议 . . . . . . . . . . . . . . . . . . . 29
6.3. 文档和协议中 URI 与 IRI 的格式 . . . . . . . . . . . 30
6.4. 使用 UTF-8 对原始字符进行编码 .. . . . . . . . . . 30
6.5. 相对 IRI 引用 . . . . . . . . . . . . . . . . . . . . 32
7. URI/IRI 处理指南（资料性） . . . . . . . . . . . . . . . . 32
7.1. URI/IRI 软件接口 . . . . . . . . . . . . . . . . . . 32
7.2. URI/IRI 输入 . . . . . . . . . . . . . . . . . . . . 33
7.3. URI/IRI 在应用之间的传递 . . . . . . . . . . . . . 33
7.4. URI/IRI 生成 . . . . . . . . . . . . . . . . . . . . 34
7.5. URI/IRI 选择 . . . . . . . . . . . . . . . . . . . . 34
7.6. URI/IRI 显示 . . . . . . . . . . . . . . . . . . . . 35
7.7. URI 和 IRI 的解释 . . . . . . . . . . . . . . . . . 36
7.8. 升级策略 . . . . . . . . . . . . . . . . . . . . . . 36
8. 安全考虑 . . . . . . . . . . . . . . . . . . . . . . . . . 37
9. 致谢 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. 规范性引用 . . . . . . . . . . . . . . . . . . . . . 40
10.2. 资料性引用 . . . . . . . . . . . . . . . . . . . . . 41
A. 设计替代方案 . . . . . . . . . . . . . . . . . . . . . . . 44
A.1. 新方案 . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. UTF-8 以外的字符编码 . . . . . . . . . . . . . . . . 44
A.3. 新的编码约定 . . . . . . . . . . . . . . . . . . . . 44
A.4. 在 URI/IRI 中指示字符编码 . . . . . . . . . . . . . 45
作者地址 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
完整版权声明 . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Duerst & Suignard 标准轨道 [第 2 页]
RFC 3987 国际化资源标识符 2005 年 1 月
1. 引言
1.1. 概述与动机
统一资源标识符（URI）在 [RFC3986] 中被定义为一串
从 US-ASCII [ASCII] 字符表的有限子集中选取的字符。
URI 中的字符经常用于表示自然语言中的词语。这种用法有
许多优点：这样的 URI 更容易记忆、更容易解释、更容易转写、
更容易创建，也更容易猜测。然而，对于英语以外的大多数语言，
其自然书写系统使用的字符并不限于 A -
Z。对许多人来说，处理拉丁字符的困难程度，就像只使用
拉丁字母的人处理其他文字的字符一样。许多使用非拉丁文字的
语言会用拉丁字母转写。这些转写如今常常用于 URI，但它们
会引入额外的歧义。
适当处理本地文字字符的基础设施，现在已广泛部署在操作系统
和应用软件的本地化版本中。能够同时处理多种文字和语言的
软件也越来越普遍。此外，越来越多的协议和格式能够承载
大范围的字符。
本文档通过将 URI 语法扩展到更宽广的字符表，定义了一种
称为国际化资源标识符（IRI）的新协议元素。它还定义了与
[RFC3986] 中其他构造相对应的“国际化”版本，例如
URI 引用。IRI 的语法在第 2 节定义，IRI 与 URI 的关系在
第 3 节定义。
在 IRI 中使用 A - Z 以外的字符会带来一些困难。
第 4 节讨论双向 IRI 的特殊情况，第 5 节讨论
IRI 之间的各种等价形式，第 6 节讨论 IRI 在不同情况下的使用。
第 7 节给出附加的资料性指南，第 8 节给出安全考虑。
1.2. 适用性
IRI 被设计为与新 URI 方案的建议 [RFC2718] 兼容。这种兼容性
通过规定一种明确定义且确定性的映射来提供，该映射把 IRI
字符序列映射为功能上等价的 URI 字符序列。在实际使用中，
用 IRI（或 IRI 引用）代替 URI（或 URI 引用）取决于是否满足
以下条件：
Duerst & Suignard 标准轨道 [第 3 页]
RFC 3987 国际化资源标识符 2005 年 1 月
a. 协议或格式元素应被明确指定为能够承载 IRI。其意图并不是
将 IRI 引入那些未定义为接受 IRI 的上下文中。例如，XML
schema [XMLSchema] 有一个显式类型 "anyURI"，它包括
IRI 和 IRI 引用。因此，IRI 和 IRI 引用可以出现在类型为
"anyURI" 的属性和元素中。另一方面，在 HTTP 协议
[RFC2616] 中，Request URI 被定义为 URI，这意味着
在 HTTP 请求中不允许直接使用 IRI。
b. 承载 IRI 的协议或格式应具有一种机制，以表示 IRI 中使用的
大范围字符；这种机制可以是原生表示，也可以是某种特定于
协议或格式的转义机制（例如 [XML1] 中的数字字符引用）。
c. 与所讨论 IRI 对应的 URI 必须使用 UTF-8 将原始字符编码为
八位字节。对于新的 URI 方案，[RFC2718] 中建议这样做。
这可以适用于整个方案（例如 IMAP URL [RFC2192] 和 POP URL
[RFC2384]，或 URN 语法 [RFC2141]）。它也可以适用于 URI
的某一特定部分，例如片段标识符（例如 [XPointer]）。它还
可以适用于特定 URI 或其一个或多个部分。详情请参见
第 6.4 节。
1.3. 定义
本文档使用以下定义；这些定义遵循 [RFC2130]、
[RFC2277] 和 [ISO10646] 中的术语。
character: 用于组织、控制或表示数据的一组元素中的一个成员。
例如，"LATIN CAPITAL LETTER A" 命名了一个字符。
octet: 被视为一个单元的有序八位序列。
character repertoire: 一组字符（从数学意义上说）。
sequence of characters: 字符序列（一个接一个）。
sequence of octets: 八位字节序列（一个接一个）。
character encoding: 将字符序列表示为八位字节序列的方法
（可能带有变体）。也指将八位字节序列（无歧义地）转换为
字符序列的方法。
Duerst & Suignard 标准轨道 [第 4 页]
RFC 3987 国际化资源标识符 2005 年 1 月
charset: 用于标识字符编码的参数或属性的名称。
UCS: 通用字符集。由 ISO/IEC 10646 [ISO10646] 和 Unicode
标准 [UNIV4] 定义的编码字符集。
IRI reference: 表示国际化资源标识符的常见用法。IRI 引用可以是
绝对的，也可以是相对的。然而，由这种引用得到的 "IRI"
只包括绝对 IRI；任何相对 IRI 引用都会解析为其绝对形式。
注意，在 [RFC2396] 中，URI 不包括片段标识符，但在
[RFC3986] 中，片段标识符是 URI 的一部分。
running text: 具有自然语言正字法约定语法的人类文本
（段落、句子、短语），与为便于机器处理而定义的语法相对
（例如标记、编程语言）。
protocol element: 消息中会影响相关协议处理该消息的任何部分。
presentation element: 与协议元素相对应的呈现形式；例如使用更宽的
字符范围。
create (a URI or IRI): 就 URI 和 IRI 而言，该术语用于初始创建。
这可以是带有某个标识符的资源的初始创建，也可以是资源在
某个特定标识符下的初始公开。
generate (a URI or IRI): 就 URI 和 IRI 而言，该术语用于 IRI
从其他信息派生生成的情况。
1.4. 记法
RFC 和 Internet 草案目前不允许使用 US-ASCII 字符表之外的
任何字符。因此，本文档在示例中使用各种特殊记法来表示
这些字符。
在正文中，US-ASCII 以外的字符有时通过前缀 'U+' 加上
四到六个十六进制数字来引用。
为了在示例中表示 US-ASCII 以外的字符，本文档使用两种记法：
'XML Notation' 和 'Bidi Notation'。
Duerst & Suignard 标准轨道 [第 5 页]
RFC 3987 国际化资源标识符 2005 年 1 月
XML Notation 使用前导的 '&#x'、尾随的 ';'，中间放置该字符在
UCS 中的十六进制数。例如，я 表示 CYRILLIC CAPITAL
LETTER YA。在这种记法中，实际的 '&' 表示为 '&'。
Bidi Notation 用于双向文本示例：小写字母表示从左向右书写的
拉丁字母或其他字母，而大写字母表示从右向左书写的阿拉伯
字母或希伯来字母。
为了在示例中表示实际八位字节（而不是百分号编码的八位字节），
表示八位字节的两个十六进制数字被括在 "<" 和 ">" 中。
例如，通常表示为 0xc9 的八位字节在这里表示为 <c9>。
在本文档中，关键词 "MUST"、"MUST NOT"、"REQUIRED"、
"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、
"MAY" 和 "OPTIONAL" 应按 [RFC2119] 中所述进行解释。
2. IRI 语法
本节定义国际化资源标识符（IRI）的语法。
与 URI 一样，IRI 被定义为字符序列，而不是八位字节序列。
该定义适应了这样一个事实：IRI 既可以写在纸上或通过无线电
读出，也可以以数字方式存储或传输。如果不同协议或文档使用
不同的字符编码（和/或传输编码），同一个 IRI 可以在这些
不同协议或文档中表示为不同的八位字节序列。使用与包含它的
协议或文档相同的字符编码，可以确保 IRI 中的字符能够以与
该协议或文档其余部分相同的方式处理（例如搜索、转换、显示）。
2.1. IRI 语法概要
IRI 的定义类似于 [RFC3986] 中的 URI，但通过加入 U+007F
之外的 UCS（通用字符集，[ISO10646]）字符，扩展了
非保留字符类，并受限于下面语法规则和第 6.1 节中给出的
限制。
除此之外，组件和保留字符的语法与使用方式与 [RFC3986] 中
相同。[RFC3986] 中定义的所有操作，例如相对引用的解析，都可以由
IRI 处理软件以与 URI 处理软件处理 URI 完全相同的方式应用于
IRI。
Duerst & Suignard 标准轨道 [第 6 页]
RFC 3987 国际化资源标识符 2005 年 1 月
US-ASCII 字符表之外的字符不是保留字符，因此 MUST NOT 用于
语法目的，例如在新定义的方案中分隔组件。例如，U+00A2，
CENT SIGN，不能作为 IRI 中的分隔符，因为它属于
'iunreserved' 类别。这类似于在 URI 中不能将 '-' 用作分隔符，
因为它属于 'unreserved' 类别这一事实。
2.2. IRI 引用和 IRI 的 ABNF
虽然也许可以仅通过它们到 URI 引用和 URI 的转换来定义 IRI
引用和 IRI，但它们也可以被直接接受和处理。因此，这里给出
IRI 引用（它们是最一般的概念，也是文法的起点）和 IRI 的
ABNF 定义。该 ABNF 的语法在 [RFC2234] 中描述。字符编号取自
UCS，但不暗示任何实际的二进制编码。ABNF 中的终结符是字符，
而不是字节。
以下文法紧密遵循 [RFC3986] 中的 URI 文法，不同之处在于
非保留字符的范围被扩展为包括 UCS 字符，并限制私用 UCS 字符
只能出现在查询部分。该文法分为两部分：因上述扩展而与
[RFC3986] 不同的规则，以及与 [RFC3986] 中相同的规则。对于
与 [RFC3986] 不同的规则，非终结符的名称按如下方式更改。
如果非终结符包含 'URI'，则将其改为 'IRI'。否则，在其前面
加上 'i'。
以下规则不同于 [RFC3986] 中的规则：
IRI = scheme ":" ihier-part [ "?" iquery ]
[ "#" ifragment ]
ihier-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-rootless
/ ipath-empty
IRI-reference = IRI / irelative-ref
absolute-IRI = scheme ":" ihier-part [ "?" iquery ]
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute
Duerst & Suignard 标准轨道 [第 7 页]
RFC 3987 国际化资源标识符 2005 年 1 月
/ ipath-noscheme
/ ipath-empty
iauthority = [ iuserinfo "@" ] ihost [ ":" port ]
iuserinfo = *( iunreserved / pct-encoded / sub-delims / ":" )
ihost = IP-literal / IPv4address / ireg-name
ireg-name = *( iunreserved / pct-encoded / sub-delims )
ipath = ipath-abempty ; 以 "/" 开始或为空
/ ipath-absolute ; 以 "/" 开始但不是 "//"
/ ipath-noscheme ; 以非冒号段开始
/ ipath-rootless ; 以一个段开始
/ ipath-empty ; 零个字符
ipath-abempty = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar>
isegment = *ipchar
isegment-nz = 1*ipchar
isegment-nz-nc = 1*( iunreserved / pct-encoded / sub-delims
/ "@" )
; 不含任何冒号 ":" 的非零长度段
ipchar = iunreserved / pct-encoded / sub-delims / ":"
/ "@"
iquery = *( ipchar / iprivate / "/" / "?" )
ifragment = *( ipchar / "/" / "?" )
iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD
有些产生式是有歧义的。适用“first-match-wins”（又称
“greedy”）算法。详情见 [RFC3986]。
Duerst & Suignard 标准轨道 [第 8 页]
RFC 3987 国际化资源标识符 2005 年 1 月
以下规则与 [RFC3986] 中的规则相同：
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
port = *DIGIT
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
此语法不支持 IPv6 作用域寻址区域标识符。
Duerst & Suignard 标准轨道 [第 9 页]
RFC 3987 国际化资源标识符 2005 年 1 月
3. IRI 与 URI 的关系
IRI 旨在为使用基于 UCS 的字符表的协议、格式和软件组件，在
标识资源时取代 URI。这些协议和组件可能永远不需要直接使用
URI，尤其是在资源标识符仅用于标识目的时。然而，当资源标识符
用于资源检索时，在许多情况下有必要确定关联的 URI，因为目前
大多数检索机制只为 URI 定义。在这种情况下，IRI 可以作为
URI 协议元素的呈现元素。一个例子是 Web 用户代理中的地址栏。
（其他理由见第 3.1 节。）
3.1. IRI 到 URI 的映射
本节定义如何将 IRI 映射到 URI。本节中的所有内容同样适用于
IRI 引用和 URI 引用，以及它们的组件（例如片段标识符）。
此映射有两个目的：
语法性的。许多 URI 方案和组件定义了第 2.2 节未涵盖的
附加语法限制。通过将 IRI 转换为 URI，并根据特定方案的
限制检查该 URI，将特定方案的限制应用于 IRI。
解释性的。URI 以各种方式标识资源。IRI 也标识资源。当 IRI
仅用于标识目的时，没有必要将 IRI 映射到 URI（见第 5 节）。
然而，当 IRI 用于资源检索时，IRI 所定位的资源与按照这里
定义的过程转换 IRI 后得到的 URI 所定位的资源相同。这意味着
不需要在 IRI 层面单独定义解析。
应用程序 MUST 使用以下两个步骤将 IRI 映射到 URI。
步骤 1. 从原始 IRI 格式生成 UCS 字符序列。此步骤根据输入
形式有以下三种变体：
a. 如果 IRI 写在纸上、被朗读，或以其他任何与字符编码
无关的字符序列形式表示，则将该 IRI 表示为来自 UCS、
并按照规范化形式 C（NFC，[UTR15]）规范化的
字符序列。
Duerst & Suignard 标准轨道 [第 10 页]
RFC 3987 国际化资源标识符 2005 年 1 月
b. 如果 IRI 处于某种数字表示形式（例如八位字节流）中，
并采用某种已知的非 Unicode 字符编码，则将该 IRI
转换为来自 UCS、并按照 NFC 规范化的字符序列。
c. 如果 IRI 处于基于 Unicode 的字符编码中（例如 UTF-8
或 UTF-16），则不要规范化（详情见第
5.3.2.2 节）。直接对已编码的 Unicode 字符序列应用
步骤 2。
步骤 2. 对 'ucschar' 或 'iprivate' 中的每个字符，应用下面的
步骤 2.1 到 2.3。
2.1. 使用 UTF-8 [RFC3629] 将该字符转换为一个或多个八位字节
的序列。
2.2. 将每个八位字节转换为 %HH，其中 HH 是该八位字节值的
十六进制表示。注意，这与 [RFC3986] 第 2.1 节中的
百分号编码机制相同。为减少可变性，十六进制表示
SHOULD 使用大写字母。
2.3. 用生成的字符序列（即 %HH 三元组序列）替换原始字符。
上述从 IRI 到 URI 的映射会产生完全符合 [RFC3986] 的 URI。
对 URI 而言，该映射也是恒等变换，并且是幂等的；第二次应用
该映射不会改变任何内容。每个 URI 按定义都是一个 IRI。
接受 IRI 的系统 MAY 按如下方式转换 IRI 的 ireg-name 组件
（在上述步骤 2 之前），适用于已知在 ireg-name 中使用域名、
且其方案定义不允许 ireg-name 使用百分号编码的方案：
将 IRI 的 ireg-name 部分替换为如下转换后的部分：对每个以点
分隔的标签使用 [RFC3490] 第 4.1 节中规定的 ToASCII 操作，
并使用 U+002E（FULL STOP）作为标签分隔符，UseSTD3ASCIIRules
标志设为 TRUE，并且在创建 IRI 时 AllowUnassigned 标志设为
FALSE，其他情况下设为 TRUE。
Duerst & Suignard 标准轨道 [第 11 页]
RFC 3987 国际化资源标识符 2005 年 1 月
ToASCII 操作可能失败，但这意味着该 IRI 无法被解析。当目标是
最大化与旧式 URI 解析器的互操作性时，SHOULD 使用这种转换。
例如，IRI
"http://résumé.example.org"
可以转换为
"http://xn--rsum-bpad.example.org"
而不是
"http://r%C3%A9sum%C3%A9.example.org"。
如果某个 IRI 的方案已知在 ireg-name 中使用域名，但该方案定义
不允许 ireg-name 使用百分号编码，则当直接转换或使用 ToASCII
操作对 ireg-name 进行转换后得到的 URI 满足特定方案限制时，
该 IRI 即满足特定方案的限制。
这样的 IRI 会解析为转换该 IRI 并在 ireg-name 上使用 ToASCII
操作后得到的 URI。只要实现能产生相同的结果，就不必实际执行
此转换。
注意：步骤 1 中变体 b 和 c 的差异（使用 NFC 规范化，还是不使用
任何规范化）解释了这样一个事实：在许多非 Unicode 字符编码中，
某些文本无法直接表示。例如，单词 "Vietnam" 在原文中写作
"Việt Nam"（包含一个 LATIN SMALL LETTER E WITH CIRCUMFLEX
AND DOT BELOW），采用 NFC；但从 windows-1258 字符编码直接
转码会得到 "Việt Nam"（包含一个 LATIN SMALL
LETTER E WITH CIRCUMFLEX 后跟一个 COMBINING DOT BELOW）。
越南语的其他 8 位编码的直接转码可能会得到其他表示。
注意：在步骤 2 中统一处理整个 IRI 非常重要，这可以使处理过程
独立于 URI 方案。深入讨论见 [Gettys]。
注意：在实践中，如果从 IRI 到 URI 的映射和解析是紧密集成的
（例如在同一个用户代理中执行），则对 ireg-name 使用一般映射
（步骤 1 和 2）还是使用 [RFC3490] 的 ToASCII 操作，通常不会
被注意到。但是
Duerst & Suignard 标准轨道 [第 12 页]
RFC 3987 国际化资源标识符 2005 年 1 月
使用 [RFC3490] 的转换，在映射和解析分离的情况下，
例如使用 HTTP 代理时，也许能够更好地处理向后兼容性问题。
注意：国际化域名可能包含在 IRI 中 ireg-name 部分以外的其他
部分中。由特定方案的实现（如果国际化域名是方案语法的一部分）
或服务器端实现（如果国际化域名是 'iquery' 的一部分）负责在
适当位置应用必要的转换。示例：尝试验证位于
http://résumé.example.org 的网页，会得到一个 IRI：
http://validator.w3.org/check?uri=http%3A%2F%2Frésumé.
example.org，它会转换为一个 URI：
http://validator.w3.org/check?uri=http%3A%2F%2Fr%C3%A9sum%C3%A9.
example.org。服务器端实现将负责执行必要的转换，以便能够
检索该网页。
接受 IRI 的系统 MAY 也在上述步骤 2 中处理那些可打印的、
但 URI 中不允许的 US-ASCII 字符，即 "<"、">"、'"'、空格、
"{"、"}"、"|"、"\"、"^" 和 "`"。如果发现这些字符但未被转换，
则转换 SHOULD 失败。请注意，数字符号（"#"）、百分号（"%"）
和方括号字符（"["、"]"）不属于上述列表，并且 MUST NOT 被转换。
曾经使用包含这些字符的早期 IRI 定义的协议和格式 MAY 要求将
这些字符作为预处理步骤进行百分号编码，以便从给定字段中提取
实际的 IRI。允许用户输入 IRI 的应用程序 MAY 也使用这种预处理。
注意：在此过程中（步骤 2.3），URI 引用中允许的字符和现有的
百分号编码序列不会被进一步编码。（这种映射类似于但不同于
将任意内容包含到 URI 某个部分时所应用的编码。）例如，
XML 记法中的 IRI
"http://www.example.org/red%09rosé#red"
会转换为
"http://www.example.org/red%09ros%C3%A9#red"，而不是类似
"http%3A%2F%2Fwww.example.org%2Fred%2509ros%C3%A9%23red"
这样的形式。
注意：一些较旧的软件在转码为 UTF-8 时，可能会对某些输入产生
非法输出，特别是 BMP（基本多文种平面）之外的字符。例如，
对于包含非 BMP 字符的 IRI（XML Notation 中）：
"http://example.com/𐌀𐌁𐌂";
Duerst & Suignard 标准轨道 [第 13 页]
RFC 3987 国际化资源标识符 2005 年 1 月
其中包含古意大利字母表的前三个字母，正确转换为 URI 是
"http://example.com/%F0%90%8C%80%F0%90%8C%81%F0%90%8C%82"
3.2. 将 URI 转换为 IRI
在某些情况下，可能需要将 URI 转换为等价的 IRI。本节给出
这种转换的过程。本节描述的转换始终会得到一个 IRI，该 IRI
会映射回作为转换输入的 URI（但百分号编码中的大小写差异、
以及可能存在的百分号编码非保留字符除外）。然而，此转换得到的
IRI 可能与原始 IRI（如果曾经存在）并不完全相同。
URI 到 IRI 的转换会移除百分号编码，但并非所有百分号编码都能
被消除。原因有几个：
1. 有些百分号编码是必要的，用于区分保留字符的百分号编码使用
与未编码使用。
2. 有些百分号编码不能解释为 UTF-8 八位字节序列。
（注意：UTF-8 的八位字节模式高度规则。因此，能够解释为
UTF-8 八位字节序列的百分号编码，实际上源自 UTF-8 的概率
非常高，但并无保证。详细讨论见 [Duerst97]。）
3. 这种转换可能得到一个不适合用于 IRI 的字符。更多细节见
2.2、4.1 和 6.1 节。
从 URI 到 IRI 的转换使用以下步骤完成（或使用任何能产生相同
结果的其他算法）：
1. 将 URI 表示为 US-ASCII 中的八位字节序列。
2. 将所有百分号编码（"%" 后跟两个十六进制数字）转换为对应的
八位字节，但对应于 "%"、"reserved" 中的字符，以及 URI 中
不允许的 US-ASCII 字符的百分号编码除外。
3. 重新对步骤 2 产生的、但不属于严格合法 UTF-8 八位字节序列的
任何八位字节进行百分号编码。
Duerst & Suignard 标准轨道 [第 14 页]
RFC 3987 国际化资源标识符 2005 年 1 月
4. 重新对步骤 3 产生的、并且在 UTF-8 中表示按照
2.2、4.1 和 6.1 节不适合的字符的所有八位字节进行
百分号编码。
5. 将所得八位字节序列解释为以 UTF-8 编码的字符序列。
此过程会尽可能多地将百分号编码字符转换为 IRI 中的字符。
由于应用步骤 4 时存在一些选择（见第 6.1 节），结果可能
会有所不同。
从 URI 到 IRI 的转换，在步骤 3 和 4 中 MUST NOT 使用 UTF-8
以外的任何字符编码，即使可能从上下文推测出 URI 中使用了
UTF-8 以外的某种字符编码也是如此。例如，URI
"http://www.example.org/r%E9sum%E9.html" 在某种猜测下可能被
解释为包含两个以 iso-8859-1 编码的 e-acute 字符。它不得转换为
包含这些 e-acute 字符的 IRI。否则，将来该 IRI 会被映射为
"http://www.example.org/r%C3%A9sum%C3%A9.html"，这是一个不同于
"http://www.example.org/r%E9sum%E9.html" 的 URI。
3.2.1. 示例
本节展示将 URI 转换为 IRI 的各种示例。每个示例都显示应用
步骤 1 到 5 中每个步骤后的结果。最终结果使用 XML Notation。
八位字节用 "<" 后跟两个十六进制数字再跟 ">" 表示。
以下示例包含序列 "%C3%BC"，它是一个严格合法的 UTF-8 序列，
并会转换为实际字符 U+00FC，LATIN SMALL LETTER U WITH DIAERESIS
（也称为 u-umlaut）。
1. http://www.example.org/D%C3%BCrst
2. http://www.example.org/D<c3><bc>rst
3. http://www.example.org/D<c3><bc>rst
4. http://www.example.org/D<c3><bc>rst
5. http://www.example.org/Dürst
以下示例包含序列 "%FC"，它可能表示 iso-8859-1 字符编码中的
U+00FC，LATIN SMALL LETTER U WITH DIAERESIS。（它也可能表示
其他字符编码中的其他字符。例如，iso-8859-5 中的八位字节
<fc> 表示 U+045C，CYRILLIC SMALL LETTER KJE。）由于
Duerst & Suignard 标准轨道 [第 15 页]
RFC 3987 国际化资源标识符 2005 年 1 月
<fc> 不是严格合法 UTF-8 序列的一部分，因此它会在步骤 3 中
被重新进行百分号编码。
1. http://www.example.org/D%FCrst
2. http://www.example.org/D<fc>rst
3. http://www.example.org/D%FCrst
4. http://www.example.org/D%FCrst
5. http://www.example.org/D%FCrst
以下示例包含 "%e2%80%ae"，它是 U+202E RIGHT-TO-LEFT OVERRIDE
的百分号编码 UTF-8 字符编码。第 4.1 节禁止在 IRI 中直接使用
此字符。因此，对应的八位字节会在步骤 4 中被重新进行百分号
编码。该示例表明，百分号编码中使用的字母大小写可能不会被保留。
该示例还包含一个 punycode 编码的域名标签（xn--99zt52a），它不会
被转换。
1. http://xn--99zt52a.example.org/%e2%80%ae
2. http://xn--99zt52a.example.org/<e2><80><ae>
3. http://xn--99zt52a.example.org/<e2><80><ae>
4. http://xn--99zt52a.example.org/%E2%80%AE
5. http://xn--99zt52a.example.org/%E2%80%AE
具有特定方案知识的实现 MAY 使用 ToUnicode 过程，将 punycode
编码的域名标签转换为对应字符。因此，对于上面的示例，标签
"xn--99zt52a" 可以转换为 U+7D0D U+8C46（日语 Natto），从而得到
整体 IRI：
"http://納豆.example.org/%E2%80%AE"。
4. 用于从右向左语言的双向 IRI
一些 UCS 字符，例如阿拉伯文字和希伯来文字中使用的字符，
具有固有的从右向左（rtl）书写方向。包含这些字符的 IRI
（称为双向 IRI 或 Bidi IRI）需要额外注意，因为逻辑表示
（用于数字表示和阅读/拼写）与视觉表示（用于显示/打印）
之间存在并不简单的关系。
Duerst & Suignard 标准轨道 [第 16 页]
RFC 3987 国际化资源标识符 2005 年 1 月
由于 Bidi IRI 的逻辑表示、视觉表示和语法之间存在复杂交互，
需要在各种要求之间取得平衡。主要要求是：
1. 用户可预测的视觉表示与逻辑表示之间的转换；
2. 能够在 IRI 的各个部分中包含大范围字符；以及
3. 对实现做出很小的更改或限制，或不做更改和限制。
4.1. 逻辑存储和视觉呈现
当以数字表示形式存储或传输时，双向 IRI MUST 使用完整的逻辑
顺序，并且 MUST 符合 IRI 语法规则（包括与其方案相关的规则）。
这确保双向 IRI 能够以与其他 IRI 相同的方式处理。
双向 IRI MUST 使用 Unicode 双向算法 [UNIV4]、[UNI9] 呈现。双向 IRI
MUST 以与其处于从左向右嵌入中时相同的方式呈现；即，仿佛在其
前面有 U+202A LEFT-TO-RIGHT EMBEDDING（LRE），后面有 U+202C
POP DIRECTIONAL FORMATTING（PDF）。设置嵌入方向也可以在更高层
协议中完成（例如 HTML 中的 dir='ltr' 属性）。
如果没有上述嵌入时显示结果仍然相同，则没有要求使用该嵌入。
例如，在具有从左向右基础方向性的文本（例如英语或西里尔文所用）
中，若双向 IRI 前后有空白和强从左向右字符，则不需要嵌入。
此外，如果双向相对 IRI 引用只包含强从右向左字符和弱字符，
并且以强从右向左字符开始和结束，出现在具有从右向左基础方向性
的文本中（例如阿拉伯语或希伯来语所用），且前后有空白和强字符，
也不需要嵌入。
Duerst & Suignard 标准轨道 [第 17 页]
RFC 3987 国际化资源标识符 2005 年 1 月
在其他一些情况下，使用 U+200E LEFT-TO-RIGHT MARK（LRM）可能
足以强制正确的显示行为。然而，Unicode 双向算法的细节并不总是
容易理解。强烈建议实现者谨慎处理，在不完全确定没有嵌入时显示
行为不会受影响的所有情况下都使用嵌入。
Unicode 双向算法（[UNI9]，第 4.3 节）允许更高层协议影响双向
呈现。如果这种由更高层协议作出的更改会改变 IRI 的呈现，则
MUST NOT 使用。
可在 IRI 前后使用以确保正确显示的双向格式字符，本身并不是
IRI 的一部分。IRI MUST NOT 包含双向格式字符（LRM、RLM、LRE、
RLE、LRO、RLO 和 PDF）。这些字符影响 IRI 的视觉呈现，但自身
并不出现。因此，不可能正确输入带有这些字符的 IRI。
4.2. Bidi IRI 结构
Unicode 双向算法主要是为 running text 设计的。为确保它不会
过多影响双向 IRI 的呈现，有必要对双向 IRI 作出一些限制。
这些限制以分隔符（结构字符，主要是标点，例如 "@"、"."、":"
和 "/"）和组件（通常主要由字母和数字组成）的形式给出。
就 Bidi 行为而言，第 2.2 节中的以下语法规则对应于组件：
iuserinfo、ireg-name、isegment、isegment-nz、isegment-nz-nc、
ireg-name、iquery 和 ifragment。
定义上述任一组件语法的规范 MAY 将它们进一步划分，并按照
本文档定义更小的部分作为组件。例如，[RFC3490] 对双向域名的
限制，对应于在 ireg-name 作为域名的方案中，将域名的每个标签
视为一个组件。即使没有正式定义组件，从组件角度思考某些语法
并应用相关限制也可能有帮助。例如，对于查询部分中常见的
name/value 语法，将每个 name 和每个 value 视为一个组件是方便的。
另一个例子是，资源名中的扩展名可以被视为单独的组件。
Duerst & Suignard 标准轨道 [第 18 页]
RFC 3987 国际化资源标识符 2005 年 1 月
对每个组件，适用以下限制：
1. 一个组件 SHOULD NOT 同时使用从右向左字符和从左向右字符。
2. 使用从右向左字符的组件 SHOULD 以从右向左字符开始和结束。
上述限制以 should 而不是 must 给出。对于从不进行视觉呈现的
IRI，它们并不相关。然而，对于一般的 IRI，它们对于确保视觉
呈现与逻辑表示之间两个方向的一致转换非常重要。
注意：在某些组件中，上述限制实际上可能会被严格执行。例如，
[RFC3490] 要求这些限制适用于那些 ireg-name 是主机名的方案中
主机名的标签。在其他一些组件中（例如路径组件），遵循这些
限制可能并不太困难。对于其他组件，例如查询部分中的若干部分，
由于查询参数的值可能是任意字符序列，因此强制执行这些限制
可能非常困难。
如果无法以其他方式满足上述限制，则受影响的组件始终可以按照
第 3.1 节所述映射为 URI 记法。请注意，必须映射整个组件
（另见下面的示例 9）。
4.3. Bidi IRI 的输入
Bidi 输入方法 MUST 以逻辑顺序生成 Bidi IRI，同时按照
第 4.1 节呈现它们。在输入期间，呈现 SHOULD 在每输入一个新字符后
更新，以避免最终用户混淆。
4.4. 示例
本节使用 Bidi Notation 给出双向 IRI 的示例。它展示合法 IRI 中
逻辑表示与视觉表示之间的关系，并说明这种关系中的某些现象在
不熟悉双向行为的人看来可能很奇怪，但对阿拉伯语和希伯来语用户
来说则很熟悉。它还展示如果不遵循第 4.2 节给出的限制会发生
什么情况。下面的示例可在 [BidiEx] 中以阿拉伯文、希伯来文和
Bidi Notation 变体查看。
Duerst & Suignard 标准轨道 [第 19 页]
RFC 3987 国际化资源标识符 2005 年 1 月
要阅读示例中的 bidi 文本，请从左向右读取视觉表示，直到遇到
一段 rtl 文本。然后从右向左读取该 rtl 块（包括斜杠和其他
特殊字符），再从下一个尚未读取的 ltr 字符继续。
示例 1：包含 rtl 字符的单个组件会被反转：
逻辑表示："http://ab.CDEFGH.ij/kl/mn/op.html"
视觉表示："http://ab.HGFEDC.ij/kl/mn/op.html"
可以逐个读取组件，并且每个组件可以按其自然方向读取。
示例 2：多个连续包含 rtl 字符的组件会作为一个整体被反转：
逻辑表示："http://ab.CDE.FGH/ij/kl/mn/op.html"
视觉表示："http://ab.HGF.EDC/ij/kl/mn/op.html"
一串 rtl 组件按 rtl 读取，就像 bidi 文本中的一串 rtl 单词
按 rtl 读取一样。
示例 3：IRI 的所有组件（方案除外）都是 rtl。
所有 rtl 组件会整体反转：
逻辑表示："http://AB.CD.EF/GH/IJ/KL?MN=OP;QR=ST#UV"
视觉表示："http://VU#TS=RQ;PO=NM?LK/JI/HG/FE.DC.BA"
整个 IRI（方案除外）按 rtl 读取。rtl 组件之间的分隔符保持在
相应组件之间；ltr 组件和 rtl 组件之间的分隔符不会移动。
示例 4：若干 rtl 组件序列分别各自反转：
逻辑表示："http://AB.CD.ef/gh/IJ/KL.html"
视觉表示："http://DC.BA.ef/gh/LK/JI.html"
每个 rtl 组件序列按 rtl 读取，就像 ltr 文本中每个 rtl 单词序列
按 rtl 读取一样。
示例 5：将示例 2 应用于不同种类的组件：
逻辑表示："http://ab.cd.EF/GH/ij/kl.html"
视觉表示："http://ab.cd.HG/FE/ij/kl.html"
域名标签和路径组件的反转可能出乎意料，但它与其他 bidi 行为
一致。为了确认域组件确实是 "ab.cd.EF"，按 bidi 算法朗读视觉
表示可能会有所帮助。在 "http://ab.cd." 之后，读取 RTL 块
"E-F-slash-G-H"，这对应于逻辑表示。
示例 6：与示例 5 相同，但包含更多 rtl 组件：
逻辑表示："http://ab.CD.EF/GH/IJ/kl.html"
视觉表示："http://ab.JI/HG/FE.DC/kl.html"
域名标签和路径组件的反转可能更容易识别，因为分隔符也会移动。
Duerst & Suignard 标准轨道 [第 20 页]
RFC 3987 国际化资源标识符 2005 年 1 月
示例 7：单个 rtl 组件包含数字：
逻辑表示："http://ab.CDE123FGH.ij/kl/mn/op.html"
视觉表示："http://ab.HGF123EDC.ij/kl/mn/op.html"
数字在所有情况下都从左向右书写，但在一段 rtl 字符中被视为
额外的嵌入。这与通常的双向文本完全一致。
示例 8（不允许）：数字位于 rtl 组件的开头或结尾：
逻辑表示："http://ab.cd.ef/GH1/2IJ/KL.html"
视觉表示："http://ab.cd.ef/LK/JI1/2HG.html"
序列 "1/2" 被 bidi 算法解释为分数，从而打碎组件并导致混淆。
还有其他字符会以接近数字的特殊方式解释；特别是 "+"、"-"、
"#"、"$"、"%"、","、"." 和 ":"。
示例 9（不允许）：前一示例中的数字被百分号编码：
逻辑表示："http://ab.cd.ef/GH%31/%32IJ/KL.html",
视觉表示（希伯来文）："http://ab.cd.ef/%31HG/LK/JI%32.html"
视觉表示（阿拉伯文）："http://ab.cd.ef/31%HG/%LK/JI32.html"
根据大写字母表示阿拉伯文还是希伯来文，视觉表示会有所不同。
示例 10（允许但不推荐）：
逻辑表示："http://ab.CDEFGH.123/kl/mn/op.html"
视觉表示："http://ab.123.HGFEDC/kl/mn/op.html"
只由数字组成的组件是允许的（禁止它们会相当困难），但这些组件
可能会以不易预测的方式与相邻的 RTL 组件交互。
5. 规范化与比较
注意：本节的结构和大部分材料取自 [RFC3986] 第 6 节；
差异源于 IRI 的具体特性。
IRI 上最常见的操作之一是简单比较：在不使用 IRI 或映射后的 URI
访问相应资源的情况下，确定两个 IRI 是否等价。每当访问响应缓存、
浏览器检查历史记录以给链接着色，或 XML 解析器处理命名空间中的
标记时，都会执行比较。蜘蛛程序和索引引擎可能会在比较 IRI 之前
进行广泛规范化，以修剪搜索空间，或减少请求操作和响应存储的重复。
Duerst & Suignard 标准轨道 [第 21 页]
RFC 3987 国际化资源标识符 2005 年 1 月
IRI 比较是为了某个特定目的而执行的。为不同目的比较 IRI 的
协议或实现，通常会在减少别名标识符所应投入的工作量方面面临
不同的设计权衡。本节描述可用于比较 IRI 的各种方法、它们之间
的权衡，以及可能使用这些方法的应用类型。
5.1. 等价性
由于 IRI 的存在是为了标识资源，所以当它们标识同一资源时，
理应被认为是等价的。然而，这种等价性定义并没有太多实际用途，
因为除非实现完全了解或控制两个资源，否则无法比较两个资源。
因此，IRI 等价或差异的判定基于字符串比较，或许还会参考 URI
方案定义提供的附加规则。我们使用术语“不同”和“等价”来描述
此类比较的可能结果，但存在许多依赖于应用的等价版本。
即使可以判定两个 IRI 等价，IRI 比较也不足以判定两个 IRI 是否
标识不同的资源。例如，两个不同域名的所有者可能决定从这两个
域名提供同一个资源，从而产生两个不同的 IRI。因此，比较方法
被设计为尽量减少假阴性，同时严格避免假阳性。
在测试等价性时，应用程序不应直接比较相对引用；在比较前应将
这些引用转换为各自的目标 IRI。当比较 IRI 是为了选择（或避免）
某个网络操作，例如检索某个表示时，应从比较中排除片段组件
（如果有）。
将 IRI 用作与协议无关的身份令牌的应用程序 MUST 使用
Simple String Comparison（见第 5.3.1 节）。所有其他应用程序
MUST 从 Comparison Ladder 中选择一种比较实践（见第 5.3 节，
或者在 IRI 到 URI 转换之后，从 [RFC3986] 第 6.2 节的 URI
比较阶梯中选择一种比较实践）
5.2. 比较前的准备
任何类型的 IRI 比较都 REQUIRES 解析承载 IRI 的协议或格式中的
所有转义或编码。这通常在解析协议或格式时完成。此类示例
Duerst & Suignard 标准轨道 [第 22 页]
RFC 3987 国际化资源标识符 2005 年 1 月
转义或编码的示例包括 [HTML4] 和 [XML1] 中的实体和
数字字符引用。例如，"http://example.org/rosé"（在 HTML 中）、
"http://example.org/rosé";（在 HTML 或 XML 中）以及
"http://example.org/rosé";（在 HTML 或 XML 中）都会解析为
本文档中（见第 1.4 节）记作
"http://example.org/rosé"; 的形式（这里的 "é" 表示
实际的 e-acute 字符，以弥补本文档不能包含非 ASCII 字符这一事实）。
类似的考虑也适用于 HTTP 中的 Transfer Codings（见 [RFC2616]）
和 MIME 中的 Content Transfer Encodings（[RFC2045]）等编码，
不过在这些情况下，编码不是基于字符，而是基于八位字节；
因此需要额外小心，以确保被比较的是字符，而不只是任意八位字节
（见第 5.3.1 节）。
5.3. 比较阶梯
实际上，人们使用多种方法来测试 IRI 等价性。这些方法构成一个
范围，其差别在于所需处理量，以及降低假阴性概率的程度。如上
所述，假阴性无法消除。实践中可以降低其概率，但这种降低需要
更多处理，并非对所有应用都具有成本效益。
如果把这一系列比较实践看作一个阶梯，下面的讨论将从成本低、
但产生假阴性的机会相对较高的实践开始，逐步上升到计算成本
更高、但假阴性风险更低的实践。
5.3.1. 简单字符串比较
如果两个 IRI 作为字符串考虑时完全相同，那么可以安全地断定
它们是等价的。这种等价性测试的计算成本很低，并广泛用于各种
应用，特别是在解析领域。当需要一个独立于所用方案、能够快速
计算且无需访问网络的 IRI 等价性确定答案时，也会使用这种测试。
XML Namespaces（[XMLNamespace]）就是这样一种情况的示例。
测试字符串等价性需要一些基本预防措施。此过程通常被称为
“bit-for-bit”或“byte-for-byte”比较，这可能具有误导性。测试
字符串相等通常基于对组成字符串的字符逐对比较，从第一个字符
开始，直到两个字符串都已耗尽且所有字符均被发现相等，或直到
某一对字符比较为不相等，或直到其中一个字符串在另一个之前耗尽。
Duerst & Suignard 标准轨道 [第 23 页]
RFC 3987 国际化资源标识符 2005 年 1 月
这种字符比较要求每一对字符都置于可比较的编码形式中。例如，
如果一个 IRI 存储在 UTF-8 编码形式的字节数组中，而第二个 IRI
处于 UTF-16 编码形式，那么天真地应用 bit-for-bit 比较会产生
错误。最好说是基于 character-for-character 的相等，而不是
基于 byte-for-byte 或 bit-for-bit 的相等。实际而言，逐字符
比较应在转换为共同字符编码形式之后，逐码点进行。当逐字符比较时，
比较函数 MUST NOT 将 IRI 映射为 URI，因为这种映射会产生额外的
虚假等价性。由此可知，如果某个 IRI 可能被用作标识符，则在传输
该 IRI 时 SHOULD NOT 修改它。
假阴性由 IRI 别名的产生和使用造成。无论采用何种比较方法，
都可以通过始终以已经规范化的形式提供 IRI 引用来减少不必要的
别名（即与按下文所述应用规范化后所产生形式相同的形式）。
协议和数据格式通常将某些 IRI 比较限制为简单字符串比较，其依据
是这样一种理论：人和实现为了自身利益，会在提供 IRI 引用时保持
一致，或者至少足够一致，以抵消进一步规范化可能获得的任何效率。
5.3.2. 基于语法的规范化
实现可以使用基于本规范所提供定义的逻辑来降低假阴性的概率。
这种处理的成本比 character-for-character 字符串比较略高。
例如，使用这种方法的应用可以合理地认为以下两个 IRI 等价：
example://a/b/c/%7Bfoo%7D/rosé
eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros%C3%A9
Web 用户代理（例如浏览器）在确定是否有可用的缓存响应时，
通常会应用这种 IRI 规范化。基于语法的规范化包括大小写规范化、
字符规范化、百分号编码规范化以及移除点段等技术。
Duerst & Suignard 标准轨道 [第 24 页]
RFC 3987 国际化资源标识符 2005 年 1 月
5.3.2.1. 大小写规范化
对于所有 IRI，百分号编码三元组中的十六进制数字（例如 "%3a"
与 "%3A"）不区分大小写，因此应规范化为对数字 A - F 使用大写字母。
当 IRI 使用通用语法的组件时，组件语法等价规则始终适用；
也就是说，方案和仅含 US-ASCII 的主机不区分大小写，因此应
规范化为小写。例如，URI "HTTP://www.EXAMPLE.com/" 等价于
"http://www.example.com/"。IRI 组件中属于 IDN 的非 ASCII 字符的
大小写等价性在第 5.3.3 节中讨论。除非方案另有明确定义，
其他通用语法组件均假定为区分大小写。
应避免创建允许包含非 ASCII 字符的大小写不敏感语法组件的方案。
非 ASCII 字符的大小写规范化可能依赖文化背景，并且始终是复杂
操作。唯一的例外涉及非 ASCII 主机名，其字符规范化包括一个源自
大小写折叠的映射步骤。
5.3.2.2. 字符规范化
Unicode 标准 [UNIV4] 为各种目的定义了字符序列之间的各种等价性。
Unicode Standard Annex #15 [UTR15] 为这些等价性定义了多种
Normalization Forms，特别是 Normalization Form C（NFC，Canonical
Decomposition 后跟 Canonical Composition）和 Normalization Form KC
（NFKC，Compatibility Decomposition 后跟 Canonical Composition）。
IRI 的等价性 MUST 依赖于这样一种假设：IRI 已经适当地进行过
预字符规范化，而不是在比较两个 IRI 时应用字符规范化。例外情况
是从非数字形式转换，以及从非基于 UCS 的字符编码转换为基于 UCS
的字符编码。在这些情况下，MUST 使用 NFC，或使用采用 NFC 的
规范化转码器，以保证互操作性。为避免假阴性和转码问题，
IRI SHOULD 使用 NFC 创建。使用 NFKC 可以避免更多问题；例如，
选择半角拉丁字母而不是全角拉丁字母，以及选择全角片假名而不是
半角片假名。
例如，"http://www.example.org/résumé.html"（XML
Notation 中）处于 NFC。另一方面，
"http://www.example.org/résumé.html" 不处于 NFC。
Duerst & Suignard 标准轨道 [第 25 页]
RFC 3987 国际化资源标识符 2005 年 1 月
前者使用预组合的 e-acute 字符，后者使用 "e" 字符后跟组合锐音符。
这两种用法在 [UNIV4] 中被定义为规范等价。
注意：由于不知道某个特定字符序列在字符规范化方面如何被处理，
允许第三方任意规范化 IRI 是不合适的。这并不与资源创建时
其 IRI 应尽可能进行字符规范化（即 NFC，甚至 NFKC）的建议
相矛盾。这类似于大写/小写问题。URI 的某些部分不区分大小写
（域名）。对于其他部分，不清楚它们是区分大小写、不区分大小写，
还是介于两者之间（例如区分大小写，但在使用错误大小写时提供
多项选择，而不是直接给出否定结果）。最佳做法是创建者使用合理的
大小写，并且在传输 URI 时永远不要更改大小写。
各种 IRI 方案可能允许在 ireg-name 部分或其他位置使用
Internationalized Domain Names（IDN）[RFC3490]。字符规范化也适用于
IDN，如第5.3.3 节所讨论。
5.3.2.3. 百分号编码规范化
百分号编码机制（[RFC3986] 第 2.1 节）是在其他方面相同的
IRI 之间产生差异的常见来源。除了上文提到的大小写规范化问题外，
一些 IRI 生成者会对不需要百分号编码的八位字节进行百分号编码，
从而产生与其未编码对应物等价的 IRI。应通过解码任何对应于
非保留字符的百分号编码八位字节序列来规范化这些 IRI，如
[RFC3986] 第 2.3 节所述。
对于实际解析，百分号编码差异（保留字符的百分号编码除外）
MUST 始终解析为同一资源。例如，"http://example.org/~user"、
"http://example.org/%7euser" 和 "http://example.org/%7Euser"
必须解析为同一资源。
如果要测试这种等价性，必须对要比较的两个 IRI 的百分号编码进行
对齐；例如，将两个 IRI 都转换为 URI（见第 3.1 节），消除
生成 URI 中的转义差异，并确保百分号编码中十六进制字符的大小写
始终相同（最好使用大写）。如果 IRI 将被传递给另一个应用程序，
或以其他方式进一步使用，则其原始形式 MUST 保留。这里描述的
转换只应为本地比较而执行。
Duerst & Suignard 标准轨道 [第 26 页]
RFC 3987 国际化资源标识符 2005 年 1 月
5.3.2.4. 路径段规范化
完整路径段 "." 和 ".." 仅用于相对引用（[RFC3986] 第 4.1 节），
并作为引用解析过程的一部分被移除（[RFC3986] 第 5.2 节）。
然而，一些实现可能错误地认为，当引用已经是 IRI 时不需要进行
引用解析，因此当点段出现在非相对路径中时未能移除它们。IRI
规范化器应通过将 remove_dot_segments 算法应用于路径来移除点段，
如 [RFC3986] 第 5.2.4 节所述。
5.3.3. 基于方案的规范化
IRI 的语法和语义因方案而异，如每个方案的定义规范所描述。
实现可以使用特定于方案的规则，以进一步的处理成本来降低假阴性的
概率。例如，由于 "http" 方案使用 authority 组件，默认端口为
"80"，并定义空路径等价于 "/"，所以下面四个 IRI 是等价的：
http://example.com
http://example.com/
http://example.com:/
http://example.com:80/
一般来说，使用带 authority 的通用语法且路径为空的 IRI，应规范化
为路径 "/"。同样，如果显式的 ":port" 中端口为空，或为该方案的
默认端口，则它等价于省略端口及其 ":" 分隔符的形式，因此应由
基于方案的规范化移除。例如，上面的第二个 IRI 是 "http" 方案的
规范形式。
另一种因方案而异的规范化情况，是对空 authority 组件或空 host
子组件的处理。对于许多方案规范，空 authority 或 host 被视为错误；
对于其他方案，则被视为等价于 "localhost" 或最终用户的主机。当某
方案为 authority 定义了默认值，并且希望 IRI 引用该默认值时，为了
统一、简洁和国际化，应将该引用规范化为空 authority。但是，如果
userinfo 或 port 子组件中任一非空，则即使 host 与默认值匹配，也应
明确给出 host。
Duerst & Suignard 标准轨道 [第 27 页]
RFC 3987 国际化资源标识符 2005 年 1 月
除非方案规范允许，否则当关联组件为空时，规范化不应移除分隔符。
例如，不能假定 IRI "http://example.com/?" 与上面的任何示例等价。
同样，userinfo 子组件中分隔符的存在或不存在，通常对其解释具有
意义。fragment 组件不受任何基于方案的规范化影响；因此，两个
仅在后缀 "#" 上不同的 IRI，无论方案如何，都被视为不同。
一些 IRI 方案可能允许在其 ireg-name 部分或其他位置使用
Internationalized Domain Names（IDN）[RFC3490]。当这些名称在 IRI 中
使用时，SHOULD 使用 [RFC3490] 定义的 ToASCII 操作，并带有
"UseSTD3ASCIIRules" 和 "AllowUnassigned" 标志来验证。包含无效 IDN
的 IRI 无法成功解析。已验证的 IRI IDN 组件 SHOULD 使用 Nameprep
过程 [RFC3491] 进行字符规范化；但是，出于可读性目的，SHOULD NOT
将其转换为 ASCII Compatible Encoding（ACE）。
基于方案的规范化也可以认为 IDN 组件及其到 punycode 的转换等价。
例如，"http://résumé.example.org" 可以被视为等价于
"http://xn--rsum-bpad.example.org"。
其他特定于方案的规范化也是可能的。
5.3.4. 基于协议的规范化
对于 Web 蜘蛛程序而言，投入大量工作来降低假阴性发生率通常具有
成本效益。因此，它们在 IRI 比较中实现更激进的技术。例如，如果
它们观察到某个 IRI，例如
http://example.com/data
重定向到仅在尾随斜杠上不同的 IRI
http://example.com/data/
它们今后很可能会将二者视为等价。只有当访问资源的结果和其方案
解引用算法的共同约定都清楚地表明等价时，这种技术才是适当的
（在此例中，是 HTTP 源服务器使用重定向来避免相对引用问题）。
Duerst & Suignard 标准轨道 [第 28 页]
RFC 3987 国际化资源标识符 2005 年 1 月
6. IRI 的使用
6.1. IRI 中允许的 UCS 字符限制
本节讨论除第 2.2 节和第 4.1 节中给出的限制之外，
可用于 IRI 的字符和字符序列的限制。本节中的考虑与创建 IRI
以及将 URI 转换为 IRI 时相关。
a. 每个 IRI 组件中允许的字符表受该组件定义的限制。例如，
scheme 组件的定义不允许 US-ASCII 以外的字符。
（注意：按照 URI 实践，通用 IRI 软件不能也不应检查此类限制。）
b. UCS 包含许多字符区域，其中有很强的视觉相似字符。由于容易
发生转写错误，也应避免这些字符。这包括拉丁字符的全角等价
字符、日语的半角片假名字符以及许多其他字符。它还包括许多
类似于 "space"、"delims" 和 "unwise" 的字符，这些字符在
[RFC3491] 中被排除。
[UNIXML] 中提供了附加信息。[UNIXML] 是在 running text 的上下文中
编写的，而不是在标识符的上下文中编写的。尽管如此，它讨论了许多
不适合 IRI 的字符类别。
6.2. 软件接口和协议
虽然 IRI 被定义为字符序列，但 URI 的软件接口通常在八位字节序列
或其他种类的代码单元序列上工作。因此，软件接口和协议 MUST 定义
使用哪种字符编码。
IRI 能力组件和仅 URI 组件之间的中间软件接口，在从 IRI 能力组件
传输到仅 URI 组件时，MUST 按照第 3.1 节映射 IRI。此映射
SHOULD 尽可能晚地应用。它 SHOULD NOT 在已知能够处理 IRI 的组件
之间应用。
Duerst & Suignard 标准轨道 [第 29 页]
RFC 3987 国际化资源标识符 2005 年 1 月
6.3. 文档和协议中 URI 与 IRI 的格式
传输 URI 的文档格式可能必须升级，以允许传输 IRI。在文档整体具有
原生字符编码的情况下，IRI MUST 也以该字符编码进行编码，并由
解析器或解释器相应地转换。无法用原生字符编码表示的 IRI 字符，
如果文档格式有此类转义约定，SHOULD 使用文档格式的转义约定进行
转义。或者，它们 MAY 按照第 3.1 节进行百分号编码。例如，
在 HTML 或 XML 中，SHOULD 使用数字字符引用。如果文档整体具有
原生字符编码，且该字符编码不是 UTF-8，则 IRIs MUST NOT 以 UTF-8
字符编码放入该文档中。
注意：一些格式已经容纳 IRI，尽管它们使用不同术语。HTML 4.0
[HTML4] 将从 IRI 到 URI 的转换定义为避免错误的行为。XML 1.0
[XML1]、XLink [XLink]、XML Schema [XMLSchema] 以及基于它们的规范允许
IRI。此外，预计所有相关的新 W3C 格式和协议都将被要求处理
IRI [CharMod]。
6.4. 使用 UTF-8 对原始字符进行编码
本节讨论第 1.2 节中 c) 点的细节并给出示例。为了能够使用
IRI，与所讨论 IRI 对应的 URI 必须使用 UTF-8 将原始字符编码为
八位字节。这可以为某个 URI 方案的所有 URI 指定，也可以适用于
那些未指定如何编码原始字符的方案中的单个 URI。它可以适用于整个
URI，也可以仅适用于某些部分。关于将字符编码到 URI 中的背景信息，
另见 [RFC3986] 第 2.5 节。
对于新的 URI 方案，[RFC2718] 中建议使用 UTF-8。已经使用 UTF-8
的示例包括 URN 语法 [RFC2141]、IMAP URL [RFC2192] 和 POP URL
[RFC2384]。另一方面，由于 HTTP URL 方案未指定如何编码原始字符，
只有某些 HTTP URL 可以具有对应但不同的 IRI。
例如，对于 URI 为
"http://www.example.org/r%C3%A9sum%C3%A9.html" 的文档，可以构造
一个对应的 IRI（XML 记法，见第 1.4 节）：
"http://www.example.org/résumé.html"（"é"; 表示
e-acute 字符，"%C3%A9" 是该字符的 UTF-8 编码并经百分号编码的
表示）。另一方面，对于 URI 为
Duerst & Suignard 标准轨道 [第 30 页]
RFC 3987 国际化资源标识符 2005 年 1 月
"http://www.example.org/r%E9sum%E9.html" 的文档，百分号编码八位字节
不能转换为 IRI 中的实际字符，因为该百分号编码不是基于 UTF-8。
这意味着，对于大多数 URI 方案，并不需要升级其方案定义才能使其
与 IRI 一起工作。升级有意义的主要情况是：某个方案定义或方案的
某个特定组件被严格限制为只能使用 US-ASCII 字符，并且没有规定
通过百分号编码包含非 ASCII 字符/八位字节；或者某个方案定义目前
使用高度特定于方案的规定来编码非 ASCII 字符。mailto: 方案
[RFC2368] 就是一个例子。
本规范不以任何方式升级任何方案规范；这必须单独完成。此外，
请注意不存在所谓的 "IRI scheme"；所有 IRI 都使用 URI 方案，
所有 URI 方案也都可以与 IRI 一起使用，尽管在某些情况下只能通过
直接把 URI 作为 IRI 使用，而不进行任何转换。
URI 方案可以对特定于方案的 URI 的语法施加限制；也就是说，
在通用 URI 语法 [RFC3986] 下可接受的 URI，可能因 URI 方案规范
施加的更窄语法约束而不可接受。URI 方案定义不能扩展通用 URI
语法的语法限制；否则，将可能生成满足特定方案语法约束、但不满足
通用 URI 语法语法约束的 URI。然而，URI 方案规范施加的附加语法
约束适用于 IRI，因为由第 3.1 节定义的映射所得的对应 URI
MUST 是一个在通用 URI 语法的语法限制和相应 URI 方案规范施加的
任何更窄限制下均有效的 URI。
使用 UTF-8 的要求适用于 URI 的所有部分（ireg-name 部分可能除外；
见第3.1 节）。然而，IRI 直接表示大范围字符的能力
可能只用于 IRI（或 IRI 引用）的某些部分。IRI 的其他部分可能只包含
US-ASCII 字符，或者它们可能并非基于 UTF-8。它们可能基于另一种
字符编码，也可能直接编码原始二进制数据（另见 [RFC2397]）。
例如，可以有一个 URI 引用：
"http://www.example.org/r%E9sum%E9.xml#r%C3%A9sum%C3%A9"，其中
文档名基于服务器设置以 iso-8859-1 编码，但片段标识符按照
Duerst & Suignard 标准轨道 [第 31 页]
RFC 3987 国际化资源标识符 2005 年 1 月
[XPointer] 以 UTF-8 编码。与上述 URI 对应的 IRI 将是（XML 记法）
"http://www.example.org/r%E9sum%E9.xml#résumé";。
类似的考虑也适用于查询部分。IRI 的功能（即能够包含非 ASCII
字符）只有在查询部分以 UTF-8 编码时才能使用。
6.5. 相对 IRI 引用
针对基底处理相对 IRI 引用是直接的；可以直接应用 [RFC3986] 的算法，
将 IRI 引用中额外允许的字符以 URI 引用中非保留字符的相同方式
处理。
7. URI/IRI 处理指南（资料性）
本资料性章节提供指南，用于在当前处理 URI 的相同软件组件和操作中
支持 IRI：处理 URI 的软件接口、允许用户输入 URI 的软件、创建或
生成 URI 的软件、显示 URI 的软件、传输 URI 的格式和协议，以及
解释 URI 的软件。这些组件在能够正确处理 IRI 之前可能都需要修改。
本节中的考虑也适用于 URI 引用和 IRI 引用。
7.1. URI/IRI 软件接口
处理 URI 的软件接口，例如 URI 处理 API 和传输 URI 的协议，
需要设计为能够承载 IRI 的接口和协议元素。
如果 API 或协议中的当前处理基于 US-ASCII，则推荐使用 UTF-8 作为
IRI 的字符编码，因为它与 US-ASCII 兼容，符合 [RFC2277] 的建议，
并且使转换为 URI 变得容易。无论如何，API 或协议定义都必须清楚地
定义要使用的字符编码。
从仅 URI 组件传输到 IRI 能力组件不需要映射，不过可以执行上文
第 3.2 节描述的转换。当存在无法正确执行这种逆向转换的可能时，
最好不要执行该逆向转换。
Duerst & Suignard 标准轨道 [第 32 页]
RFC 3987 国际化资源标识符 2005 年 1 月
7.2. URI/IRI 输入
一些组件允许用户通过键入或听写等方式将 URI 输入系统。此类软件
必须更新，以允许 IRI 输入。
看到 IRI 的视觉表示（以某种顺序排列的一串字形，呈现在某种视觉
显示中）或听到 IRI 的人，将使用用户语言中字符的输入方法输入该
IRI。根据所用文字和输入方法，这可能是一个或多或少复杂的过程。
IRI 输入过程必须尽可能确保满足第 2.2 节定义的限制。这可以
通过选择适当的输入方法或其变体/设置，适当转换正在输入的字符，
消除无法转换的字符，和/或向用户发出警告或错误消息来完成。
作为变体设置的示例，东亚语言的输入法编辑器通常允许输入全角或
半角版本的拉丁字母和相关字符。对于 IRI 输入，输入法编辑器应设置为
产生半角拉丁字母和标点，以及全角片假名。
主要或专门用于输入 URI/IRI 的输入字段，可以允许用户查看 IRI
映射为 URI 后的形式。经常输入 IRI 的位置可以提供查看 IRI 映射为
URI 后形式的可能性。当用户使用的某些软件尚不接受 IRI 时，这会
帮助用户。
与处理 URI 但不处理 IRI 的组件对接的 IRI 输入组件，在将 IRI
传递给这些组件之前，必须将 IRI 映射为 URI。
关于包含从右向左字符的 IRI 输入，请参见第 4.3 节。
7.3. URI/IRI 在应用之间的传递
许多应用，特别是邮件用户代理，会尝试检测纯文本中出现的 URI。
为此，它们使用一些基于 URI 语法的启发式方法。然后它们允许用户
点击这些 URI，并在适当的（通常依赖方案的）应用中检索相应资源。
Duerst & Suignard 标准轨道 [第 33 页]
RFC 3987 国际化资源标识符 2005 年 1 月
此类应用必须升级，以使用 IRI 语法作为启发式方法的基础。特别是，
不应把非 ASCII 字符视为 IRI 结束的指示。此类应用还必须确保，
它们正确地将检测到的 IRI 从该 IRI 所出现的文档或应用的字符编码，
转换为系统级 IRI 调用机制所使用的字符编码；如果系统级调用机制
只接受 URI，则按第 3.1 节转换为 URI。
剪贴板是另一个经常用于在应用之间传递 URI 和 IRI 的方式。在大多数
平台上，剪贴板能够存储和传递多种语言和文字的文本。正确使用时，
剪贴板传递的是字符，而不是字节，这会正确处理 IRI。
7.4. URI/IRI 生成
通过 Internet 提供资源且这些资源具有逻辑名称的系统，有时会自动
为其提供的资源生成 URI。例如，一些 HTTP 服务器可以为文件目录生成
目录列表，然后用文件响应所生成的 URI。
许多旧式字符编码在各种文件系统中使用。许多当前部署的系统在生成
URI 之前，并不转换底层系统的本地字符表示。
为了最大化互操作性，生成资源标识符的系统应进行适当转换。例如，
如果文件系统包含一个名为 "résumé.html" 的文件，服务器应在
URI 中将其公开为 "r%C3%A9sum%C3%A9.html"，这样即可在 IRI 中使用
"résumé.html"，即使本地文件名保存在 UTF-8 以外的字符编码中。
此建议特别适用于 HTTP 服务器。对于 FTP 服务器，类似的考虑也适用；
见 [RFC2640]。
7.5. URI/IRI 选择
在某些情况下，资源所有者和发布者可以控制用于标识其资源的 IRI。
这种控制主要通过直接控制资源名称（例如文件名）来执行。
Duerst & Suignard 标准轨道 [第 34 页]
RFC 3987 国际化资源标识符 2005 年 1 月
在这些情况下，建议避免选择容易混淆的 IRI。例如，对于 US-ASCII，
小写字母 ell（"l"）容易与数字一（"1"）混淆，大写字母 oh（"O"）
容易与数字零（"0"）混淆。发布者应避免用 "br0ken" 或 "1ame"
这样的标识符使用户困惑。
在 US-ASCII 字符表之外，混淆的机会更多；完整的指南集合过长，
无法在此包含。只要名称限于单一文字中的字符，某种文字或语言的
母语书写者最清楚何时可能出现歧义，以及如何避免歧义。对外来者
看起来可能有歧义的内容，对普通母语用户来说可能完全显而易见。
另一方面，在某些情况下，UCS 出于兼容原因包含变体；例如用于排版
目的的变体。这些应尽可能避免。虽然可能存在例外，但新创建的资源
名称通常应处于 NFKC [UTR15]（这意味着它们也处于 NFC）。
例如，出于兼容原因，UCS 在 U+FB01 包含 "fi" 连字。只要可能，
IRI 应使用两个字母 "f" 和 "i"，而不是 "fi" 连字。后一种用法的
一个示例，是在 IRI 的查询部分中显式搜索包含 "fi" 连字写法的词。
在某些情况下，来自不同文字的字符可能看起来相同。最著名的示例是
拉丁字母 "A"、希腊字母 "Alpha" 和西里尔字母 "A" 的相似性。为避免
这种情况，只应创建这样的 IRI：单个组件中的所有字符都在某一给定
语言中一起使用。这通常意味着这些字符都来自同一种文字，但也有一些
语言会混合来自不同文字的字符（例如日语）。这类似于上面示例中
用于区分字母和数字的启发式方法。此外，对于拉丁文、希腊文和
西里尔文，使用小写字母比使用大写字母会产生更少歧义。
7.6. URI/IRI 显示
在渲染软件预计无法使用可用的布局和字体资源正确显示 IRI 的
非 ASCII 部分的情况下，这些部分应在显示前进行百分号编码。
关于 Bidi IRI 的显示，请参见第 4.1 节。
Duerst & Suignard 标准轨道 [第 35 页]
RFC 3987 国际化资源标识符 2005 年 1 月
7.7. URI 和 IRI 的解释
将 IRI 解释为本地资源名称的软件，应接受多种形式的 IRI，并将它们
转换并匹配到适当的本地资源名称。
首先，多种表示包括协议原生字符编码中的 IRI，以及它们的 URI
对应物。
其次，它可能包括基于 UTF-8 以外字符编码构造的 URI。这些 URI
可能由不符合本规范、并使用旧式字符编码将非 ASCII 字符转换为 URI
的用户代理产生。这是否必要，以及要覆盖哪些字符编码，取决于许多
因素，例如本地使用的旧式字符编码以及各种版本用户代理的分布。
例如，日语软件可能除了 UTF-8 外，还接受 Shift_JIS 和/或 EUC-JP
中的 URI。
第三，它可能包括附加映射，以便更加用户友好，并更能抵御传输错误。
这些映射类似于一些服务器目前将 URI 视为大小写不敏感，或执行
附加匹配以处理拼写错误的方式。对于 US-ASCII 字符表之外的字符，
这可能包括，例如，忽略接收到的 IRI 或资源名称中的重音符号。
请注意，此类映射，包括大小写映射，都是依赖语言的。
如果考虑过多映射，可能很难无歧义地标识资源。然而，IRI 中
百分号编码的部分和未百分号编码的部分始终可以清楚地区分。此外，
UTF-8 的规律性（见 [Duerst97]）使潜在冲突低于乍看之下的程度。
7.8. 升级策略
当本建议对已经部署许多实例的软件施加进一步约束时，谨慎引入升级
并了解各种相互依赖关系非常重要。
如果 IRI 无法被正确解释，则不应创建、生成或传输它们。这表明，
将解释 URI 的软件升级为接受 IRI 应具有最高优先级。
另一方面，单个 IRI 只由一个或极少数事先已知的解释器解释，
尽管它可能会被非常广泛地输入和传输。
Duerst & Suignard 标准轨道 [第 36 页]
RFC 3987 国际化资源标识符 2005 年 1 月
因此，IRI 从软件能够输入和传输 IRI 的广泛升级中受益最大。然而，
在发布单个 IRI 之前，应注意升级相应的解释软件，以覆盖预期会由
各种版本的输入和传输软件接收到的形式。
生成软件从使用本地字符编码升级为生成 IRI，应只在服务已升级为
接受 IRI 之后发生。同样，只有在服务接受 IRI，并且已知中间基础
设施和协议能够安全传输它们时，才应生成 IRI。
用于显示的、从 URI 转换为 IRI 的软件，应只在升级后的输入软件已在
将看到该显示结果的人群中广泛部署之后再升级。
在可以自由选择字符编码的情况下，使用 UTF-8 而不是另一种编码，
通常可以减少升级到 IRI 的工作量和依赖关系。例如，在设置新的
基于文件的 Web 服务器时，使用 UTF-8 作为文件名的字符编码将使
迁移到 IRI 更容易。同样，在设置新的 Web 表单时，如果使用 UTF-8
作为表单页面的字符编码，返回的查询 URI 将使用 UTF-8 作为字符编码
（除非用户出于某种原因更改字符编码），因此将与 IRI 兼容。
这些建议结合起来，将允许从 URI 扩展到 IRI，以处理 US-ASCII 以外
的字符，同时最大限度减少互操作性问题。关于 URI 方案定义升级的
考虑，见第 6.4 节。
8. 安全考虑
[RFC3986] 中讨论的安全考虑也适用于 IRI。此外，以下问题对 IRI
需要特别小心。
不正确的编码或解码可能导致安全问题。特别是，一些 UTF-8 解码器
不检查过长字节序列。例如，"/" 在 UTF-8 和 US-ASCII 中都以字节
0x2F 编码，但一些 UTF-8 解码器也会错误地将序列 0xC0 0xAF 解释为
"/"。如果 UTF-8 解码器具有容错性、转换和检查未按正确顺序完成，
和/或保留字符与非保留字符没有清楚区分，那么类似
Duerst & Suignard 标准轨道 [第 37 页]
RFC 3987 国际化资源标识符 2005 年 1 月
"%C0%AF.." 这样的序列可能通过某些安全测试，然后在路径中被解释为
"/.."。
IRI 中可能以多种方式发生“欺骗”。“欺骗”意味着有人可能添加一个
资源名称，它在用户看来相同或相似，但指向不同资源。所添加的资源
可能通过看起来非常相似而假装是真实资源，但可能包含各种难以发现、
且可能造成各种问题的更改。IRI 的大多数欺骗可能性都是 URI 欺骗
可能性的扩展。
欺骗可能因各种原因发生。首先，用户在输入 IRI 或从旧式字符编码
转码 IRI 时的规范化预期或实际规范化，与服务器端使用的规范化不匹配。
从概念上说，这与使用大小写不敏感 Web 服务器所带来的问题并无不同。
例如，一个具有混合大小写名称的热门网页
（"http://big.example.com/PopularPage.html"）可能被某个能够创建
"http://big.example.com/popularpage.html" 的人“欺骗”。然而，
使用未规范化的字符序列，以及为用户便利而使用附加映射，可能增加
欺骗机会。允许创建未规范化名称资源的协议和服务器特别容易受到
这种攻击。这是相关协议、服务器或资源固有的安全问题，并非 IRI
所特有，但为完整性起见在此提及。
欺骗可能发生在各种 IRI 组件中，例如域名部分或路径部分。关于
域名部分的特定考虑，见 [RFC3491]。对于路径部分，允许独立用户在
同一子区域中创建资源的网站管理员，可能必须小心检查欺骗。
欺骗可能因为 UCS 中许多字符看起来非常相似而发生。细节在
第 7.5 节中讨论。同样，这与 US-ASCII 上的欺骗可能性非常相似，
例如使用 "br0ken" 或 "1ame" URI。
当接受基于各种字符编码的百分号编码 URI 以处理较旧的用户代理时，
可能发生欺骗。在某些情况下，特别是对于基于拉丁字母的资源名称，
这通常容易检测，因为 UTF-8 编码的名称在按旧式字符编码解释和查看时，
大多会产生乱码。
Duerst & Suignard 标准轨道 [第 38 页]
RFC 3987 国际化资源标识符 2005 年 1 月
当同时使用的字符编码具有相似结构，但不存在具有完全相同编码的字符时，
检测会更困难。
如果不遵循第 4.2 节中的限制，双向 IRI 中可能发生欺骗。
同一视觉表示可能被解释为不同的逻辑表示，反之亦然。使用正确的
Unicode 双向实现也非常重要。
9. 致谢
我们要感谢 Larry Masinter，他作为许多早期版本本文档
（draft-masinter-url-i18n-xx）的合著者所做的工作。
关于这里所处理问题的讨论很早以前就开始了。1995 年 8 月 HTML
工作组中有一个讨论串（主题为 "Globalizing URIs"），1996 年 7 月
www-international 邮件列表中也有一个讨论串（主题为
"Internationalization and URLs"），并且在 1995 年 9 月和 1997 年
9 月的 Unicode 会议上举行过临时会议。
非常感谢 Francois Yergeau、Matitiahu Allouche、Roy Fielding、
Tim Berners-Lee、Mark Davis、M.T. Carrasco Benitez、James Clark、
Tim Bray、Chris Wendt、Yaron Goland、Andrea Vine、Misha Wolf、
Leslie Daigle、Ted Hardie、Bill Fenner、Margaret Wasserman、
Russ Housley、Makoto MURATA、Steven Atkin、Ryan Stansifer、
Tex Texin、Graham Klyne、Bjoern Hoehrmann、Chris Lilley、Ian Jacobs、
Adam Costello、Dan Oscarson、Elliotte Rusty Harold、Mike J. Brown、
Roy Badami、Jonathan Rosenne、Asmus Freytag、Simon Josefsson、
Carlos Viegas Damasio、Chris Haynes、Walter Underwood 以及许多其他人，
感谢他们帮助理解这些问题和可能的解决方案，并帮助把细节做正确。
本文档是 World Wide Web Consortium（W3C）Internationalization
Working Group（I18N WG）的产物。感谢 W3C I18N Working Group 和
Interest Group 的成员所做的贡献，以及他们在 [CharMod] 上的工作。
还要感谢许多其他 W3C Working Groups 的成员采纳 IRI，并感谢
Montreal IAB Workshop on Internationalization and Localization 的成员
进行审阅。
Duerst & Suignard 标准轨道 [第 39 页]
RFC 3987 国际化资源标识符 2005 年 1 月
10. 参考文献
10.1. 规范性引用
[ASCII] American National Standards Institute, "Coded
Character Set -- 7-bit American Standard Code for
Information Interchange", ANSI X3.4, 1986.
[ISO10646] International Organization for Standardization,
"ISO/IEC 10646:2003: Information Technology -
Universal Multiple-Octet Coded Character Set (UCS)",
ISO Standard 10646, December 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[UNI9] Davis, M., "The Bidirectional Algorithm", Unicode
Standard Annex #9, March 2004,
<http://www.unicode.org/reports/tr9/tr9-13.html>.
[UNIV4] The Unicode Consortium, "The Unicode Standard, Version
4.0.1, defined by: The Unicode Standard, Version 4.0
(Reading, MA, Addison-Wesley, 2003. ISBN
0-321-18578-1), as amended by Unicode 4.0.1
(http://www.unicode.org/versions/Unicode4.0.1/)",
March 2004.
Duerst & Suignard 标准轨道 [第 40 页]
RFC 3987 国际化资源标识符 2005 年 1 月
[UTR15] Davis, M. and M. Duerst, "Unicode Normalization
Forms", Unicode Standard Annex #15, April 2003,
<http://www.unicode.org/unicode/reports/
tr15/tr15-23.html>.
10.2. 资料性引用
[BidiEx] "Examples of bidirectional IRIs",
<http://www.w3.org/International/iri-edit/
BidiExamples>.
[CharMod] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., and T.
Texin, "Character Model for the World Wide Web:
Resource Identifiers", World Wide Web Consortium
Candidate Recommendation, November 2004,
<http://www.w3.org/TR/charmod-resid>.
[Duerst97] Duerst, M., "The Properties and Promises of UTF-8",
Proc. 11th International Unicode Conference, San Jose
, September 1997,
<http://www.ifi.unizh.ch/mml/mduerst/papers/
PDF/IUC11-UTF-8.pdf>.
[Gettys] Gettys, J., "URI Model Consequences",
<http://www.w3.org/DesignIssues/ModelConsequences>.
[HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium
Recommendation, December 1999,
<http://www.w3.org/TR/html401/appendix/
notes.html#h-B.2>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
Atkinson, R., Crispin, M., and P. Svanberg, "The
Report of the IAB Character Set Workshop held 29
February - 1 March, 1996", RFC 2130, April 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September
1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
Duerst & Suignard 标准轨道 [第 41 页]
RFC 3987 国际化资源标识符 2005 年 1 月
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The
mailto URL scheme", RFC 2368, July 1998.
[RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2640] Curtin, B., "Internationalization of the File Transfer
Protocol", RFC 2640, July 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R.
Petke, "Guidelines for new URL Schemes", RFC 2718,
November 1999.
[UNIXML] Duerst, M. and A. Freytag, "Unicode in XML and other
Markup Languages", Unicode Technical Report #20, World
Wide Web Consortium Note, June 2003,
<http://www.w3.org/TR/unicode-xml/>.
[XLink] DeRose, S., Maler, E., and D. Orchard, "XML Linking
Language (XLink) Version 1.0", World Wide Web
Consortium Recommendation, June 2001,
<http://www.w3.org/TR/xlink/#link-locators>.
[XML1] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Third Edition)", World Wide Web Consortium
Recommendation, February 2004,
<http://www.w3.org/TR/REC-xml#sec-external-ent>.
[XMLNamespace] Bray, T., Hollander, D., and A. Layman, "Namespaces in
XML", World Wide Web Consortium Recommendation,
January 1999, <http://www.w3.org/TR/REC-xml-names>.
[XMLSchema] Biron, P. and A. Malhotra, "XML Schema Part 2:
Datatypes", World Wide Web Consortium Recommendation,
May 2001, <http://www.w3.org/TR/xmlschema-2/#anyURI>.
Duerst & Suignard 标准轨道 [第 42 页]
RFC 3987 国际化资源标识符 2005 年 1 月
[XPointer] Grosso, P., Maler, E., Marsh, J. and N. Walsh,
"XPointer Framework", World Wide Web Consortium
Recommendation, March 2003,
<http://www.w3.org/TR/xptr-framework/#escaping>.
Duerst & Suignard 标准轨道 [第 43 页]
RFC 3987 国际化资源标识符 2005 年 1 月
附录 A. 设计替代方案
本节简要总结主要设计替代方案，以及未选择它们的原因。
附录 A.1. 新方案
曾有人提出引入新方案（例如 httpi:、ftpi:，...）或新的元方案
（例如 i:，从而产生诸如 i:http:、i:ftp:，... 的 URI/IRI 前缀），
以使 IRI 到 URI 的转换依赖于方案，或区分由 IRI 到 URI 转换产生的
百分号编码与来自旧式字符编码的百分号编码。
不需要新方案来区分 URI 与真正的 IRI（即包含非 ASCII 字符的 IRI）。
能够检测百分号编码来源的益处很小，因为 UTF-8 可以以非常高的
可靠性被检测出来。部署新方案极其困难，因此不要求为 IRI 提供
新方案会使 IRI 的部署容易得多。使转换依赖于方案是非常不可取的，
而为 IRI 设置单独方案会鼓励这种做法。使用统一约定从 IRI 转换为
URI，使 IRI 实现与实际新方案的引入相互正交。
附录 A.2. UTF-8 以外的字符编码
在早期阶段，当 IRI 转换为 URI 时，曾考虑过用 UTF-7 作为 UTF-8 的
替代方案。UTF-7 不需要百分号编码，并且在大多数情况下会比百分号
编码的 UTF-8 更短。
使用 UTF-8 避免了双重分层以及对 "+" 字符用途的重载。UTF-8 与
US-ASCII 完全兼容，因此已由 IETF 推荐，并且正在被广泛使用。
UTF-7 从未被大量使用，如今显然正被反对。要求实现从 UTF-8 转换为
UTF-7 再转换回来，会带来额外的实现负担。
附录 A.3. 新编码约定
曾有一种想法，不使用现有的基于八位字节的 URI 百分号编码约定，
而是创建新的编码约定；例如使用 "%u" 引入 UCS 码点。
Duerst & Suignard 标准轨道 [第 44 页]
RFC 3987 国际化资源标识符 2005 年 1 月
使用现有的基于八位字节的百分号编码机制，不需要升级 URI 语法，
也不需要相应的服务器升级。
附录 A.4. 在 URI/IRI 中指示字符编码
一些提案建议使用 URI 本身中的某种新语法约定，指示 URI 或 IRI 中
使用的字符编码，类似于电子邮件和网页中的 "charset" 参数。例如，
方括号中的标签
"http://www.example.org/ros[iso-8859-1]é"; 表示后面的
"é"; 必须解释为 iso-8859-1。
如果专门使用 UTF-8，就不需要升级 URI 语法。它避免了可能需要在
所有情况下正确复制多个标签的问题，即使是在公交车侧面或餐巾纸上
也是如此，从而避免可用性问题（以及令人难以忍受的烦扰）。
专门使用 UTF-8 也减少了转码错误和混淆。
作者地址
Martin Duerst （注意：请尽可能将 "Duerst" 写作带 u-umlaut 的形式，
例如在 XML 和 HTML 中写作 "Dürst"。）
World Wide Web Consortium
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
电话：+81 466 49 1170
传真：+81 466 49 1171
电子邮件：duerst@w3.org
URI: http://www.w3.org/People/D%C3%BCrst/
（注意：这是一个 IRI 的百分号编码形式。）
Michel Suignard
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
U.S.A.
电话：+1 425 882-8080
电子邮件：michelsu@microsoft.com
URI: http://www.suignard.com
Duerst & Suignard 标准轨道 [第 45 页]
RFC 3987 国际化资源标识符 2005 年 1 月
完整版权声明
Copyright (C) The Internet Society (2005).
本文档受 BCP 78 中所包含的权利、许可和限制约束；除其中规定
的情况外，作者保留其所有权利。
本文档及其包含的信息按“AS IS”基础提供，贡献者、其所代表或赞助
（如有）的组织、Internet Society 以及 Internet Engineering Task
Force 不作任何明示或默示保证，包括但不限于保证使用本文信息不会
侵犯任何权利，或任何关于适销性或特定用途适用性的默示保证。
知识产权
IETF 对任何可能被声称涉及本文档所述技术的实现或使用的知识产权
或其他权利的有效性或范围不持立场，也不对是否已有或可能已有此类
权利下的任何许可作出立场；同时也不表示它已经独立努力识别任何此类
权利。有关 IETF 对 IETF 文档中权利的处理程序的信息，可见
BCP 78 和 BCP 79。
向 IETF 秘书处提交的 IPR 披露副本以及任何将提供许可的保证，
或实现者或本规范用户为使用此类专有权利而尝试获得一般许可或授权的
结果，可从 IETF 在线 IPR 存储库获得：
http://www.ietf.org/ipr。
IETF 邀请任何相关方提请其注意任何可能覆盖实现本标准所需技术的
版权、专利或专利申请，或其他专有权利。请将相关信息发送给 IETF：
ietf-ipr@ietf.org。
致谢
RFC Editor 职能的经费目前由 Internet Society 提供。
Duerst & Suignard 标准轨道 [第 46 页]