Network Working Group P. Faltstrom
Request for Comments: 3490 Cisco
Category: Standards Track P. Hoffman
IMC & VPNC
A. Costello
UC Berkeley
March 2003
Network Working Group P. Faltstrom
Request for Comments: 3490 Cisco
Category: Standards Track P. Hoffman
IMC & VPNC
A. Costello
UC Berkeley
March 2003
Internationalizing Domain Names in Applications (IDNA)
应用程序中的域名国际化（IDNA）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text.
到目前为止，还没有标准的方法让域名使用ASCII指令表之外的字符。本文档定义了国际化域名（IDN）和一种称为应用程序中域名国际化（IDNA）的机制，用于以标准方式处理它们。IDN使用从大型指令集（Unicode）中提取的字符，但IDNA允许仅使用当前所谓主机名中已经允许的ASCII字符来表示非ASCII字符。在现有协议（如DNS）中需要这种向后兼容的表示，这样就可以在不改变现有基础结构的情况下引入IDN。IDNA仅用于处理域名，而不是自由文本。
Table of Contents
目录
1. Introduction.................................................. 2
1.1 Problem Statement......................................... 3
1.2 Limitations of IDNA....................................... 3
1.3 Brief overview for application developers................. 4
2. Terminology................................................... 5
3. Requirements and applicability................................ 7
3.1 Requirements.............................................. 7
3.2 Applicability............................................. 8
3.2.1. DNS resource records................................ 8
1. Introduction.................................................. 2
1.1 Problem Statement......................................... 3
1.2 Limitations of IDNA....................................... 3
1.3 Brief overview for application developers................. 4
2. Terminology................................................... 5
3. Requirements and applicability................................ 7
3.1 Requirements.............................................. 7
3.2 Applicability............................................. 8
3.2.1. DNS resource records................................ 8
3.2.2. Non-domain-name data types stored in domain names... 9
4. Conversion operations......................................... 9
4.1 ToASCII................................................... 10
4.2 ToUnicode................................................. 11
5. ACE prefix.................................................... 12
6. Implications for typical applications using DNS............... 13
6.1 Entry and display in applications......................... 14
6.2 Applications and resolver libraries....................... 15
6.3 DNS servers............................................... 15
6.4 Avoiding exposing users to the raw ACE encoding........... 16
6.5 DNSSEC authentication of IDN domain names................ 16
7. Name server considerations.................................... 17
8. Root server considerations.................................... 17
9. References.................................................... 18
9.1 Normative References...................................... 18
9.2 Informative References.................................... 18
10. Security Considerations...................................... 19
11. IANA Considerations.......................................... 20
12. Authors' Addresses........................................... 21
13. Full Copyright Statement..................................... 22
3.2.2. Non-domain-name data types stored in domain names... 9
4. Conversion operations......................................... 9
4.1 ToASCII................................................... 10
4.2 ToUnicode................................................. 11
5. ACE prefix.................................................... 12
6. Implications for typical applications using DNS............... 13
6.1 Entry and display in applications......................... 14
6.2 Applications and resolver libraries....................... 15
6.3 DNS servers............................................... 15
6.4 Avoiding exposing users to the raw ACE encoding........... 16
6.5 DNSSEC authentication of IDN domain names................ 16
7. Name server considerations.................................... 17
8. Root server considerations.................................... 17
9. References.................................................... 18
9.1 Normative References...................................... 18
9.2 Informative References.................................... 18
10. Security Considerations...................................... 19
11. IANA Considerations.......................................... 20
12. Authors' Addresses........................................... 21
13. Full Copyright Statement..................................... 22
IDNA works by allowing applications to use certain ASCII name labels (beginning with a special prefix) to represent non-ASCII name labels. Lower-layer protocols need not be aware of this; therefore IDNA does not depend on changes to any infrastructure. In particular, IDNA does not depend on any changes to DNS servers, resolvers, or protocol elements, because the ASCII name service provided by the existing DNS is entirely sufficient for IDNA.
IDNA允许应用程序使用某些ASCII名称标签（以特殊前缀开头）来表示非ASCII名称标签。低层协议不需要意识到这一点；因此，IDNA不依赖于对任何基础设施的更改。特别是，IDNA不依赖于对DNS服务器、解析程序或协议元素的任何更改，因为现有DNS提供的ASCII名称服务对于IDNA来说已经足够了。
This document does not require any applications to conform to IDNA, but applications can elect to use IDNA in order to support IDN while maintaining interoperability with existing infrastructure. If an application wants to use non-ASCII characters in domain names, IDNA is the only currently-defined option. Adding IDNA support to an existing application entails changes to the application only, and leaves room for flexibility in the user interface.
本文档不要求任何应用程序符合IDNA，但应用程序可以选择使用IDNA以支持IDN，同时保持与现有基础架构的互操作性。如果应用程序希望在域名中使用非ASCII字符，IDNA是当前唯一定义的选项。向现有应用程序添加IDNA支持只需要对应用程序进行更改，并在用户界面中留出灵活性的空间。
A great deal of the discussion of IDN solutions has focused on transition issues and how IDN will work in a world where not all of the components have been updated. Proposals that were not chosen by the IDN Working Group would depend on user applications, resolvers, and DNS servers being updated in order for a user to use an internationalized domain name. Rather than rely on widespread updating of all components, IDNA depends on updates to user applications only; no changes are needed to the DNS protocol or any DNS servers or the resolvers on user's computers.
关于IDN解决方案的大量讨论都集中在过渡问题上，以及在一个并非所有组件都已更新的世界中，IDN将如何工作。IDN工作组未选择的方案将取决于用户应用程序、解析程序和DNS服务器的更新，以便用户使用国际化域名。IDNA不依赖于所有组件的广泛更新，而只依赖于用户应用程序的更新；不需要更改DNS协议或任何DNS服务器或用户计算机上的解析程序。
The IDNA specification solves the problem of extending the repertoire of characters that can be used in domain names to include the Unicode repertoire (with some restrictions).
IDNA规范解决了扩展可用于域名的字符库以包括Unicode字符库的问题（有一些限制）。
IDNA does not extend the service offered by DNS to the applications. Instead, the applications (and, by implication, the users) continue to see an exact-match lookup service. Either there is a single exactly-matching name or there is no match. This model has served the existing applications well, but it requires, with or without internationalized domain names, that users know the exact spelling of the domain names that the users type into applications such as web browsers and mail user agents. The introduction of the larger repertoire of characters potentially makes the set of misspellings larger, especially given that in some cases the same appearance, for example on a business card, might visually match several Unicode code points or several sequences of code points.
IDNA不将DNS提供的服务扩展到应用程序。相反，应用程序（以及隐含的用户）继续看到精确的匹配查找服务。要么有一个完全匹配的名称，要么没有匹配的名称。该模型很好地服务于现有的应用程序，但无论是否使用国际化域名，它都要求用户知道用户在web浏览器和邮件用户代理等应用程序中键入的域名的确切拼写。更大的字符库的引入可能会使拼写错误的集合更大，特别是在某些情况下，相同的外观（例如名片上）可能会在视觉上匹配多个Unicode代码点或多个代码点序列。
IDNA allows the graceful introduction of IDNs not only by avoiding upgrades to existing infrastructure (such as DNS servers and mail transport agents), but also by allowing some rudimentary use of IDNs in applications by using the ASCII representation of the non-ASCII name labels. While such names are very user-unfriendly to read and type, and hence are not suitable for user input, they allow (for instance) replying to email and clicking on URLs even though the domain name displayed is incomprehensible to the user. In order to allow user-friendly input and output of the IDNs, the applications need to be modified to conform to this specification.
IDNA不仅通过避免升级现有基础设施（如DNS服务器和邮件传输代理），而且通过使用非ASCII名称标签的ASCII表示，允许在应用程序中初步使用IDN，从而允许优雅地引入IDN。虽然这样的名称对用户阅读和键入非常不友好，因此不适合用户输入，但它们允许（例如）回复电子邮件和单击URL，即使用户无法理解显示的域名。为了允许用户友好地输入和输出IDN，需要修改应用程序以符合本规范。
IDNA uses the Unicode character repertoire, which avoids the significant delays that would be inherent in waiting for a different and specific character set be defined for IDN purposes by some other standards developing organization.
IDNA使用Unicode字符库，这避免了等待其他一些标准开发组织为IDN目的定义不同的特定字符集所固有的重大延迟。
The IDNA protocol does not solve all linguistic issues with users inputting names in different scripts. Many important language-based and script-based mappings are not covered in IDNA and need to be handled outside the protocol. For example, names that are entered in a mix of traditional and simplified Chinese characters will not be mapped to a single canonical name. Another example is Scandinavian names that are entered with U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH STROKE).
IDNA协议不能解决用户在不同脚本中输入姓名的所有语言问题。IDNA中没有涵盖许多重要的基于语言和基于脚本的映射，需要在协议之外处理。例如，以繁体和简体汉字混合输入的名称将不会映射到单个规范名称。另一个例子是，使用U+00F6（带分音符的拉丁小写字母O）输入的斯堪的纳维亚名称将不会映射到U+00F8（带笔划的拉丁小写字母O）。
An example of an important issue that is not considered in detail in IDNA is how to provide a high probability that a user who is entering a domain name based on visual information (such as from a business card or billboard) or aural information (such as from a telephone or radio) would correctly enter the IDN. Similar issues exist for ASCII domain names, for example the possible visual confusion between the letter 'O' and the digit zero, but the introduction of the larger repertoire of characters creates more opportunities of similar looking and similar sounding names. Note that this is a complex issue relating to languages, input methods on computers, and so on. Furthermore, the kind of matching and searching necessary for a high probability of success would not fit the role of the DNS and its exact matching function.
IDNA中未详细考虑的一个重要问题的示例是，如何提供基于视觉信息（如名片或广告牌）或听觉信息（如电话或收音机）输入域名的用户正确输入IDN的高概率。ASCII域名也存在类似的问题，例如字母“O”和数字零之间可能存在视觉混淆，但更大的字符集的引入创造了更多类似外观和发音名称的机会。请注意，这是一个与语言、计算机输入法等相关的复杂问题。此外，高成功概率所需的匹配和搜索类型不适合DNS的角色及其精确匹配功能。
Applications can use IDNA to support internationalized domain names anywhere that ASCII domain names are already supported, including DNS master files and resolver interfaces. (Applications can also define protocols and interfaces that support IDNs directly using non-ASCII representations. IDNA does not prescribe any particular representation for new protocols, but it still defines which names are valid and how they are compared.)
应用程序可以使用IDNA在已经支持ASCII域名的任何地方支持国际化域名，包括DNS主文件和解析器接口。（应用程序还可以定义直接使用非ASCII表示法支持IDN的协议和接口。IDNA没有规定新协议的任何特定表示法，但它仍然定义哪些名称有效以及如何比较它们。）
The IDNA protocol is contained completely within applications. It is not a client-server or peer-to-peer protocol: everything is done inside the application itself. When used with a DNS resolver library, IDNA is inserted as a "shim" between the application and the resolver library. When used for writing names into a DNS zone, IDNA is used just before the name is committed to the zone.
IDNA协议完全包含在应用程序中。它不是客户机-服务器或对等协议：一切都是在应用程序内部完成的。当与DNS解析程序库一起使用时，IDNA作为“垫片”插入到应用程序和解析程序库之间。当用于将名称写入DNS区域时，IDNA将在名称提交到区域之前使用。
There are two operations described in section 4 of this document:
本文件第4节描述了两种操作：
- The ToASCII operation is used before sending an IDN to something that expects ASCII names (such as a resolver) or writing an IDN into a place that expects ASCII names (such as a DNS master file).
- ToASCII操作用于将IDN发送到需要ASCII名称的对象（如解析器）或将IDN写入需要ASCII名称的位置（如DNS主文件）之前。
- The ToUnicode operation is used when displaying names to users, for example names obtained from a DNS zone.
- ToUnicode操作用于向用户显示名称，例如从DNS区域获得的名称。
It is important to note that the ToASCII operation can fail. If it fails when processing a domain name, that domain name cannot be used as an internationalized domain name and the application has to have some method of dealing with this failure.
需要注意的是，ToASCII操作可能会失败。如果在处理域名时失败，则该域名不能用作国际化域名，应用程序必须有某种方法来处理此失败。
IDNA requires that implementations process input strings with Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP], and then with Punycode [PUNYCODE]. Implementations of IDNA MUST
IDNA要求实现使用Nameprep[Nameprep]处理输入字符串，这是Stringprep[Stringprep]的配置文件，然后使用Punycode[Punycode]。IDNA的实现必须
fully implement Nameprep and Punycode; neither Nameprep nor Punycode are optional.
全面实施Nameprep和Punycode；Nameprep和Punycode都不是可选的。
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“应”、“要求”、“应”、“建议”和“可能”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
A code point is an integer value associated with a character in a coded character set.
代码点是与编码字符集中的字符关联的整数值。
Unicode [UNICODE] is a coded character set containing tens of thousands of characters. A single Unicode code point is denoted by "U+" followed by four to six hexadecimal digits, while a range of Unicode code points is denoted by two hexadecimal numbers separated by "..", with no prefixes.
Unicode[Unicode]是一个包含数万个字符的编码字符集。单个Unicode代码点由“U+”表示，后跟四到六个十六进制数字，而Unicode代码点的范围由两个十六进制数字表示，两个数字之间用“.”分隔，没有前缀。
ASCII means US-ASCII [USASCII], a coded character set containing 128 characters associated with code points in the range 0..7F. Unicode is an extension of ASCII: it includes all the ASCII characters and associates them with the same code points.
ASCII表示US-ASCII[USASCII]，一种编码字符集，包含128个字符，与0..7F范围内的代码点相关。Unicode是ASCII的扩展：它包括所有ASCII字符，并将它们与相同的代码点相关联。
The term "LDH code points" is defined in this document to mean the code points associated with ASCII letters, digits, and the hyphen-minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an abbreviation for "letters, digits, hyphen".
本文件中定义的术语“LDH代码点”是指与ASCII字母、数字和连字符减号相关的代码点；即U+002D、30..39、41..5A和61..7A。“LDH”是“字母、数字、连字符”的缩写。
[STD13] talks about "domain names" and "host names", but many people use the terms interchangeably. Further, because [STD13] was not terribly clear, many people who are sure they know the exact definitions of each of these terms disagree on the definitions. In this document the term "domain name" is used in general. This document explicitly cites [STD3] whenever referring to the host name syntax restrictions defined therein.
[STD13]谈到“域名”和“主机名”，但许多人互换使用这些术语。此外，由于[STD13]并不十分清楚，许多确信自己知道这些术语的确切定义的人对定义存在分歧。在本文件中，通常使用术语“域名”。当提及其中定义的主机名语法限制时，本文档明确引用[STD3]。
A label is an individual part of a domain name. Labels are usually shown separated by dots; for example, the domain name "www.example.com" is composed of three labels: "www", "example", and "com". (The zero-length root label described in [STD13], which can be explicit as in "www.example.com." or implicit as in "www.example.com", is not considered a label in this specification.) IDNA extends the set of usable characters in labels that are text. For the rest of this document, the term "label" is shorthand for "text label", and "every label" means "every text label".
标签是域名的一个单独部分。标签通常以点分隔显示；例如，域名“www.example.com”由三个标签组成：“www”、“example”和“com”。（在[STD13]中描述的零长度根标签，可以是“www.example.com”中的显式标签，也可以是“www.example.com”中的隐式标签，在本规范中不被视为标签。）IDNA扩展了文本标签中的可用字符集。对于本文件的其余部分，“标签”是“文本标签”的缩写，“每个标签”是指“每个文本标签”。
An "internationalized label" is a label to which the ToASCII operation (see section 4) can be applied without failing (with the UseSTD3ASCIIRules flag unset). This implies that every ASCII label that satisfies the [STD13] length restriction is an internationalized label. Therefore the term "internationalized label" is a generalization, embracing both old ASCII labels and new non-ASCII labels. Although most Unicode characters can appear in internationalized labels, ToASCII will fail for some input strings, and such strings are not valid internationalized labels.
“国际化标签”是一个可以应用ToASCII操作（参见第4节）而不会失败的标签（未设置UseSTD3ASCIIRules标志）。这意味着每个满足[STD13]长度限制的ASCII标签都是国际化标签。因此，术语“国际化标签”是一种泛化，包括旧的ASCII标签和新的非ASCII标签。尽管大多数Unicode字符可以出现在国际化标签中，但对于某些输入字符串，ToASCII将失败，并且这些字符串不是有效的国际化标签。
An "internationalized domain name" (IDN) is a domain name in which every label is an internationalized label. This implies that every ASCII domain name is an IDN (which implies that it is possible for a name to be an IDN without it containing any non-ASCII characters). This document does not attempt to define an "internationalized host name". Just as has been the case with ASCII names, some DNS zone administrators may impose restrictions, beyond those imposed by DNS or IDNA, on the characters or strings that may be registered as labels in their zones. Such restrictions have no impact on the syntax or semantics of DNS protocol messages; a query for a name that matches no records will yield the same response regardless of the reason why it is not in the zone. Clients issuing queries or interpreting responses cannot be assumed to have any knowledge of zone-specific restrictions or conventions.
“国际化域名”（IDN）是一个域名，其中每个标签都是国际化标签。这意味着每个ASCII域名都是IDN（这意味着一个名称可以是IDN，而不包含任何非ASCII字符）。本文档不尝试定义“国际化主机名”。与ASCII名称一样，一些DNS区域管理员可能会对其区域中可能注册为标签的字符或字符串施加限制（DNS或IDNA施加的限制除外）。此类限制对DNS协议消息的语法或语义没有影响；对不匹配任何记录的名称的查询将产生相同的响应，无论其不在区域中的原因为何。不能假设发出查询或解释响应的客户了解特定区域的限制或约定。
In IDNA, equivalence of labels is defined in terms of the ToASCII operation, which constructs an ASCII form for a given label, whether or not the label was already an ASCII label. Labels are defined to be equivalent if and only if their ASCII forms produced by ToASCII match using a case-insensitive ASCII comparison. ASCII labels already have a notion of equivalence: upper case and lower case are considered equivalent. The IDNA notion of equivalence is an extension of that older notion. Equivalent labels in IDNA are treated as alternate forms of the same label, just as "foo" and "Foo" are treated as alternate forms of the same label.
在IDNA中，标签的等价性是根据ToASCII操作定义的，该操作为给定标签构造ASCII形式，而不管该标签是否已经是ASCII标签。当且仅当ToASCII使用不区分大小写的ASCII比较生成的ASCII形式匹配时，标签才定义为等效。ASCII标签已经有了等价的概念：大写和小写被认为是等价的。IDNA的等价概念是旧概念的延伸。IDNA中的等效标签被视为同一标签的替代形式，正如“foo”和“foo”被视为同一标签的替代形式一样。
To allow internationalized labels to be handled by existing applications, IDNA uses an "ACE label" (ACE stands for ASCII Compatible Encoding). An ACE label is an internationalized label that can be rendered in ASCII and is equivalent to an internationalized label that cannot be rendered in ASCII. Given any internationalized label that cannot be rendered in ASCII, the ToASCII operation will convert it to an equivalent ACE label (whereas an ASCII label will be left unaltered by ToASCII). ACE labels are unsuitable for display to users. The ToUnicode operation will convert any label to an equivalent non-ACE label. In fact, an ACE label is formally defined to be any label that the ToUnicode operation would alter (whereas non-ACE labels are left unaltered by
为了允许现有应用程序处理国际化标签，IDNA使用“ACE标签”（ACE代表ASCII兼容编码）。ACE标签是可以用ASCII表示的国际化标签，相当于不能用ASCII表示的国际化标签。如果任何国际化标签不能以ASCII格式呈现，ToASCII操作会将其转换为等效的ACE标签（而ASCII标签不会被ToASCII更改）。ACE标签不适合向用户显示。ToUnicode操作将任何标签转换为等效的非ACE标签。事实上，ACE标签被正式定义为ToUnicode操作将改变的任何标签（而非ACE标签则保持不变）
ToUnicode). Every ACE label begins with the ACE prefix specified in section 5. The ToASCII and ToUnicode operations are specified in section 4.
图尼科德）。每个ACE标签都以第5节中指定的ACE前缀开头。第4节规定了ToASCII和ToUnicode操作。
The "ACE prefix" is defined in this document to be a string of ASCII characters that appears at the beginning of every ACE label. It is specified in section 5.
“ACE前缀”在本文档中定义为出现在每个ACE标签开头的ASCII字符字符串。第5节对此作了规定。
A "domain name slot" is defined in this document to be a protocol element or a function argument or a return value (and so on) explicitly designated for carrying a domain name. Examples of domain name slots include: the QNAME field of a DNS query; the name argument of the gethostbyname() library function; the part of an email address following the at-sign (@) in the From: field of an email message header; and the host portion of the URI in the src attribute of an HTML <IMG> tag. General text that just happens to contain a domain name is not a domain name slot; for example, a domain name appearing in the plain text body of an email message is not occupying a domain name slot.
“域名槽”在本文档中定义为协议元素、函数参数或显式指定用于承载域名的返回值（等等）。域名槽的示例包括：DNS查询的QNAME字段；gethostbyname（）库函数的name参数；电子邮件消息头的发件人：字段中位于at符号（@）后面的电子邮件地址部分；以及HTML<IMG>标记的src属性中URI的主机部分。恰好包含域名的一般文本不是域名槽；例如，出现在电子邮件纯文本正文中的域名没有占用域名槽。
An "IDN-aware domain name slot" is defined in this document to be a domain name slot explicitly designated for carrying an internationalized domain name as defined in this document. The designation may be static (for example, in the specification of the protocol or interface) or dynamic (for example, as a result of negotiation in an interactive session).
“IDN感知域名槽”在本文件中定义为明确指定用于承载本文件中定义的国际化域名的域名槽。指定可以是静态的（例如，在协议或接口的规范中）或动态的（例如，作为交互会话中协商的结果）。
An "IDN-unaware domain name slot" is defined in this document to be any domain name slot that is not an IDN-aware domain name slot. Obviously, this includes any domain name slot whose specification predates IDNA.
“IDN未知域名插槽”在本文档中定义为非IDN已知域名插槽的任何域名插槽。显然，这包括规范早于IDNA的任何域名槽。
IDNA conformance means adherence to the following four requirements:
IDNA合规性是指遵守以下四项要求：
1) Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop).
1) 当使用点作为标签分隔符时，必须将以下字符识别为点：U+002E（句号）、U+3002（表意句号）、U+FF0E（全幅句号）、U+FF61（半幅表意句号）。
2) Whenever a domain name is put into an IDN-unaware domain name slot (see section 2), it MUST contain only ASCII characters. Given an internationalized domain name (IDN), an equivalent domain name satisfying this requirement can be obtained by applying the
2) 无论何时将域名放入IDN未知域名槽（参见第2节），它必须仅包含ASCII字符。给定一个国际化域名（IDN），可以通过应用
ToASCII operation (see section 4) to each label and, if dots are used as label separators, changing all the label separators to U+002E.
对每个标签进行ToASCII操作（见第4节），如果将点用作标签分隔符，则将所有标签分隔符更改为U+002E。
3) ACE labels obtained from domain name slots SHOULD be hidden from users when it is known that the environment can handle the non-ACE form, except when the ACE form is explicitly requested. When it is not known whether or not the environment can handle the non-ACE form, the application MAY use the non-ACE form (which might fail, such as by not being displayed properly), or it MAY use the ACE form (which will look unintelligle to the user). Given an internationalized domain name, an equivalent domain name containing no ACE labels can be obtained by applying the ToUnicode operation (see section 4) to each label. When requirements 2 and 3 both apply, requirement 2 takes precedence.
3) 当知道环境可以处理非ACE表单时，从域名槽获取的ACE标签应该对用户隐藏，除非明确请求ACE表单。当不知道环境是否可以处理非ACE表单时，应用程序可能会使用非ACE表单（可能会失败，例如未正确显示），或者可能会使用ACE表单（用户看起来不太明白）。给定一个国际化域名，通过对每个标签应用ToUnicode操作（参见第4节），可以获得不包含ACE标签的等效域名。当要求2和3都适用时，要求2优先。
4) Whenever two labels are compared, they MUST be considered to match if and only if they are equivalent, that is, their ASCII forms (obtained by applying ToASCII) match using a case-insensitive ASCII comparison. Whenever two names are compared, they MUST be considered to match if and only if their corresponding labels match, regardless of whether the names use the same forms of label separators.
4) 每当比较两个标签时，必须认为它们匹配当且仅当它们相等时，即它们的ASCII形式（通过应用ToASCII获得）使用不区分大小写的ASCII比较进行匹配。每当比较两个名称时，无论名称是否使用相同形式的标签分隔符，当且仅当其对应的标签匹配时，必须将其视为匹配。
IDNA is applicable to all domain names in all domain name slots except where it is explicitly excluded.
IDNA适用于所有域名槽中的所有域名，明确排除的除外。
This implies that IDNA is applicable to many protocols that predate IDNA. Note that IDNs occupying domain name slots in those protocols MUST be in ASCII form (see section 3.1, requirement 2).
这意味着IDNA适用于IDNA之前的许多协议。请注意，在这些协议中占用域名槽的IDN必须采用ASCII格式（见第3.1节，要求2）。
IDNA does not apply to domain names in the NAME and RDATA fields of DNS resource records whose CLASS is not IN. This exclusion applies to every non-IN class, present and future, except where future standards override this exclusion by explicitly inviting the use of IDNA.
IDNA不适用于类不在中的DNS资源记录的名称和RDATA字段中的域名。此排除适用于所有非类内、当前和未来，除非未来标准通过明确邀请使用IDNA来覆盖此排除。
There are currently no other exclusions on the applicability of IDNA to DNS resource records; it depends entirely on the CLASS, and not on the TYPE. This will remain true, even as new types are defined, unless there is a compelling reason for a new type to complicate matters by imposing type-specific rules.
目前，没有其他排除适用于DNS资源记录的IDNA；它完全取决于类，而不是类型。即使定义了新类型，这仍然是正确的，除非有令人信服的理由让新类型通过强加特定于类型的规则使事情复杂化。
Although IDNA enables the representation of non-ASCII characters in domain names, that does not imply that IDNA enables the representation of non-ASCII characters in other data types that are stored in domain names. For example, an email address local part is sometimes stored in a domain label (hostmaster@example.com would be represented as hostmaster.example.com in the RDATA field of an SOA record). IDNA does not update the existing email standards, which allow only ASCII characters in local parts. Therefore, unless the email standards are revised to invite the use of IDNA for local parts, a domain label that holds the local part of an email address SHOULD NOT begin with the ACE prefix, and even if it does, it is to be interpreted literally as a local part that happens to begin with the ACE prefix.
尽管IDNA支持在域名中表示非ASCII字符，但这并不意味着IDNA支持在存储在域名中的其他数据类型中表示非ASCII字符。例如，电子邮件地址本地部分有时存储在域标签中(hostmaster@example.com将在SOA记录的RDATA字段中表示为hostmaster.example.com）。IDNA不更新现有的电子邮件标准，该标准只允许本地部分使用ASCII字符。因此，除非修改电子邮件标准以允许本地部分使用IDNA，否则包含电子邮件地址本地部分的域标签不应以ACE前缀开头，即使它以ACE前缀开头，也应字面解释为恰好以ACE前缀开头的本地部分。
An application converts a domain name put into an IDN-unaware slot or displayed to a user. This section specifies the steps to perform in the conversion, and the ToASCII and ToUnicode operations.
应用程序将域名转换为IDN插槽或显示给用户。本节指定转换中要执行的步骤，以及ToASCII和ToUnicode操作。
The input to ToASCII or ToUnicode is a single label that is a sequence of Unicode code points (remember that all ASCII code points are also Unicode code points). If a domain name is represented using a character set other than Unicode or US-ASCII, it will first need to be transcoded to Unicode.
ToASCII或ToUnicode的输入是一个单一标签，它是一个Unicode代码点序列（请记住，所有ASCII代码点也是Unicode代码点）。如果域名使用Unicode或US-ASCII以外的字符集表示，则首先需要将其转换为Unicode。
Starting from a whole domain name, the steps that an application takes to do the conversions are:
从整个域名开始，应用程序进行转换的步骤如下：
1) Decide whether the domain name is a "stored string" or a "query string" as described in [STRINGPREP]. If this conversion follows the "queries" rule from [STRINGPREP], set the flag called "AllowUnassigned".
1) 确定域名是[STRINGPREP]中所述的“存储字符串”还是“查询字符串”。如果此转换遵循[STRINGPREP]中的“查询”规则，则设置名为“AllowUnassigned”的标志。
2) Split the domain name into individual labels as described in section 3.1. The labels do not include the separator.
2) 如第3.1节所述，将域名拆分为单独的标签。标签不包括分隔符。
3) For each label, decide whether or not to enforce the restrictions on ASCII characters in host names [STD3]. (Applications already faced this choice before the introduction of IDNA, and can continue to make the decision the same way they always have; IDNA makes no new recommendations regarding this choice.) If the restrictions are to be enforced, set the flag called "UseSTD3ASCIIRules" for that label.
3) 对于每个标签，决定是否对主机名[STD3]中的ASCII字符实施限制。（在引入IDNA之前，应用程序已经面临这一选择，并且可以继续以与以往相同的方式做出决定；IDNA对此选择没有新的建议。）如果要强制实施限制，请为该标签设置名为“UseSTD3ASCIIRules”的标志。
4) Process each label with either the ToASCII or the ToUnicode operation as appropriate. Typically, you use the ToASCII operation if you are about to put the name into an IDN-unaware slot, and you use the ToUnicode operation if you are displaying the name to a user; section 3.1 gives greater detail on the applicable requirements.
4) 使用ToASCII或ToUnicode操作（视情况而定）处理每个标签。通常，如果要将名称放入IDN不知道的插槽中，则使用ToASCII操作；如果要向用户显示名称，则使用ToUnicode操作；第3.1节详细介绍了适用要求。
5) If ToASCII was applied in step 4 and dots are used as label separators, change all the label separators to U+002E (full stop).
5) 如果在步骤4中应用ToASCII，并且点用作标签分隔符，请将所有标签分隔符更改为U+002E（句号）。
The following two subsections define the ToASCII and ToUnicode operations that are used in step 4.
以下两小节定义了步骤4中使用的ToASCII和ToUnicode操作。
This description of the protocol uses specific procedure names, names of flags, and so on, in order to facilitate the specification of the protocol. These names, as well as the actual steps of the procedures, are not required of an implementation. In fact, any implementation which has the same external behavior as specified in this document conforms to this specification.
该协议的描述使用特定的过程名称、标志名称等，以便于协议的规范。这些名称以及程序的实际步骤不是实现所必需的。事实上，任何具有本文档中指定的相同外部行为的实现都符合本规范。
The ToASCII operation takes a sequence of Unicode code points that make up one label and transforms it into a sequence of code points in the ASCII range (0..7F). If ToASCII succeeds, the original sequence and the resulting sequence are equivalent labels.
ToASCII操作获取组成一个标签的Unicode代码点序列，并将其转换为ASCII范围（0..7F）内的代码点序列。如果ToASCII成功，则原始序列和结果序列是等效的标签。
It is important to note that the ToASCII operation can fail. ToASCII fails if any step of it fails. If any step of the ToASCII operation fails on any label in a domain name, that domain name MUST NOT be used as an internationalized domain name. The method for dealing with this failure is application-specific.
需要注意的是，ToASCII操作可能会失败。如果ToASCII的任何一步都失败了，它就会失败。如果ToASCII操作的任何步骤在域名中的任何标签上失败，则该域名不得用作国际化域名。处理此故障的方法是特定于应用程序的。
The inputs to ToASCII are a sequence of code points, the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of ToASCII is either a sequence of ASCII code points or a failure condition.
ToASCII的输入是一系列代码点、allowunasigned标志和usestd3ascirules标志。ToASCII的输出为ASCII码点序列或故障条件。
ToASCII never alters a sequence of code points that are all in the ASCII range to begin with (although it could fail). Applying the ToASCII operation multiple times has exactly the same effect as applying it just once.
ToASCII从不更改一系列代码点，这些代码点都在ASCII范围内（尽管可能会失败）。多次应用ToASCII操作的效果与仅应用一次完全相同。
ToASCII consists of the following steps:
ToASCII由以下步骤组成：
1. If the sequence contains any code points outside the ASCII range (0..7F) then proceed to step 2, otherwise skip to step 3.
1. 如果序列包含ASCII范围（0..7F）以外的任何代码点，则继续执行步骤2，否则跳至步骤3。
2. Perform the steps specified in [NAMEPREP] and fail if there is an error. The AllowUnassigned flag is used in [NAMEPREP].
2. 执行[NAMEPREP]中指定的步骤，如果出现错误，则失败。AllowUnassigned标志用于[NAMEPREP]。
3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
3. 如果设置了UseSTD3ASCIIRules标志，则执行以下检查：
(a) Verify the absence of non-LDH ASCII code points; that is, the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
(a) 验证是否存在非LDH ASCII码点；也就是说，没有0..2C、2E..2F、3A..40、5B..60和7B..7F。
(b) Verify the absence of leading and trailing hyphen-minus; that is, the absence of U+002D at the beginning and end of the sequence.
(b) 验证是否缺少前导和尾随连字符减号；也就是说，在序列的开始和结束处不存在U+002D。
4. If the sequence contains any code points outside the ASCII range (0..7F) then proceed to step 5, otherwise skip to step 8.
4. 如果序列包含ASCII范围（0..7F）之外的任何代码点，则继续执行步骤5，否则跳至步骤8。
5. Verify that the sequence does NOT begin with the ACE prefix.
5. 验证序列是否以ACE前缀开头。
6. Encode the sequence using the encoding algorithm in [PUNYCODE] and fail if there is an error.
6. 使用[PUNYCODE]中的编码算法对序列进行编码，如果出现错误，则编码失败。
7. Prepend the ACE prefix.
7. 在ACE前缀前加前缀。
8. Verify that the number of code points is in the range 1 to 63 inclusive.
8. 验证代码点数是否在1到63之间（含1到63）。
The ToUnicode operation takes a sequence of Unicode code points that make up one label and returns a sequence of Unicode code points. If the input sequence is a label in ACE form, then the result is an equivalent internationalized label that is not in ACE form, otherwise the original sequence is returned unaltered.
ToUnicode操作获取组成一个标签的Unicode代码点序列，并返回Unicode代码点序列。如果输入序列是ACE格式的标签，则结果是不采用ACE格式的等效国际化标签，否则将原封不动地返回原始序列。
ToUnicode never fails. If any step fails, then the original input sequence is returned immediately in that step.
图尼科德从不失败。如果任何步骤失败，则在该步骤中立即返回原始输入序列。
The ToUnicode output never contains more code points than its input. Note that the number of octets needed to represent a sequence of code points depends on the particular character encoding used.
ToUnicode输出包含的代码点永远不会超过其输入。请注意，表示代码点序列所需的八位字节数取决于所使用的特定字符编码。
The inputs to ToUnicode are a sequence of code points, the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of ToUnicode is always a sequence of Unicode code points.
ToUnicode的输入是一系列代码点、allowunasigned标志和usestd3ascirules标志。ToUnicode的输出总是一个Unicode代码点序列。
1. If all code points in the sequence are in the ASCII range (0..7F) then skip to step 3.
1. 如果序列中的所有代码点都在ASCII范围（0..7F）内，则跳到步骤3。
2. Perform the steps specified in [NAMEPREP] and fail if there is an error. (If step 3 of ToASCII is also performed here, it will not affect the overall behavior of ToUnicode, but it is not necessary.) The AllowUnassigned flag is used in [NAMEPREP].
2. 执行[NAMEPREP]中指定的步骤，如果出现错误，则失败。（如果此处也执行了ToASCII的步骤3，则不会影响ToUnicode的整体行为，但这不是必需的。）[NAMEPREP]中使用AllowUnassigned标志。
3. Verify that the sequence begins with the ACE prefix, and save a copy of the sequence.
3. 验证序列是否以ACE前缀开头，并保存序列的副本。
4. Remove the ACE prefix.
4. 删除ACE前缀。
5. Decode the sequence using the decoding algorithm in [PUNYCODE] and fail if there is an error. Save a copy of the result of this step.
5. 使用[PUNYCODE]中的解码算法解码序列，如果出现错误，则解码失败。保存此步骤结果的副本。
6. Apply ToASCII.
6. 应用ToASCII。
7. Verify that the result of step 6 matches the saved copy from step 3, using a case-insensitive ASCII comparison.
7. 使用不区分大小写的ASCII比较，验证步骤6的结果是否与步骤3中保存的副本匹配。
8. Return the saved copy from step 5.
8. 从步骤5返回保存的副本。
The ACE prefix, used in the conversion operations (section 4), is two alphanumeric ASCII characters followed by two hyphen-minuses. It cannot be any of the prefixes already used in earlier documents, which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--" and "zq--". The ToASCII and ToUnicode operations MUST recognize the ACE prefix in a case-insensitive manner.
转换操作（第4节）中使用的ACE前缀是两个字母数字ASCII字符，后跟两个连字符减号。它不能是早期文档中已经使用的任何前缀，其中包括：“bl-”、“bq-”、“dq-”、“lq-”、“mq-”、“ra-”、“wq-”和“zq-”。ToASCII和ToUnicode操作必须以不区分大小写的方式识别ACE前缀。
The ACE prefix for IDNA is "xn--" or any capitalization thereof.
IDNA的ACE前缀为“xn--”或其任何大写字母。
This means that an ACE label might be "xn--de-jg4avhby1noc0d", where "de-jg4avhby1noc0d" is the part of the ACE label that is generated by the encoding steps in [PUNYCODE].
这意味着ACE标签可能是“xn--de-jg4avhby1noc0d”，其中“de-jg4avhby1noc0d”是由[PUNYCODE]中的编码步骤生成的ACE标签的一部分。
While all ACE labels begin with the ACE prefix, not all labels beginning with the ACE prefix are necessarily ACE labels. Non-ACE labels that begin with the ACE prefix will confuse users and SHOULD NOT be allowed in DNS zones.
虽然所有ACE标签都以ACE前缀开头，但并非所有以ACE前缀开头的标签都必须是ACE标签。以ACE前缀开头的非ACE标签将混淆用户，不应允许在DNS区域中使用。
In IDNA, applications perform the processing needed to input internationalized domain names from users, display internationalized domain names to users, and process the inputs and outputs from DNS and other protocols that carry domain names.
在IDNA中，应用程序执行从用户输入国际化域名所需的处理，向用户显示国际化域名，并处理DNS和其他承载域名的协议的输入和输出。
The components and interfaces between them can be represented pictorially as:
它们之间的组件和接口可以用图形表示为：
+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+-------------------|-------------------------------+
| v |
| +-----------------------------+ |
| | Application | |
| | (ToASCII and ToUnicode | |
| | operations may be | |
| | called here) | |
| +-----------------------------+ |
| ^ ^ | End system
| | | |
| Call to resolver: | | Application-specific |
| ACE | | protocol: |
| v | ACE unless the |
| +----------+ | protocol is updated |
| | Resolver | | to handle other |
| +----------+ | encodings |
| ^ | |
+-----------------|----------|----------------------+
DNS protocol: | |
ACE | |
v v
+-------------+ +---------------------+
| DNS servers | | Application servers |
+-------------+ +---------------------+
+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+-------------------|-------------------------------+
| v |
| +-----------------------------+ |
| | Application | |
| | (ToASCII and ToUnicode | |
| | operations may be | |
| | called here) | |
| +-----------------------------+ |
| ^ ^ | End system
| | | |
| Call to resolver: | | Application-specific |
| ACE | | protocol: |
| v | ACE unless the |
| +----------+ | protocol is updated |
| | Resolver | | to handle other |
| +----------+ | encodings |
| ^ | |
+-----------------|----------|----------------------+
DNS protocol: | |
ACE | |
v v
+-------------+ +---------------------+
| DNS servers | | Application servers |
+-------------+ +---------------------+
The box labeled "Application" is where the application splits a domain name into labels, sets the appropriate flags, and performs the ToASCII and ToUnicode operations. This is described in section 4.
标记为“应用程序”的框是应用程序将域名拆分为标签、设置适当标志并执行ToASCII和ToUnicode操作的地方。第4节对此进行了描述。
Applications can accept domain names using any character set or sets desired by the application developer, and can display domain names in any charset. That is, the IDNA protocol does not affect the interface between users and applications.
应用程序可以使用应用程序开发人员所需的任何字符集接受域名，并且可以在任何字符集中显示域名。也就是说，IDNA协议不会影响用户和应用程序之间的接口。
An IDNA-aware application can accept and display internationalized domain names in two formats: the internationalized character set(s) supported by the application, and as an ACE label. ACE labels that are displayed or input MUST always include the ACE prefix. Applications MAY allow input and display of ACE labels, but are not encouraged to do so except as an interface for special purposes, possibly for debugging, or to cope with display limitations as described in section 6.4.. ACE encoding is opaque and ugly, and should thus only be exposed to users who absolutely need it. Because name labels encoded as ACE name labels can be rendered either as the encoded ASCII characters or the proper decoded characters, the application MAY have an option for the user to select the preferred method of display; if it does, rendering the ACE SHOULD NOT be the default.
支持IDNA的应用程序可以接受和显示两种格式的国际化域名：应用程序支持的国际化字符集和ACE标签。显示或输入的ACE标签必须始终包含ACE前缀。应用程序可允许输入和显示ACE标签，但不鼓励这样做，除非作为特殊用途的接口，可能用于调试，或处理第6.4节所述的显示限制。。ACE编码是不透明和丑陋的，因此应该只向绝对需要它的用户公开。由于编码为ACE名称标签的名称标签可以呈现为编码的ASCII字符或正确的解码字符，因此应用程序可能具有供用户选择首选显示方法的选项；如果是，则不应默认渲染ACE。
Domain names are often stored and transported in many places. For example, they are part of documents such as mail messages and web pages. They are transported in many parts of many protocols, such as both the control commands and the RFC 2822 body parts of SMTP, and the headers and the body content in HTTP. It is important to remember that domain names appear both in domain name slots and in the content that is passed over protocols.
域名经常在许多地方存储和传输。例如，它们是文档（如邮件和网页）的一部分。它们在许多协议的许多部分中传输，例如SMTP的控制命令和RFC 2822主体部分，以及HTTP中的头和主体内容。请务必记住，域名同时出现在域名槽和通过协议传递的内容中。
In protocols and document formats that define how to handle specification or negotiation of charsets, labels can be encoded in any charset allowed by the protocol or document format. If a protocol or document format only allows one charset, the labels MUST be given in that charset.
在定义如何处理字符集规范或协商的协议和文档格式中，标签可以用协议或文档格式允许的任何字符集编码。如果协议或文档格式只允许一个字符集，则必须在该字符集中给出标签。
In any place where a protocol or document format allows transmission of the characters in internationalized labels, internationalized labels SHOULD be transmitted using whatever character encoding and escape mechanism that the protocol or document format uses at that place.
在协议或文档格式允许在国际化标签中传输字符的任何地方，国际化标签应使用协议或文档格式在该地方使用的任何字符编码和转义机制进行传输。
All protocols that use domain name slots already have the capacity for handling domain names in the ASCII charset. Thus, ACE labels (internationalized labels that have been processed with the ToASCII operation) can inherently be handled by those protocols.
所有使用域名插槽的协议都已具备处理ASCII字符集中域名的能力。因此，ACE标签（已通过ToASCII操作处理的国际化标签）本质上可以由这些协议处理。
Applications normally use functions in the operating system when they resolve DNS queries. Those functions in the operating system are often called "the resolver library", and the applications communicate with the resolver libraries through a programming interface (API).
应用程序通常在解析DNS查询时使用操作系统中的函数。操作系统中的这些函数通常称为“解析器库”，应用程序通过编程接口（API）与解析器库通信。
Because these resolver libraries today expect only domain names in ASCII, applications MUST prepare labels that are passed to the resolver library using the ToASCII operation. Labels received from the resolver library contain only ASCII characters; internationalized labels that cannot be represented directly in ASCII use the ACE form. ACE labels always include the ACE prefix.
因为现在这些解析器库只需要ASCII格式的域名，所以应用程序必须准备标签，这些标签使用ToASCII操作传递给解析器库。从解析器库接收的标签仅包含ASCII字符；不能直接用ASCII表示的国际化标签使用ACE格式。ACE标签始终包含ACE前缀。
An operating system might have a set of libraries for performing the ToASCII operation. The input to such a library might be in one or more charsets that are used in applications (UTF-8 and UTF-16 are likely candidates for almost any operating system, and script-specific charsets are likely for localized operating systems).
操作系统可能有一组库来执行ToASCII操作。此类库的输入可能在应用程序中使用的一个或多个字符集中（UTF-8和UTF-16可能适用于几乎任何操作系统，脚本特定字符集可能适用于本地化操作系统）。
IDNA-aware applications MUST be able to work with both non-internationalized labels (those that conform to [STD13] and [STD3]) and internationalized labels.
支持IDNA的应用程序必须能够使用非国际化标签（符合[STD13]和[STD3]的标签）和国际化标签。
It is expected that new versions of the resolver libraries in the future will be able to accept domain names in other charsets than ASCII, and application developers might one day pass not only domain names in Unicode, but also in local script to a new API for the resolver libraries in the operating system. Thus the ToASCII and ToUnicode operations might be performed inside these new versions of the resolver libraries.
预计未来新版本的冲突解决程序库将能够接受ASCII以外的其他字符集中的域名，应用程序开发人员有朝一日可能不仅会将Unicode中的域名传递给操作系统中冲突解决程序库的新API，还会将本地脚本中的域名传递给该API。因此，ToASCII和ToUnicode操作可以在这些新版本的解析器库中执行。
Domain names passed to resolvers or put into the question section of DNS requests follow the rules for "queries" from [STRINGPREP].
传递给解析程序或放入DNS请求问题部分的域名遵循[STRINGPREP]的“查询”规则。
Domain names stored in zones follow the rules for "stored strings" from [STRINGPREP].
存储在区域中的域名遵循[STRINGPREP]中的“存储字符串”规则。
For internationalized labels that cannot be represented directly in ASCII, DNS servers MUST use the ACE form produced by the ToASCII operation. All IDNs served by DNS servers MUST contain only ASCII characters.
对于不能直接用ASCII表示的国际化标签，DNS服务器必须使用ToASCII操作生成的ACE表单。DNS服务器提供的所有IDN必须仅包含ASCII字符。
If a signaling system which makes negotiation possible between old and new DNS clients and servers is standardized in the future, the encoding of the query in the DNS protocol itself can be changed from
如果使新旧DNS客户端和服务器之间的协商成为可能的信令系统在将来被标准化，则DNS协议本身中查询的编码可以从
ACE to something else, such as UTF-8. The question whether or not this should be used is, however, a separate problem and is not discussed in this memo.
将ACE转换为其他内容，例如UTF-8。然而，是否应使用此项的问题是一个单独的问题，本备忘录中未讨论。
Any application that might show the user a domain name obtained from a domain name slot, such as from gethostbyaddr or part of a mail header, will need to be updated if it is to prevent users from seeing the ACE.
任何可能向用户显示从域名槽获得的域名的应用程序，例如从gethostbyaddr或邮件头的一部分获得的域名，如果是为了防止用户看到ACE，则需要进行更新。
If an application decodes an ACE name using ToUnicode but cannot show all of the characters in the decoded name, such as if the name contains characters that the output system cannot display, the application SHOULD show the name in ACE format (which always includes the ACE prefix) instead of displaying the name with the replacement character (U+FFFD). This is to make it easier for the user to transfer the name correctly to other programs. Programs that by default show the ACE form when they cannot show all the characters in a name label SHOULD also have a mechanism to show the name that is produced by the ToUnicode operation with as many characters as possible and replacement characters in the positions where characters cannot be displayed.
如果应用程序使用ToUnicode对ACE名称进行解码，但无法显示解码名称中的所有字符，例如，如果名称包含输出系统无法显示的字符，则应用程序应以ACE格式（始终包含ACE前缀）显示名称，而不是使用替换字符显示名称（U+FFFD）。这是为了让用户更容易将名称正确地传输到其他程序。默认情况下，当无法在名称标签中显示所有字符时，程序会显示ACE表单，还应具有一种机制，以尽可能多的字符和替换字符显示ToUnicode操作生成的名称e无法显示字符的位置。
The ToUnicode operation does not alter labels that are not valid ACE labels, even if they begin with the ACE prefix. After ToUnicode has been applied, if a label still begins with the ACE prefix, then it is not a valid ACE label, and is not equivalent to any of the intermediate Unicode strings constructed by ToUnicode.
ToUnicode操作不会更改无效的ACE标签，即使这些标签以ACE前缀开头。应用ToUnicode后，如果标签仍然以ACE前缀开头，则它不是有效的ACE标签，并且不等同于ToUnicode构造的任何中间Unicode字符串。
DNS Security [RFC2535] is a method for supplying cryptographic verification information along with DNS messages. Public Key Cryptography is used in conjunction with digital signatures to provide a means for a requester of domain information to authenticate the source of the data. This ensures that it can be traced back to a trusted source, either directly, or via a chain of trust linking the source of the information to the top of the DNS hierarchy.
DNS安全[RFC2535]是一种与DNS消息一起提供加密验证信息的方法。公钥加密技术与数字签名结合使用，为域信息请求者提供了验证数据源的手段。这确保了可以直接或通过将信息源链接到DNS层次结构顶部的信任链将其追溯到受信任的源。
IDNA specifies that all internationalized domain names served by DNS servers that cannot be represented directly in ASCII must use the ACE form produced by the ToASCII operation. This operation must be performed prior to a zone being signed by the private key for that zone. Because of this ordering, it is important to recognize that DNSSEC authenticates the ASCII domain name, not the Unicode form or
IDNA指定DNS服务器提供的所有不能直接用ASCII表示的国际化域名必须使用ToASCII操作生成的ACE格式。此操作必须在区域被该区域的私钥签名之前执行。由于这种顺序，必须认识到DNSSEC认证的是ASCII域名，而不是Unicode格式或名称
the mapping between the Unicode form and the ASCII form. In the presence of DNSSEC, this is the name that MUST be signed in the zone and MUST be validated against.
Unicode表单和ASCII表单之间的映射。在DNSSEC在场的情况下，这是必须在区域中签名并根据其进行验证的名称。
One consequence of this for sites deploying IDNA in the presence of DNSSEC is that any special purpose proxies or forwarders used to transform user input into IDNs must be earlier in the resolution flow than DNSSEC authenticating nameservers for DNSSEC to work.
对于在DNSSEC在场的情况下部署IDNA的站点而言，这样做的一个后果是，用于将用户输入转换为IDN的任何专用代理或转发器在解析流中必须早于DNSSEC验证名称服务器，以便DNSSEC工作。
Existing DNS servers do not know the IDNA rules for handling non-ASCII forms of IDNs, and therefore need to be shielded from them. All existing channels through which names can enter a DNS server database (for example, master files [STD13] and DNS update messages [RFC2136]) are IDN-unaware because they predate IDNA, and therefore requirement 2 of section 3.1 of this document provides the needed shielding, by ensuring that internationalized domain names entering DNS server databases through such channels have already been converted to their equivalent ASCII forms.
现有DNS服务器不知道处理非ASCII形式IDN的IDNA规则，因此需要屏蔽这些规则。名称可通过其进入DNS服务器数据库的所有现有通道（例如，主文件[STD13]和DNS更新消息[RFC2136]）都不知道IDN，因为它们早于IDNA，因此本文件第3.1节的要求2提供了所需的屏蔽，通过确保通过此类通道进入DNS服务器数据库的国际化域名已转换为其等效的ASCII格式。
It is imperative that there be only one ASCII encoding for a particular domain name. Because of the design of the ToASCII and ToUnicode operations, there are no ACE labels that decode to ASCII labels, and therefore name servers cannot contain multiple ASCII encodings of the same domain name.
一个特定域名必须只有一个ASCII编码。由于ToASCII和ToUnicode操作的设计，没有解码为ASCII标签的ACE标签，因此名称服务器不能包含同一域名的多个ASCII编码。
[RFC2181] explicitly allows domain labels to contain octets beyond the ASCII range (0..7F), and this document does not change that. Note, however, that there is no defined interpretation of octets 80..FF as characters. If labels containing these octets are returned to applications, unpredictable behavior could result. The ASCII form defined by ToASCII is the only standard representation for internationalized labels in the current DNS protocol.
[RFC2181]明确允许域标签包含超出ASCII范围（0..7F）的八位字节，本文档不会改变这一点。但是，请注意，八位字节80..FF作为字符没有定义的解释。如果将包含这些八位字节的标签返回给应用程序，可能会导致不可预测的行为。ToASCII定义的ASCII格式是当前DNS协议中国际化标签的唯一标准表示形式。
IDNs are likely to be somewhat longer than current domain names, so the bandwidth needed by the root servers is likely to go up by a small amount. Also, queries and responses for IDNs will probably be somewhat longer than typical queries today, so more queries and responses may be forced to go to TCP instead of UDP.
IDN可能比当前域名稍长，因此根服务器所需的带宽可能会小幅增加。此外，IDN的查询和响应可能比今天的典型查询要长一些，因此可能会有更多的查询和响应被迫转到TCP而不是UDP。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[STRINGPREP]Hoffman，P.和M.Blanchet，“国际化弦的准备（“STRINGPREP”）”，RFC 3454，2002年12月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[NAMEPREP]Hoffman，P.和M.Blanchet，“NAMEPREP：国际化域名（IDN）的Stringprep配置文件”，RFC 34912003年3月。
[PUNYCODE] Costello, A., "Punycode: A Bootstring encoding of Unicode for use with Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[PUNYCODE]Costello，A.，“PUNYCODE:Unicode引导字符串编码，用于应用程序中的国际化域名（IDNA）”，RFC 3492，2003年3月。
[STD3] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, and "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[STD3]Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122和“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034 and "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[STD13]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034和“域名-实施和规范”，STD 13，RFC 1035，1987年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm, <http://www.unicode.org/unicode/reports/tr9/>.
[UAX9]Unicode标准附录#9，双向算法<http://www.unicode.org/unicode/reports/tr9/>.
[UNICODE] The Unicode Consortium. The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).
[UNICODE]UNICODE联盟。Unicode标准3.2.0版由Unicode标准3.0版（雷丁，马萨诸塞州，Addison-Wesley，2000.ISBN 0-201-61633-5）定义，并由Unicode标准附录27:Unicode 3.1修订(http://www.unicode.org/reports/tr27/)根据Unicode标准附录#28:Unicode 3.2(http://www.unicode.org/reports/tr28/).
[USASCII] Cerf, V., "ASCII format for Network Interchange", RFC 20, October 1969.
[USASCII]Cerf，V.，“网络交换的ASCII格式”，RFC 20，1969年10月。
Security on the Internet partly relies on the DNS. Thus, any change to the characteristics of the DNS can change the security of much of the Internet.
互联网上的安全部分依赖于DNS。因此，DNS特性的任何改变都可能改变互联网的大部分安全性。
This memo describes an algorithm which encodes characters that are not valid according to STD3 and STD13 into octet values that are valid. No security issues such as string length increases or new allowed values are introduced by the encoding process or the use of these encoded values, apart from those introduced by the ACE encoding itself.
本备忘录描述了一种算法，该算法将根据STD3和STD13无效的字符编码为有效的八位字节值。除了ACE编码本身引入的安全问题外，编码过程或这些编码值的使用不会引入任何安全问题，如字符串长度增加或新的允许值。
Domain names are used by users to identify and connect to Internet servers. The security of the Internet is compromised if a user entering a single internationalized name is connected to different servers based on different interpretations of the internationalized domain name.
域名被用户用来识别和连接互联网服务器。如果输入单个国际化域名的用户根据对国际化域名的不同解释连接到不同的服务器，则会危及互联网的安全。
When systems use local character sets other than ASCII and Unicode, this specification leaves the the problem of transcoding between the local character set and Unicode up to the application. If different applications (or different versions of one application) implement different transcoding rules, they could interpret the same name differently and contact different servers. This problem is not solved by security protocols like TLS that do not take local character sets into account.
当系统使用ASCII和Unicode以外的本地字符集时，本规范将本地字符集和Unicode之间的转码问题留给应用程序处理。如果不同的应用程序（或一个应用程序的不同版本）实现不同的代码转换规则，它们可能会对同一名称进行不同的解释，并联系不同的服务器。像TLS这样不考虑本地字符集的安全协议并不能解决这个问题。
Because this document normatively refers to [NAMEPREP], [PUNYCODE], and [STRINGPREP], it includes the security considerations from those documents as well.
由于本文档规范性地引用了[NAMEPREP]、[PUNYCODE]和[STRINGPREP]，因此它还包括这些文档中的安全注意事项。
If or when this specification is updated to use a more recent Unicode normalization table, the new normalization table will need to be compared with the old to spot backwards incompatible changes. If there are such changes, they will need to be handled somehow, or there will be security as well as operational implications. Methods to handle the conflicts could include keeping the old normalization, or taking care of the conflicting characters by operational means, or some other method.
如果或当更新此规范以使用较新的Unicode规范化表时，需要将新的规范化表与旧的规范化表进行比较，以发现向后不兼容的更改。如果有这样的变化，他们将需要以某种方式处理，否则将有安全以及操作的影响。处理冲突的方法可以包括保持旧的规范化，或者通过操作手段处理冲突字符，或者其他一些方法。
Implementations MUST NOT use more recent normalization tables than the one referenced from this document, even though more recent tables may be provided by operating systems. If an application is unsure of which version of the normalization tables are in the operating
实现不能使用比本文引用的规范化表更新的规范化表，即使操作系统可能提供更新的表。如果应用程序不确定操作系统中规范化表的版本
system, the application needs to include the normalization tables itself. Using normalization tables other than the one referenced from this specification could have security and operational implications.
在系统中，应用程序需要包含规范化表本身。使用本规范中引用的规范化表以外的规范化表可能会带来安全和操作方面的影响。
To help prevent confusion between characters that are visually similar, it is suggested that implementations provide visual indications where a domain name contains multiple scripts. Such mechanisms can also be used to show when a name contains a mixture of simplified and traditional Chinese characters, or to distinguish zero and one from O and l. DNS zone adminstrators may impose restrictions (subject to the limitations in section 2) that try to minimize homographs.
为了帮助防止视觉上相似的字符之间的混淆，建议实现在域名包含多个脚本时提供视觉指示。这种机制还可以用于显示名称何时包含简体和繁体汉字，或者区分零和一与O和l。DNS区域管理员可能会施加限制（受第2节限制的约束），以尽量减少同形词。
Domain names (or portions of them) are sometimes compared against a set of privileged or anti-privileged domains. In such situations it is especially important that the comparisons be done properly, as specified in section 3.1 requirement 4. For labels already in ASCII form, the proper comparison reduces to the same case-insensitive ASCII comparison that has always been used for ASCII labels.
域名（或部分域名）有时会与一组特权域或反特权域进行比较。在这种情况下，按照第3.1节要求4的规定，正确进行比较尤为重要。对于已经采用ASCII格式的标签，适当的比较将简化为始终用于ASCII标签的不区分大小写的ASCII比较。
The introduction of IDNA means that any existing labels that start with the ACE prefix and would be altered by ToUnicode will automatically be ACE labels, and will be considered equivalent to non-ASCII labels, whether or not that was the intent of the zone adminstrator or registrant.
IDNA的引入意味着任何以ACE前缀开头并将由ToUnicode更改的现有标签将自动成为ACE标签，并将被视为等同于非ASCII标签，无论这是否是区域管理员或注册人的意图。
IANA has assigned the ACE prefix in consultation with the IESG.
IANA已与IESG协商分配ACE前缀。
Patrik Faltstrom Cisco Systems Arstaangsvagen 31 J S-117 43 Stockholm Sweden
Patrik Faltstrom Cisco Systems Arstaangsvagen 31 J S-117 43瑞典斯德哥尔摩
EMail: paf@cisco.com
EMail: paf@cisco.com
Paul Hoffman Internet Mail Consortium and VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
保罗·霍夫曼互联网邮件联盟和VPN联盟美国加利福尼亚州圣克鲁斯塞格雷广场127号，邮编95060
EMail: phoffman@imc.org
EMail: phoffman@imc.org
Adam M. Costello University of California, Berkeley
亚当·M·科斯特洛加利福尼亚大学加利福尼亚大学伯克利
URL: http://www.nicemice.net/amc/
URL: http://www.nicemice.net/amc/
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。