Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6365 VPN Consortium
BCP: 166 J. Klensin
Obsoletes: 3536 September 2011
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6365 VPN Consortium
BCP: 166 J. Klensin
Obsoletes: 3536 September 2011
Category: Best Current Practice
ISSN: 2070-1721
Terminology Used in Internationalization in the IETF
IETF国际化中使用的术语
Abstract
摘要
This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.
本文档提供了IETF讨论国际化时使用的术语列表。目的是帮助构建IETF各领域国际化讨论的框架，并帮助向IETF参与者介绍主要概念。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6365.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6365.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose of this Document . . . . . . . . . . . . . . . . . 3
1.2. Format of the Definitions in This Document . . . . . . . . 4
1.3. Normative Terminology . . . . . . . . . . . . . . . . . . 4
2. Fundamental Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Standards Bodies and Standards . . . . . . . . . . . . . . . . 10
3.1. Standards Bodies . . . . . . . . . . . . . . . . . . . . . 11
3.2. Encodings and Transformation Formats of ISO/IEC 10646 . . 13
3.3. Native CCSs and Charsets . . . . . . . . . . . . . . . . . 15
4. Character Issues . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Types of Characters . . . . . . . . . . . . . . . . . . . 20
4.2. Differentiation of Subsets . . . . . . . . . . . . . . . . 23
5. User Interface for Text . . . . . . . . . . . . . . . . . . . 24
6. Text in Current IETF Protocols . . . . . . . . . . . . . . . . 27
7. Terms Associated with Internationalized Domain Names . . . . . 31
7.1. IDNA Terminology . . . . . . . . . . . . . . . . . . . . . 31
7.2. Character Relationships and Variants . . . . . . . . . . . 32
8. Other Common Terms in Internationalization . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. Additional Interesting Reading . . . . . . . . . . . 41
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Appendix C. Significant Changes from RFC 3536 . . . . . . . . . . 42
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose of this Document . . . . . . . . . . . . . . . . . 3
1.2. Format of the Definitions in This Document . . . . . . . . 4
1.3. Normative Terminology . . . . . . . . . . . . . . . . . . 4
2. Fundamental Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Standards Bodies and Standards . . . . . . . . . . . . . . . . 10
3.1. Standards Bodies . . . . . . . . . . . . . . . . . . . . . 11
3.2. Encodings and Transformation Formats of ISO/IEC 10646 . . 13
3.3. Native CCSs and Charsets . . . . . . . . . . . . . . . . . 15
4. Character Issues . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Types of Characters . . . . . . . . . . . . . . . . . . . 20
4.2. Differentiation of Subsets . . . . . . . . . . . . . . . . 23
5. User Interface for Text . . . . . . . . . . . . . . . . . . . 24
6. Text in Current IETF Protocols . . . . . . . . . . . . . . . . 27
7. Terms Associated with Internationalized Domain Names . . . . . 31
7.1. IDNA Terminology . . . . . . . . . . . . . . . . . . . . . 31
7.2. Character Relationships and Variants . . . . . . . . . . . 32
8. Other Common Terms in Internationalization . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. Additional Interesting Reading . . . . . . . . . . . 41
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Appendix C. Significant Changes from RFC 3536 . . . . . . . . . . 42
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
As the IETF Character Set Policy specification [RFC2277] summarizes: "Internationalization is for humans. This means that protocols are not subject to internationalization; text strings are." Many protocols throughout the IETF use text strings that are entered by, or are visible to, humans. Subject only to the limitations of their own knowledge and facilities, it should be possible for anyone to enter or read these text strings, which means that Internet users must be able to enter text using typical input methods and have it be displayed in any human language. Further, text containing any character should be able to be passed between Internet applications easily. This is the challenge of internationalization.
正如IETF字符集策略规范[RFC2277]总结的那样：“国际化是为人类而设的。这意味着协议不受国际化的约束；文本字符串受国际化的约束。”整个IETF中的许多协议使用由人类输入或可见的文本字符串。仅受自身知识和设施的限制，任何人都可以输入或读取这些文本字符串，这意味着互联网用户必须能够使用典型的输入方法输入文本，并以任何人类语言显示文本。此外，包含任何字符的文本应该能够在Internet应用程序之间轻松传递。这就是国际化的挑战。
This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.
本文档提供了IETF讨论国际化时使用的术语表。目的是帮助构建IETF各领域国际化讨论的框架，并帮助向IETF参与者介绍主要概念。
Internationalization is discussed in many working groups of the IETF. However, few working groups have internationalization experts. When designing or updating protocols, the question often comes up "Should we internationalize this?" (or, more likely, "Do we have to internationalize this?").
IETF的许多工作组都讨论了国际化问题。然而，很少有工作组有国际化专家。在设计或更新协议时，经常会出现这样的问题：“我们应该将其国际化吗？”（或者，更可能的是，“我们必须将其国际化吗？”）。
This document gives an overview of internationalization terminology as it applies to IETF standards work by lightly covering the many aspects of internationalization and the vocabulary associated with those topics. Some of the overview is somewhat tutorial in nature. It is not meant to be a complete description of internationalization. The definitions here SHOULD be used by IETF standards. IETF standards that explicitly want to create different definitions for the terms defined here can do so, but unless an alternate definition is provided the definitions of the terms in this document apply. IETF standards that have a requirement for different definitions are encouraged, for clarity's sake, to find terms different than the ones defined here. Some of the definitions in this document come from earlier IETF documents and books.
本文档概述了国际化术语，因为它适用于IETF标准工作，简单介绍了国际化的许多方面以及与这些主题相关的词汇。有些概述在本质上有点像教程。这并不是对国际化的完整描述。此处的定义应由IETF标准使用。明确希望为此处定义的术语创建不同定义的IETF标准可以这样做，但除非提供替代定义，否则本文件中的术语定义适用。为清晰起见，鼓励对不同定义有要求的IETF标准查找与此处定义不同的术语。本文件中的一些定义来自早期的IETF文件和书籍。
As in many fields, there is disagreement in the internationalization community on definitions for many words. The topic of language brings up particularly passionate opinions for experts and non-experts alike. This document attempts to define terms in a way that will be most useful to the IETF audience.
与许多领域一样，国际化界对许多词的定义存在分歧。语言这个话题给专家和非专家带来了特别热烈的意见。本文件试图以对IETF受众最有用的方式定义术语。
This document uses definitions from many documents that have been developed inside and outside the IETF. The primary documents used are:
本文件使用了IETF内外开发的许多文件中的定义。使用的主要文件有：
o ISO/IEC 10646 [ISOIEC10646]
o ISO/IEC10646[ISO10646]
o The Unicode Standard [UNICODE]
o Unicode标准[Unicode]
o W3C Character Model [CHARMOD]
o W3C字符模型[CHARMOD]
o IETF RFCs, including the Character Set Policy specification [RFC2277] and the domain name internationalization standard [RFC5890]
o IETF RFCs，包括字符集策略规范[RFC2277]和域名国际化标准[RFC5890]
In the body of this document, the source for the definition is shown in angle brackets, such as "<ISOIEC10646>". Many definitions are shown as "<RFC6365>", which means that the definitions were crafted originally for this document. The angle bracket notation for the source of definitions is different than the square bracket notation used for references to documents, such as in the paragraph above; these references are given in the reference sections of this document.
在本文件正文中，定义的来源用尖括号表示，如“<ISOIEC10646>”。许多定义显示为“<RFC6365>”，这意味着这些定义最初是为本文档编制的。定义来源的角括号符号不同于上文段落中引用文件时使用的方括号符号；这些参考资料在本文件的参考章节中给出。
For some terms, there are commentary and examples after the definitions. In those cases, the part before the angle brackets is the definition that comes from the original source, and the part after the angle brackets is commentary that is not a definition (such as an example or further exposition).
对于某些术语，在定义之后有注释和示例。在这些情况下，尖括号前的部分是来自原始来源的定义，尖括号后的部分是不是定义的评注（例如示例或进一步的阐述）。
Examples in this document use the notation for code points and names from the Unicode Standard [UNICODE] and ISO/IEC 10646 [ISOIEC10646]. For example, the letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER A". See RFC 5137 [RFC5137] for a description of this notation.
本文档中的示例使用Unicode标准[Unicode]和ISO/IEC 10646[ISOIEC10646]中的代码点和名称表示法。例如，字母“a”可以表示为“U+0061”或“拉丁小写字母a”。有关此符号的说明，请参见RFC 5137[RFC5137]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section covers basic topics that are needed for almost anyone who is involved with making IETF protocols more friendly to non-ASCII text (see Section 4.2) and with other aspects of internationalization.
本节涵盖了使IETF协议对非ASCII文本更友好（见第4.2节）以及国际化其他方面的几乎所有人都需要的基本主题。
language
语言
A language is a way that humans communicate. The use of language occurs in many forms, the most common of which are speech, writing, and signing. <RFC6365>
语言是人类交流的一种方式。语言的使用有多种形式，其中最常见的是演讲、写作和签名<RFC6365>
Some languages have a close relationship between the written and spoken forms, while others have a looser relationship. The so-called LTRU (Language Tag Registry Update) standards [RFC5646] [RFC4647] discuss languages in more detail and provide identifiers for languages for use in Internet protocols. Note that computer languages are explicitly excluded from this definition.
一些语言的书面形式和口头形式之间有着密切的关系，而另一些语言则有着松散的关系。所谓的LTRU（语言标记注册表更新）标准[RFC5646][RFC4647]更详细地讨论了语言，并为互联网协议中使用的语言提供了标识符。请注意，此定义中明确排除了计算机语言。
script
剧本
A set of graphic characters used for the written form of one or more languages. <ISOIEC10646>
一组图形字符，用于一种或多种语言的书面形式<ISO10646>
Examples of scripts are Latin, Cyrillic, Greek, Arabic, and Han (the characters, often called ideographs after a subset of them, used in writing Chinese, Japanese, and Korean). RFC 2277 discusses scripts in detail.
脚本的例子有拉丁语、西里尔语、希腊语、阿拉伯语和汉（这些字符通常以其子集命名为表意文字，用于书写汉语、日语和韩语）。RFC2277详细讨论了脚本。
It is common for internationalization novices to mix up the terms "language" and "script". This can be a problem in protocols that differentiate the two. Almost all protocols that are designed (or were re-designed) to handle non-ASCII text deal with scripts (the written systems) or characters, while fewer actually deal with languages.
国际化新手经常混淆“语言”和“脚本”这两个术语。这可能是区分两者的协议中的一个问题。几乎所有设计（或重新设计）用于处理非ASCII文本的协议都处理脚本（书面系统）或字符，而实际处理语言的协议则更少。
A single name can mean either a language or a script; for example, "Arabic" is both the name of a language and the name of a script. In fact, many scripts borrow their names from the names of languages. Further, many scripts are used to write more than one language; for example, the Russian and Bulgarian languages are written in the Cyrillic script. Some languages can be expressed using different scripts or were used with different scripts at different times; the Mongolian language can be written in either the Mongolian or Cyrillic scripts; Malay is primarily written in Latin script today, but the earlier, Arabic-script-based, Jawa form is still in use; and a number of languages were converted
一个名字可以指一种语言或一个脚本；例如，“阿拉伯语”既是一种语言的名称，也是一种脚本的名称。事实上，许多脚本借用了语言的名称。此外，许多脚本用于编写多种语言；例如，俄语和保加利亚语是用西里尔文字书写的。有些语言可以使用不同的脚本来表达，或者在不同的时间与不同的脚本一起使用；蒙古语可以用蒙古语或西里尔语书写；马来语今天主要用拉丁语书写，但早期的以阿拉伯语为基础的爪哇语仍在使用；许多语言被转换了
from other scripts to Cyrillic in the first half of the last century, some of which have switched again more recently. Further, some languages are normally expressed with more than one script at the same time; for example, the Japanese language is normally expressed in the Kanji (Han), Katakana, and Hiragana scripts in a single string of text.
在上个世纪上半叶，从其他文字到西里尔文，其中一些最近又发生了变化。此外，一些语言通常同时用多个脚本表示；例如，日语通常用汉字、片假名和平假名在一个文本字符串中表达。
writing system
书写系统
A set of rules for using one or more scripts to write a particular language. Examples include the American English writing system, the British English writing system, the French writing system, and the Japanese writing system. <UNICODE>
使用一个或多个脚本编写特定语言的一组规则。例如美国英语写作体系、英国英语写作体系、法国写作体系和日本写作体系<UNICODE>
character
性格
A member of a set of elements used for the organization, control, or representation of data. <ISOIEC10646>
用于组织、控制或表示数据的一组元素的成员<ISO10646>
There are at least three common definitions of the word "character":
“字符”一词至少有三种常见定义：
* a general description of a text entity
* 文本实体的一般描述
* a unit of a writing system, often synonymous with "letter" or similar terms, but generalized to include digits and symbols of various sorts
* 书写系统的一种单位，通常与“字母”或类似术语同义，但一般包括各种数字和符号
* the encoded entity itself
* 编码实体本身
When people talk about characters, they usually intend one of the first two definitions. The term "character" is often abbreviated as "char".
当人们谈论角色时，他们通常使用前两种定义中的一种。术语“字符”通常缩写为“字符”。
A particular character is identified by its name, not by its shape. A name may suggest a meaning, but the character may be used for representing other meanings as well. A name may suggest a shape, but that does not imply that only that shape is commonly used in print, nor that the particular shape is associated only with that name.
一个特定的字符是通过它的名字而不是形状来识别的。一个名字可能暗示一种含义，但这个字符也可能被用来表示其他含义。一个名称可能暗示一个形状，但这并不意味着只有该形状通常用于印刷，也不意味着特定形状仅与该名称关联。
coded character
编码字符
A character together with its coded representation. <ISOIEC10646>
一种字符及其编码表示<ISO10646>
coded character set
编码字符集
A coded character set (CCS) is a set of unambiguous rules that establishes a character set and the relationship between the characters of the set and their coded representation. <ISOIEC10646>
编码字符集（CCS）是一组明确的规则，用于建立字符集及其字符与其编码表示之间的关系<ISO10646>
character encoding form
字符编码形式
A character encoding form is a mapping from a coded character set (CCS) to the actual code units used to represent the data. <UNICODE>
字符编码形式是从编码字符集（CCS）到用于表示数据的实际代码单位的映射<UNICODE>
repertoire
可表演项目
The collection of characters included in a character set. Also called a character repertoire. <UNICODE>
字符集中包含的字符集合。也称为角色剧目<UNICODE>
glyph
字形
A glyph is an image of a character that can be displayed after being imaged onto a display surface. <RFC6365>
字形是一种字符图像，可以在成像到显示表面后显示<RFC6365>
The Unicode Standard has a different definition that refers to an abstract form that may represent different images when the same character is rendered under different circumstances.
Unicode标准有一个不同的定义，它指的是一种抽象形式，当在不同的环境下呈现相同的字符时，它可能表示不同的图像。
glyph code
glyph代码
A glyph code is a numeric code that refers to a glyph. Usually, the glyphs contained in a font are referenced by their glyph code. Glyph codes are local to a particular font; that is, a different font containing the same glyphs may use different codes. <UNICODE>
字形代码是指字形的数字代码。通常，字体中包含的字形由字形代码引用。字形代码是特定字体的本地代码；也就是说，包含相同字形的不同字体可能使用不同的代码<UNICODE>
transcoding
转码
Transcoding is the process of converting text data from one character encoding form to another. Transcoders work only at the level of character encoding and do not parse the text. Note: Transcoding may involve one-to-one, many-to-one, one-to-many, or many-to-many mappings. Because some legacy mappings are glyphic, they may not only be many-to-many, but also unordered: thus XYZ may map to yxz. <CHARMOD>
转码是将文本数据从一种字符编码形式转换为另一种字符编码形式的过程。转码器仅在字符编码级别工作，不解析文本。注意：转码可能涉及一对一、多对一、一对多或多对多映射。因为一些遗留映射是字形的，它们可能不仅是多对多的，而且是无序的：因此XYZ可能映射到yxz<CHARMOD>
In this definition, "many-to-one" means a sequence of characters mapped to a single character. The "many" does not mean alternative characters that map to the single character.
在此定义中，“多对一”指映射到单个字符的字符序列。“多”并不意味着映射到单个字符的替代字符。
character encoding scheme
字符编码方案
A character encoding scheme (CES) is a character encoding form plus byte serialization. There are many character encoding schemes in Unicode, such as UTF-8 and UTF-16BE. <UNICODE>
字符编码方案（CES）是字符编码形式加字节序列化。Unicode中有许多字符编码方案，如UTF-8和UTF-16BE<UNICODE>
Some CESs are associated with a single CCS; for example, UTF-8 [RFC3629] applies only to the identical CCSs of ISO/IEC 10646 and Unicode. Other CESs, such as ISO 2022, are associated with many CCSs.
一些CES与单个CCS相关；例如，UTF-8[RFC3629]仅适用于ISO/IEC 10646和Unicode的相同CCS。其他CES，如ISO 2022，与许多CCS相关。
charset
字符集
A charset is a method of mapping a sequence of octets to a sequence of abstract characters. A charset is, in effect, a combination of one or more CCSs with a CES. Charset names are registered by the IANA according to procedures documented in [RFC2978]. <RFC6365>
字符集是一种将八位字节序列映射到抽象字符序列的方法。字符集实际上是一个或多个CCS与CES的组合。IANA根据[RFC2978]中记录的程序注册字符集名称<RFC6365>
Many protocol definitions use the term "character set" in their descriptions. The terms "charset", or "character encoding scheme" and "coded character set", are strongly preferred over the term "character set" because "character set" has other definitions in other contexts, particularly outside the IETF. When reading IETF standards that use "character set" without defining the term, they usually mean "a specific combination of one CCS with a CES", particularly when they are talking about the "US-ASCII character set".
许多协议定义在其描述中使用术语“字符集”。术语“字符集”或“字符编码方案”和“编码字符集”强烈优于术语“字符集”，因为“字符集”在其他上下文中有其他定义，特别是在IETF之外。当阅读使用“字符集”但未定义术语的IETF标准时，它们通常表示“一个CCS与一个CES的特定组合”，特别是当它们谈论“US-ASCII字符集”时。
internationalization
国际化
In the IETF, "internationalization" means to add or improve the handling of non-ASCII text in a protocol. <RFC6365> A different perspective, more appropriate to protocols that are designed for global use from the beginning, is the definition used by W3C:
在IETF中，“国际化”是指在协议中添加或改进非ASCII文本的处理<RFC6365>W3C使用的定义是一个不同的视角，更适合于从一开始就为全局使用而设计的协议：
"Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language." [W3C-i18n-Def]
“国际化是指产品、应用程序或文档内容的设计和开发，使不同文化、地区或语言的目标受众能够轻松本地化。”[W3C-i18n-Def]
Many protocols that handle text only handle one charset (US-ASCII), or leave the question of what CCS and encoding are used up to local guesswork (which leads, of course, to interoperability problems). If multiple charsets are permitted, they must be explicitly identified [RFC2277]. Adding non-ASCII text to a protocol allows the protocol to handle more scripts, hopefully all of the ones useful in the world. In today's world,
许多处理文本的协议只处理一个字符集（US-ASCII），或者将使用何种CCS和编码的问题留给本地猜测（这当然会导致互操作性问题）。如果允许多个字符集，则必须明确标识它们[RFC2277]。将非ASCII文本添加到协议中可以让协议处理更多脚本，希望能够处理世界上所有有用的脚本。当今世界,，
that is normally best accomplished by allowing Unicode encoded in UTF-8 only, thereby shifting conversion issues away from individual choices.
通常，最好的方法是只允许使用UTF-8编码的Unicode，从而将转换问题从单个选择中转移出去。
localization
本地化
The process of adapting an internationalized application platform or application to a specific cultural environment. In localization, the same semantics are preserved while the syntax may be changed. [FRAMEWORK]
使国际化应用程序平台或应用程序适应特定文化环境的过程。在本地化中，相同的语义被保留，而语法可能被更改。[框架]
Localization is the act of tailoring an application for a different language or script or culture. Some internationalized applications can handle a wide variety of languages. Typical users only understand a small number of languages, so the program must be tailored to interact with users in just the languages they know.
本地化是为不同的语言、脚本或文化定制应用程序的行为。一些国际化应用程序可以处理多种语言。典型的用户只懂少量语言，因此必须对程序进行定制，以便仅使用他们所知道的语言与用户进行交互。
The major work of localization is translating the user interface and documentation. Localization involves not only changing the language interaction, but also other relevant changes such as display of numbers, dates, currency, and so on. The better internationalized an application is, the easier it is to localize it for a particular language and character encoding scheme.
本地化的主要工作是翻译用户界面和文档。本地化不仅涉及到语言交互的变化，还涉及到其他相关的变化，如数字、日期、货币等的显示。应用程序的国际化程度越高，就越容易针对特定语言和字符编码方案对其进行本地化。
Localization is rarely an IETF matter, and protocols that are merely localized, even if they are serially localized for several locations, are generally considered unsatisfactory for the global Internet.
本地化很少是IETF的问题，仅本地化的协议，即使它们在多个位置连续本地化，通常被认为不适合全球互联网。
Do not confuse "localization" with "locale", which is described in Section 8 of this document.
请勿将本文件第8节中描述的“本地化”与“语言环境”混淆。
i18n, l10n
i18n，l10n
These are abbreviations for "internationalization" and "localization". <RFC6365>
这些是“国际化”和“本地化”的缩写<RFC6365>
"18" is the number of characters between the "i" and the "n" in "internationalization", and "10" is the number of characters between the "l" and the "n" in "localization".
“18”是“国际化”中“i”和“n”之间的字符数，“10”是“本地化”中“l”和“n”之间的字符数。
multilingual
多语
The term "multilingual" has many widely varying definitions and thus is not recommended for use in standards. Some of the definitions relate to the ability to handle international characters; other definitions relate to the ability to handle multiple charsets; and still others relate to the ability to handle multiple languages. <RFC6365>
“多语言”一词有许多不同的定义，因此不建议在标准中使用。一些定义与处理国际字符的能力有关；其他定义涉及处理多个字符集的能力；还有一些涉及到处理多种语言的能力<RFC6365>
displaying and rendering text
显示和呈现文本
To display text, a system puts characters on a visual display device such as a screen or a printer. To render text, a system analyzes the character input to determine how to display the text. The terms "display" and "render" are sometimes used interchangeably. Note, however, that text might be rendered as audio and/or tactile output, such as in systems that have been designed for people with visual disabilities. <RFC6365>
为了显示文本，系统将字符放在可视显示设备（如屏幕或打印机）上。要呈现文本，系统将分析字符输入以确定如何显示文本。术语“显示”和“渲染”有时可以互换使用。但是，请注意，文本可能会呈现为音频和/或触觉输出，例如在为视觉残疾人士设计的系统中<RFC6365>
Combining characters modify the display of the character (or, in some cases, characters) that precede them. When rendering such text, the display engine must either find the glyph in the font that represents the base character and all of the combining characters, or it must render the combination itself. Such rendering can be straightforward, but it is sometimes complicated when the combining marks interact with each other, such as when there are two combining marks that would appear above the same character. Formatting characters can also change the way that a renderer would display text. Rendering can also be difficult for some scripts that have complex display rules for base characters, such as Arabic and Indic scripts.
组合字符会修改前面字符（或在某些情况下，字符）的显示。呈现此类文本时，显示引擎必须在表示基本字符和所有组合字符的字体中找到字形，或者必须呈现组合本身。这样的渲染可以很简单，但当组合标记相互交互时，有时会很复杂，例如当有两个组合标记出现在同一个角色的上方时。格式化字符还可以更改渲染器显示文本的方式。对于一些基本字符具有复杂显示规则的脚本（如阿拉伯语和印度语脚本），渲染也可能很困难。
This section describes some of the standards bodies and standards that appear in discussions of internationalization in the IETF. This is an incomplete and possibly over-full list; listing too few bodies or standards can be just as politically dangerous as listing too many. Note that there are many other bodies that deal with internationalization; however, few if any of them appear commonly in IETF standards work.
本节描述了IETF国际化讨论中出现的一些标准机构和标准。这是一份不完整且可能过满的清单；列出太少的机构或标准可能与列出太多机构或标准一样具有政治危险性。注意，还有许多其他机构处理国际化问题；然而，在IETF标准工作中，它们很少出现。
ISO and ISO/IEC JTC 1
ISO和ISO/IEC JTC 1
The International Organization for Standardization has been involved with standards for characters since before the IETF was started. ISO is a non-governmental group made up of national bodies. Most of ISO's work in information technology is performed jointly with a similar body, the International Electrotechnical Commission (IEC) through a joint committee known as "JTC 1". ISO and ISO/IEC JTC 1 have many diverse standards in the international characters area; the one that is most used in the IETF is commonly referred to as "ISO/IEC 10646", sometimes with a specific date. ISO/IEC 10646 describes a CCS that covers almost all known written characters in use today.
在IETF启动之前，国际标准化组织就参与了字符标准的制定。ISO是由国家机构组成的非政府组织。国际标准化组织在信息技术方面的大部分工作是通过一个名为“JTC 1”的联合委员会与一个类似机构国际电工委员会（IEC）联合开展的。ISO和ISO/IEC JTC 1在国际字符领域有许多不同的标准；IETF中使用最多的一个通常被称为“ISO/IEC 10646”，有时带有特定日期。ISO/IEC 10646描述了一种CCS，它涵盖了目前使用的几乎所有已知的书写字符。
ISO/IEC 10646 is controlled by the group known as "ISO/IEC JTC 1/
SC 2 WG2", often called "SC2/WG2" or "WG2" for short. ISO
standards go through many steps before being finished, and years
often go by between changes to the base ISO/IEC 10646 standard
although amendments are now issued to track Unicode changes.
Information on WG2, and its work products, can be found at
<http://www.dkuug.dk/JTC1/SC2/WG2/>. Information on SC2, and its
work products, can be found at <http://www.iso.org/iso/
standards_development/technical_committees/
list_of_iso_technical_committees/
iso_technical_committee.htm?commid=45050>
ISO/IEC 10646 is controlled by the group known as "ISO/IEC JTC 1/
SC 2 WG2", often called "SC2/WG2" or "WG2" for short. ISO
standards go through many steps before being finished, and years
often go by between changes to the base ISO/IEC 10646 standard
although amendments are now issued to track Unicode changes.
Information on WG2, and its work products, can be found at
<http://www.dkuug.dk/JTC1/SC2/WG2/>. Information on SC2, and its
work products, can be found at <http://www.iso.org/iso/
standards_development/technical_committees/
list_of_iso_technical_committees/
iso_technical_committee.htm?commid=45050>
The standard comes as a base part and a series of attachments or amendments. It is available in PDF form for downloading or in a CD-ROM version. One example of how to cite the standard is given in [RFC3629]. Any standard that cites ISO/IEC 10646 needs to evaluate how to handle the versioning problem that is relevant to the protocol's needs.
本标准作为基础部分和一系列附件或修改件发布。该文件以PDF格式提供，可供下载或以CD-ROM格式提供。[RFC3629]中给出了如何引用该标准的一个示例。任何引用ISO/IEC 10646的标准都需要评估如何处理与协议需求相关的版本控制问题。
ISO is responsible for other standards that might be of interest to protocol developers concerned about internationalization. ISO 639 [ISO639] specifies the names of languages and forms part of the basis for the IETF's Language Tag work [RFC5646]. ISO 3166 [ISO3166] specifies the names and code abbreviations for countries and territories and is used in several protocols and databases including names for country-code top level domain names. The responsibilities of ISO TC 46 on Information and Documentation <http://www.iso.org/iso/standards_development/ technical_committees/list_of_iso_technical_committees/ iso_technical_committee.htm?commid=48750> include a series of standards for transliteration of various languages into Latin characters.
ISO负责关注国际化的协议开发人员可能感兴趣的其他标准。ISO 639[ISO639]规定了语言名称，并构成IETF语言标记工作[RFC5646]基础的一部分。ISO 3166[ISO3166]规定了国家和地区的名称和代码缩写，并用于多个协议和数据库，包括国家代码顶级域名的名称。ISO TC 46在信息和文件方面的责任<http://www.iso.org/iso/standards_development/ 技术委员会/iso技术委员会列表/iso技术委员会.htm？commid=48750>包括一系列将各种语言音译为拉丁字符的标准。
Another relevant ISO group was JTC 1/SC22/WG20, which was responsible for internationalization in JTC 1, such as for international string ordering. Information on WG20, and its work products, can be found at <http://www.dkuug.dk/jtc1/sc22/wg20/>. The specific tasks of SC22/WG20 were moved from SC22 into SC2, and there has been little significant activity since that occurred.
另一个相关的ISO小组是JTC 1/SC22/WG20，负责JTC 1的国际化，例如国际字符串排序。有关WG20及其工作产品的信息，请访问<http://www.dkuug.dk/jtc1/sc22/wg20/>. SC22/WG20的具体任务从SC22转移到了SC2，此后几乎没有什么重大活动。
Unicode Consortium
统一码协会
The second important group for international character standards is the Unicode Consortium. The Unicode Consortium is a trade association of companies, governments, and other groups interested in promoting the Unicode Standard [UNICODE]. The Unicode Standard is a CCS whose repertoire and code points are identical to ISO/IEC 10646. The Unicode Consortium has added features to the base CCS that make it more useful in protocols, such as defining attributes for each character. Examples of these attributes include case conversion and numeric properties.
国际字符标准的第二个重要团体是Unicode联盟。Unicode联盟是一个由公司、政府和其他对推广Unicode标准[Unicode]感兴趣的团体组成的行业协会。Unicode标准是一种CCS，其指令集和代码点与ISO/IEC 10646相同。Unicode联盟为基础CCS添加了一些功能，使其在协议中更加有用，例如为每个字符定义属性。这些属性的示例包括大小写转换和数字属性。
The actual technical and definitional work of the Unicode Consortium is done in the Unicode Technical Committee (UTC). The terms "UTC" and "Unicode Consortium" are often treated, imprecisely, as synonymous in the IETF.
Unicode联盟的实际技术和定义工作由Unicode技术委员会（UTC）完成。在IETF中，术语“UTC”和“Unicode联合体”通常被不精确地视为同义词。
The Unicode Consortium publishes addenda to the Unicode Standard as Unicode Technical Reports. There are many types of technical reports at various stages of maturity. The Unicode Standard and affiliated technical reports can be found at <http://www.unicode.org/>.
Unicode联盟以Unicode技术报告的形式发布Unicode标准的附录。在不同的成熟阶段，有许多类型的技术报告。Unicode标准和相关技术报告可在<http://www.unicode.org/>.
A reciprocal agreement between the Unicode Consortium and ISO/IEC JTC 1/SC 2 provides for ISO/IEC 10646 and The Unicode Standard to track each other for definitions of characters and assignments of code points. Updates, often in the form of amendments, to the former sometimes lag updates to the latter for a short period, but the gap has rarely been significant in recent years.
Unicode联盟和ISO/IEC JTC 1/SC 2之间的互惠协议规定ISO/IEC 10646和Unicode标准可相互跟踪字符定义和代码点分配。对前者的更新（通常以修正的形式）有时会在短时间内滞后于对后者的更新，但近年来差距很少显著。
At the time that the IETF character set policy [RFC2277] was established and the first version of this terminology specification was published, there was a strong preference in the IETF community for references to ISO/IEC 10646 (rather than Unicode) when possible. That preference largely reflected a more general IETF preference for referencing established open international standards over specifications from consortia. However, the Unicode definitions of character properties and classes are not part of ISO/IEC 10646. Because IETF specifications are increasingly dependent on those definitions
在制定IETF字符集策略[RFC2277]并发布本术语规范的第一个版本时，IETF社区强烈倾向于在可能的情况下参考ISO/IEC 10646（而非Unicode）。这种偏好在很大程度上反映了IETF更倾向于引用已建立的开放式国际标准，而不是来自联合体的规范。但是，字符属性和类的Unicode定义不是ISO/IEC 10646的一部分。因为IETF规范越来越依赖于这些定义
(for example, see the explanation in Section 4.2) and the Unicode specifications are freely available online in convenient machine-readable form, the IETF's preference has shifted to referencing the Unicode Standard. The latter is especially important when version consistency between code points (either standard) and Unicode properties (Unicode only) is required.
（例如，参见第4.2节中的解释）并且Unicode规范以方便的机器可读形式在网上免费提供，IETF的首选已转向引用Unicode标准。当需要代码点（标准）和Unicode属性（仅限Unicode）之间的版本一致性时，后者尤其重要。
World Wide Web Consortium (W3C)
万维网联盟（W3C）
This group created and maintains the standard for XML, the markup language for text that has become very popular. XML has always been fully internationalized so that there is no need for a new version to handle international text. However, in some circumstances, XML files may be sensitive to differences among Unicode versions.
这个小组创建并维护XML标准，XML是一种非常流行的文本标记语言。XML一直都是完全国际化的，因此不需要新版本来处理国际文本。但是，在某些情况下，XML文件可能对Unicode版本之间的差异很敏感。
local and regional standards organizations
地方和区域标准组织
Just as there are many native CCSs and charsets, there are many local and regional standards organizations to create and support them. Common examples of these are ANSI (United States), CEN/ISSS (Europe), JIS (Japan), and SAC (China).
正如有许多本地CCS和字符集一样，也有许多本地和区域标准组织来创建和支持它们。常见的例子有ANSI（美国）、CEN/ISSS（欧洲）、JIS（日本）和SAC（中国）。
Characters in the ISO/IEC 10646 CCS can be expressed in many ways. Historically, "encoding forms" are both direct addressing methods, while "transformation formats" are methods for expressing encoding forms as bits on the wire. That distinction has mostly disappeared in recent years.
ISO/IEC 10646 CCS中的字符可以用多种方式表示。历史上，“编码形式”都是直接寻址方法，而“转换格式”是将编码形式表示为线路上的位的方法。近年来，这种区别基本上消失了。
Documents that discuss characters in the ISO/IEC 10646 CCS often need to list specific characters. RFC 5137 describes the common methods for doing so in IETF documents, and these practices have been adopted by many other communities as well.
讨论ISO/IEC 10646 CCS中字符的文档通常需要列出特定字符。RFC 5137在IETF文件中描述了这样做的常用方法，这些实践也被许多其他社区采用。
Basic Multilingual Plane (BMP)
基本多语言平面（BMP）
The BMP is composed of the first 2^16 code points in ISO/IEC 10646 and contains almost all characters in contemporary use. The BMP is also called "Plane 0".
BMP由ISO/IEC 10646中的前2^16个代码点组成，包含几乎所有当代使用的字符。BMP也称为“平面0”。
UCS-2 and UCS-4
UCS-2和UCS-4
UCS-2 and UCS-4 are the two encoding forms historically defined for ISO/IEC 10646. UCS-2 addresses only the BMP. Because many useful characters (such as many Han characters) have been defined outside of the BMP, many people consider UCS-2 to be obsolete.
UCS-2和UCS-4是历史上为ISO/IEC 10646定义的两种编码形式。UCS-2仅处理BMP。由于许多有用的字符（如许多汉字）已经定义在BMP之外，很多人认为UCS-2是过时的。
UCS-4 addresses the entire range of code points from ISO/IEC 10646 (by agreement between ISO/IEC JTC 1 SC2 and the Unicode Consortium, a range from 0..0x10FFFF) as 32-bit values with zero padding to the left. UCS-4 is identical to UTF-32BE (without use of a BOM (see below)); UTF-32BE is now the preferred term.
UCS-4将ISO/IEC 10646（根据ISO/IEC JTC 1 SC2和Unicode联盟之间的协议，范围为0..0x10FFFF）中的整个代码点范围作为32位值进行寻址，左侧为零填充。UCS-4与UTF-32BE相同（不使用BOM（见下文））；UTF-32BE现在是首选术语。
UTF-8
UTF-8
UTF-8 [RFC3629] is the preferred encoding for IETF protocols. Characters in the BMP are encoded as one, two, or three octets. Characters outside the BMP are encoded as four octets. Characters from the US-ASCII repertoire have the same on-the-wire representation in UTF-8 as they do in US-ASCII. The IETF-specific definition of UTF-8 in RFC 3629 is identical to that in recent versions of the Unicode Standard (e.g., in Section 3.9 of Version 6.0 [UNICODE]).
UTF-8[RFC3629]是IETF协议的首选编码。BMP中的字符编码为一个、两个或三个八位字节。BMP之外的字符编码为四个八位字节。US-ASCII指令表中的字符在UTF-8中具有与在US-ASCII中相同的在线表示形式。RFC 3629中UTF-8的IETF特定定义与最新版本的Unicode标准（例如，版本6.0[Unicode]第3.9节）中的定义相同。
UTF-16, UTF-16BE, and UTF-16LE
UTF-16、UTF-16BE和UTF-16LE
UTF-16, UTF-16BE, and UTF-16LE, three transformation formats described in [RFC2781] and defined in The Unicode Standard (Sections 3.9 and 16.8 of Version 6.0), are not required by any IETF standards, and are thus used much less often in protocols than UTF-8. Characters in the BMP are always encoded as two octets, and characters outside the BMP are encoded as four octets using a "surrogate pair" arrangement. The latter is not part of UCS-2, marking the difference between UTF-16 and UCS-2. The three UTF-16 formats differ based on the order of the octets and the presence or absence of a special lead-in ordering identifier called the "byte order mark" or "BOM".
UTF-16、UTF-16BE和UTF-16LE是[RFC2781]中描述并在Unicode标准（版本6.0的第3.9节和第16.8节）中定义的三种转换格式，任何IETF标准都不需要，因此在协议中使用的频率远低于UTF-8。BMP中的字符始终编码为两个八位字节，BMP之外的字符使用“代理项对”排列编码为四个八位字节。后者不是UCS-2的一部分，标志着UTF-16和UCS-2之间的区别。三种UTF-16格式根据八位字节的顺序以及是否存在称为“字节顺序标记”或“BOM”的特殊引入顺序标识符而有所不同。
UTF-32
UTF-32
The Unicode Consortium and ISO/IEC JTC 1 have defined UTF-32 as a transformation format that incorporates the integer code point value right-justified in a 32-bit field. As with UTF-16, the byte order mark (BOM) can be used and UTF-32BE and UTF-32LE are defined. UTF-32 and UCS-4 are essentially equivalent and the terms are often used interchangeably.
Unicode联盟和ISO/IEC JTC 1已将UTF-32定义为一种转换格式，该格式将整数码点值在32位字段中右对齐。与UTF-16一样，可以使用字节顺序标记（BOM），并定义UTF-32BE和UTF-32LE。UTF-32和UCS-4在本质上是等效的，两个术语经常互换使用。
SCSU and BOCU-1
SCSU和BOCU-1
The Unicode Consortium has defined an encoding, SCSU [UTR6], which is designed to offer good compression for typical text. A different encoding that is meant to be MIME-friendly, BOCU-1, is described in [UTN6]. Although compression is attractive, as opposed to UTF-8, neither of these (at the time of this writing) has attracted much interest.
Unicode联盟定义了一种编码，SCSU[UTR6]，其设计目的是为典型文本提供良好的压缩。[UTN6]中描述了一种不同的MIME友好编码BOCU-1。尽管与UTF-8相比，压缩很有吸引力，但这两种（在撰写本文时）都没有引起太多兴趣。
The compression provided as a side effect of the Punycode algorithm [RFC3492] is heavily used in some contexts, especially IDNA [RFC5890], but imposes some restrictions. (See also Section 7.)
作为Punycode算法[RFC3492]的副作用提供的压缩在某些上下文中大量使用，尤其是IDNA[RFC5890]，但存在一些限制。（另见第7节。）
Before ISO/IEC 10646 was developed, many countries developed their own CCSs and charsets. Some of these were adopted into international standards for the relevant scripts or writing systems. Many dozen of these are in common use on the Internet today. Examples include ISO 8859-5 for Cyrillic and Shift-JIS for Japanese scripts.
在ISO/IEC 10646开发之前，许多国家都开发了自己的CCS和字符集。其中一些已被纳入相关脚本或书写系统的国际标准。其中有几十种在今天的互联网上被广泛使用。例如，西里尔文的ISO 8859-5和日文的Shift JIS。
The official list of the registered charset names for use with IETF protocols is maintained by IANA and can be found at <http://www.iana.org/assignments/character-sets>. The list contains preferred names and aliases. Note that this list has historically contained many errors, such as names that are in fact not charsets or references that do not give enough detail to reliably map names to charsets.
IETF协议使用的注册字符集名称的官方列表由IANA维护，可在<http://www.iana.org/assignments/character-sets>. 该列表包含首选名称和别名。请注意，此列表历史上曾包含许多错误，例如实际上不是字符集的名称，或者没有提供足够详细信息以可靠地将名称映射到字符集的引用。
Probably the most well-known native CCS is ASCII [US-ASCII]. This CCS is used as the basis for keywords and parameter names in many IETF protocols, and as the sole CCS in numerous IETF protocols that have not yet been internationalized. ASCII became the basis for ISO/IEC 646 which, in turn, formed the basis for many national and international standards, such as the ISO 8859 series, that mix Basic Latin characters with characters from another script.
最著名的本地CCS可能是ASCII[US-ASCII]。该CCS在许多IETF协议中用作关键字和参数名称的基础，并在许多尚未国际化的IETF协议中用作唯一的CCS。ASCII成为ISO/IEC 646的基础，而ISO/IEC 646又形成了许多国家和国际标准的基础，如ISO 8859系列，这些标准将基本拉丁字符与另一个脚本中的字符混合在一起。
It is important to note that, strictly speaking, "ASCII" is a CCS and repertoire, not an encoding. The encoding used for ASCII in IETF protocols involves the 7-bit integer ASCII code point right-justified in an 8-bit field and is sometimes described as the "Network Virtual Terminal" or "NVT" encoding [RFC5198]. Less formally, "ASCII" and "NVT" are often used interchangeably. However, "non-ASCII" refers only to characters outside the ASCII repertoire and is not linked to a specific encoding. See Section 4.2.
重要的是要注意，严格来说，“ASCII”是CCS和指令集，而不是编码。IETF协议中用于ASCII的编码涉及在8位字段中右对齐的7位整数ASCII码点，有时被描述为“网络虚拟终端”或“NVT”编码[RFC5198]。不太正式的是，“ASCII”和“NVT”经常互换使用。但是，“非ASCII”仅指ASCII指令表之外的字符，不与特定编码相关联。见第4.2节。
A Unicode publication describes issues involved in mapping character data between charsets, and an XML format for mapping table data [UTR22].
Unicode出版物描述了字符集之间映射字符数据所涉及的问题，以及映射表数据的XML格式[UTR22]。
This section contains terms and topics that are commonly used in character handling and therefore are of concern to people adding non-ASCII text handling to protocols. These topics are standardized outside the IETF.
本节包含字符处理中常用的术语和主题，因此，将非ASCII文本处理添加到协议中的人员非常关注这些术语和主题。这些主题在IETF之外标准化。
code point
代码点
A value in the codespace of a repertoire. For all common repertoires developed in recent years, code point values are integers (code points for ASCII and its immediate descendants were defined in terms of column and row positions of a table).
曲目的代码空间中的值。对于近年来开发的所有通用指令集，代码点值都是整数（ASCII及其直接后代的代码点是根据表的列和行位置定义的）。
combining character
组合字符
A member of an identified subset of the coded character set of ISO/IEC 10646 intended for combination with the preceding non-combining graphic character, or with a sequence of combining characters preceded by a non-combining character. Combining characters are inherently non-spacing. <ISOIEC10646>
ISO/IEC 10646编码字符集的识别子集的一个成员，用于与前面的非组合图形字符组合，或与前面有非组合字符的组合字符序列组合。组合字符本质上是无间距的<ISO10646>
composite sequence or combining character sequence
复合序列还是组合字符序列
A sequence of graphic characters consisting of a non-combining character followed by one or more combining characters. A graphic symbol for a composite sequence generally consists of the combination of the graphic symbols of each character in the sequence. The Unicode Standard often uses the term "combining character sequence" to refer to composite sequences. A composite sequence is not a character and therefore is not a member of the repertoire of ISO/IEC 10646. <ISOIEC10646> However, Unicode now assigns names to some such sequences especially when the names are required to match terminology in other standards [UAX34].
一种图形字符序列，由一个非组合字符后跟一个或多个组合字符组成。复合序列的图形符号通常由序列中每个字符的图形符号组合而成。Unicode标准通常使用术语“组合字符序列”来表示复合序列。复合序列不是字符，因此不是ISO/IEC 10646指令集的成员<ISOIEC10646>然而，Unicode现在为一些这样的序列分配名称，特别是当名称需要与其他标准中的术语相匹配时[UAX34]。
In some CCSs, some characters consist of combinations of other characters. For example, the letter "a with acute" might be a combination of the two characters "a" and "combining acute", or it might be a combination of the three characters "a", a non-destructive backspace, and an acute. In the same or other CCSs, it might be available as a single code point. The rules for combining two or more characters are called "composition rules", and the rules for taking apart a character into other characters are called "decomposition rules". The result of decomposition is called a "decomposed character"; the result of composition is usually a "precomposed character".
在某些CCS中，某些字符由其他字符的组合组成。例如，字母“a with acute”可能是两个字符“a”和“combining acute”的组合，也可能是三个字符“a”、非破坏性退格和acute的组合。在相同或其他CCS中，它可能作为单个代码点可用。组合两个或多个字符的规则称为“组合规则”，将一个字符拆分为其他字符的规则称为“分解规则”。分解的结果称为“分解字符”；合成的结果通常是“预合成字符”。
normalization
规范化
Normalization is the transformation of data to a normal form, for example, to unify spelling. <UNICODE>
规范化是将数据转换为标准格式，例如，统一拼写<UNICODE>
Note that the phrase "unify spelling" in the definition above does not mean unifying different strings with the same meaning as words (such as "color" and "colour"). Instead, it means unifying different character sequences that are intended to form the same composite characters, such as "<n><combining tilde>" and "<n with tilde>" (where "<n>" is U+006E, "<combining tilde>" is U+0303, and "<n with tilde>" is U+00F1).
请注意，上述定义中的短语“统一拼写”并不意味着统一具有与单词相同含义的不同字符串（如“颜色”和“颜色”）。相反，它意味着统一旨在形成相同组合字符的不同字符序列，例如“<n><combing tilde>”和“<n with tilde>”（其中“<n>”是U+006E，<combing tilde>”是U+0303，“<n with tilde>”是U+00F1）。
The purpose of normalization is to allow two strings to be compared for equivalence. The strings "<a><n><combining tilde><o>" and "<a><n with tilde><o>" would be shown identically on a text display device. If a protocol designer wants those two strings to be considered equivalent during comparison, the protocol must define where normalization occurs.
规范化的目的是允许对两个字符串进行等效性比较。字符串“<a><n><combined tilde><o>”和“<a><n with tilde><o>”将在文本显示设备上以相同方式显示。如果协议设计者希望在比较期间将这两个字符串视为等效的，则协议必须定义规范化发生的位置。
The terms "normalization" and "canonicalization" are often used interchangeably. Generally, they both mean to convert a string of one or more characters into another string based on standardized rules. However, in Unicode, "canonicalization" or similar terms are used to refer to a particular type of normalization equivalence ("canonical equivalence" in contrast to "compatibility equivalence"), so the term should be used with some care. Some CCSs allow multiple equivalent representations for a written string; normalization selects one among multiple equivalent representations as a base for reference purposes in comparing strings. In strings of text, these rules are usually based on decomposing combined characters or composing characters with combining characters. Unicode Standard Annex #15 [UTR15] describes the process and many forms of normalization in detail. Normalization is important when comparing strings to see if they are the same.
术语“规范化”和“规范化”经常互换使用。通常，它们都表示根据标准化规则将一个或多个字符的字符串转换为另一个字符串。然而，在Unicode中，“规范化”或类似术语用于指代特定类型的规范化等价（“规范化等价”与“兼容性等价”形成对比），因此应谨慎使用该术语。一些CCS允许对一个写入字符串使用多个等效表示；规范化从多个等效表示中选择一个作为比较字符串时引用的基础。在文本字符串中，这些规则通常基于组合字符的分解或组合字符的组合。Unicode标准附录#15[UTR15]详细描述了规范化的过程和多种形式。在比较字符串以查看它们是否相同时，规范化非常重要。
The Unicode NFC and NFD normalizations support canonical equivalence; NFKC and NFKD support canonical and compatibility equivalence.
Unicode NFC和NFD规范化支持规范等价性；NFKC和NFKD支持规范和兼容性等价。
case
案例
Case is the feature of certain alphabets where the letters have two (or occasionally more) distinct forms. These forms, which may differ markedly in shape and size, are called the uppercase letter (also known as capital or majuscule) and the lowercase letter (also known as small or minuscule). Case mapping is the association of the uppercase and lowercase forms of a letter. <UNICODE>
大小写是某些字母表的特征，字母有两种（或偶尔更多）不同的形式。这些形式在形状和大小上可能明显不同，称为大写字母（也称为大写或小写字母）和小写字母（也称为小写或小写字母）。大小写映射是字母大小写形式的关联<UNICODE>
There is usually (but not always) a one-to-one mapping between the same letter in the two cases. However, there are many examples of characters that exist in one case but for which there is no corresponding character in the other case or for which there is a special mapping rule, such as the Turkish dotless "i", some Greek characters with modifiers, and characters like the German Sharp S (Eszett) and Greek Final Sigma that traditionally do not have uppercase forms. Case mapping can even be dependent on locale or language. Converting text to have only a single case, primarily for comparison purposes, is called "case folding". Because of the various unusual cases, case mapping can be quite controversial and some case folding algorithms even more so. For example, some programming languages such as Java have case-folding algorithms that are locale-sensitive; this makes those algorithms incredibly resource-intensive and makes them act differently depending on the location of the system at the time the algorithm is used.
在这两种情况下，同一个字母之间通常（但并非总是）存在一对一的映射。但是，有许多字符示例存在于一种情况下，但在另一种情况下没有对应的字符，或者存在特殊的映射规则，例如土耳其无圆点“i”、一些带修饰符的希腊字符以及类似德语夏普S（Eszett）的字符希腊语的最后一个Sigma，传统上没有大写形式。案例映射甚至可以依赖于区域设置或语言。将文本转换为只有一个大小写（主要用于比较目的）称为“大小写折叠”。由于各种不寻常的情况，案例映射可能是相当有争议的，一些案例折叠算法更是如此。例如，一些编程语言（如Java）具有区分区域设置的大小写折叠算法；这使得这些算法非常耗费资源，并且根据使用算法时系统的位置，它们的行为也会有所不同。
sorting and collation
整理
Collating is the process of ordering units of textual information. Collation is usually specific to a particular language or even to a particular application or locale. It is sometimes known as alphabetizing, although alphabetization is just a special case of sorting and collation. <UNICODE>
排序是对文本信息的单位进行排序的过程。排序规则通常特定于特定的语言，甚至特定的应用程序或区域设置。它有时被称为字母排序，尽管字母排序只是排序和排序的一种特殊情况<UNICODE>
Collation is concerned with the determination of the relative order of any particular pair of strings, and algorithms concerned with collation focus on the problem of providing appropriate weighted keys for string values, to enable binary comparison of the key values to determine the relative ordering of the strings.
排序与确定任何特定字符串对的相对顺序有关，与排序相关的算法侧重于为字符串值提供适当的加权键的问题，以使键值的二进制比较能够确定字符串的相对顺序。
The relative orders of letters in collation sequences can differ widely based on the needs of the system or protocol defining the collation order. For example, even within ASCII characters, there are two common and very different collation orders: "A, a, B, b,..." and "A, B, C, ..., Z, a, b,...", with additional variations for lowercase first and digits before and after letters.
根据定义排序顺序的系统或协议的需要，排序顺序中字母的相对顺序可能存在很大差异。例如，即使在ASCII字符中，也有两种常见且非常不同的排序顺序：“A，A，B，B，…”和“A，B，C，…，Z，A，B，…”，小写字母的首字母和字母前后的数字还有其他变化。
In practice, it is rarely necessary to define a collation sequence for characters drawn from different scripts, but arranging such sequences so as to not surprise users is usually particularly problematic.
在实践中，很少需要为从不同脚本中提取的字符定义排序顺序，但是为了不让用户感到惊讶而安排这样的顺序通常是特别有问题的。
Sorting is the process of actually putting data records into specified orders, according to criteria for comparison between the records. Sorting can apply to any kind of data (including textual data) for which an ordering criterion can be defined. Algorithms concerned with sorting focus on the problem of performance (in terms of time, memory, or other resources) in actually putting the data records into the desired order.
排序是根据记录之间的比较标准，将数据记录实际放入指定顺序的过程。排序可以应用于可以定义排序标准的任何类型的数据（包括文本数据）。与排序相关的算法关注的是将数据记录实际放入所需顺序的性能问题（在时间、内存或其他资源方面）。
A sorting algorithm for string data can be internationalized by providing it with the appropriate collation-weighted keys corresponding to the strings to be ordered.
字符串数据的排序算法可以国际化，方法是为其提供与要排序的字符串对应的适当排序加权键。
Many processes have a need to order strings in a consistent (sorted) sequence. For only a few CCS/CES combinations, there is an obvious sort order that can be applied without reference to the linguistic meaning of the characters: the code point order is sufficient for sorting. That is, the code point order is also the order that a person would use in sorting the characters. For many CCS/CES combinations, the code point order would make no sense to a person and therefore is not useful for sorting if the results will be displayed to a person.
许多进程都需要按一致（排序）的顺序对字符串排序。对于少数CCS/CES组合，有一个明显的排序顺序，可以在不参考字符语言含义的情况下应用：代码点顺序足以进行排序。也就是说，代码点顺序也是一个人在对字符进行排序时使用的顺序。对于许多CCS/CES组合，代码点顺序对一个人来说毫无意义，因此，如果结果将显示给一个人，则无法用于排序。
Code point order is usually not how any human educated by a local school system expects to see strings ordered; if one orders to the expectations of a human, one has a "language-specific" or "human language" sort. Sorting to code point order will seem inconsistent if the strings are not normalized before sorting because different representations of the same character will sort differently. This problem may be smaller with a language-specific sort.
代码点顺序通常不是任何受当地学校系统教育的人期望看到的字符串顺序；如果一个人的命令符合一个人的期望，那么他就有一种“特定语言”或“人类语言”类型。如果字符串在排序之前未规范化，则排序到代码点顺序将看起来不一致，因为同一字符的不同表示形式排序不同。对于特定于语言的排序，这个问题可能会更小。
code table
代码表
A code table is a table showing the characters allocated to the octets in a code. <ISOIEC10646>
代码表是显示代码中分配给八位字节的字符的表<ISO10646>
Code tables are also commonly called "code charts".
代码表通常也称为“代码图”。
The following definitions of types of characters do not clearly delineate each character into one type, nor do they allow someone to accurately predict what types would apply to a particular character. The definitions are intended for application designers to help them think about the many (sometimes confusing) properties of text.
以下字符类型的定义不能清楚地将每个字符划分为一种类型，也不能让人们准确地预测将应用于特定字符的类型。这些定义是为了帮助应用程序设计人员思考文本的许多属性（有时令人困惑）。
alphabetic
字母的
An informative Unicode property. Characters that are the primary units of alphabets and/or syllabaries, whether combining or non-combining. This includes composite characters that are canonical equivalents to a combining character sequence of an alphabetic base character plus one or more combining characters: letter digraphs; contextual variants of alphabetic characters; ligatures of alphabetic characters; contextual variants of ligatures; modifier letters; letterlike symbols that are compatibility equivalents of single alphabetic letters; and miscellaneous letter elements. <UNICODE>
提供信息的Unicode属性。作为字母表和/或音节的主要单位的字符，无论是组合字符还是非组合字符。这包括组合字符，其在规范上等同于字母基字符加上一个或多个组合字符的组合字符序列：字母有向图；字母字符的上下文变体；字母字符的连字；连字的语境变体；修饰字母；与单个字母兼容的字母符号；和其他字母元素<UNICODE>
ideographic
表意的
Any symbol that primarily denotes an idea (or meaning) in contrast to a sound (or pronunciation), for example, a symbol showing a telephone or the Han characters used in Chinese, Japanese, and Korean. <UNICODE>
主要表示与声音（或发音）相反的想法（或意义）的任何符号，例如，表示电话的符号或汉语、日语和韩语中使用的汉字<UNICODE>
While Unicode and many other systems use this term to refer to all Han characters, strictly speaking not all of those characters are actually ideographic. Some are pictographic (such as the telephone example above), some are used phonetically, and so on. However, the convention is to describe the script as ideographic as contrasted to alphabetic.
虽然Unicode和许多其他系统使用这个术语来指代所有的汉字，但严格来说，并不是所有的汉字都是表意文字。有些是象形的（如上面的电话示例），有些是语音的，等等。然而，惯例是将文字描述为表意文字，而不是字母文字。
digit or number
数字
All modern writing systems use decimal digits in some form; some older ones use non-positional or other systems. Different scripts may have their own digits. Unicode distinguishes between numbers and other kinds of characters by assigning a special General Category value to them and subdividing that value to distinguish between decimal digits, letter digits, and other digits. <UNICODE>
所有现代书写系统都以某种形式使用十进制数字；一些较旧的系统使用非位置系统或其他系统。不同的脚本可能有自己的数字。Unicode通过为数字和其他类型的字符指定一个特殊的通用类别值并细分该值来区分十进制数字、字母数字和其他数字，从而区分数字和其他类型的字符<UNICODE>
punctuation
标点符号
Characters that separate units of text, such as sentences and phrases, thus clarifying the meaning of the text. The use of punctuation marks is not limited to prose; they are also used in mathematical and scientific formulae, for example. <UNICODE>
分隔文本单位的字符，如句子和短语，从而阐明文本的含义。标点符号的使用不仅限于散文；例如，它们也用于数学和科学公式中<UNICODE>
symbol
象征
One of a set of characters other than those used for letters, digits, or punctuation, and representing various concepts generally not connected to written language use per se. <RFC6365>
除用于字母、数字或标点符号以外的一组字符中的一个，代表通常与书面语言使用本身无关的各种概念<RFC6365>
Examples of symbols include characters for mathematical operators, symbols for optical character recognition (OCR), symbols for box-drawing or graphics, as well as symbols for dingbats, arrows, faces, and geometric shapes. Unicode has a property that identifies symbol characters.
符号的示例包括用于数学运算符的字符、用于光学字符识别（OCR）的符号、用于方框图或图形的符号以及用于丁字、箭头、面和几何形状的符号。Unicode具有标识符号字符的属性。
nonspacing character
无空格字符
A combining character whose positioning in presentation is dependent on its base character. It generally does not consume space along the visual baseline in and of itself. <UNICODE>
一种组合字符，其在表示中的位置取决于其基本字符。它本身通常不会沿视觉基线消耗空间<UNICODE>
A combining acute accent (U+0301) is an example of a nonspacing character.
组合急性重音（U+0301）是非空格字符的一个示例。
diacritic
变音的
A mark applied or attached to a symbol to create a new symbol that represents a modified or new value. They can also be marks applied to a symbol irrespective of whether they change the value of that symbol. In the latter case, the diacritic usually represents an independent value (for example, an accent, tone, or some other linguistic information). Also called diacritical mark or diacritical. <UNICODE>
应用或附加到符号上的标记，用于创建表示修改值或新值的新符号。它们也可以是应用于符号的标记，无论它们是否更改该符号的值。在后一种情况下，变音符号通常表示一个独立的值（例如，重音、音调或其他一些语言信息）。也称为变音符号或变音符号<UNICODE>
control character
控制字符
The 65 characters in the ranges U+0000..U+001F and U+007F..U+009F.
The basic space character, U+0020, is often considered as a
control character as well, making the total number 66. They are
also known as control codes. In terminology adopted by Unicode
from ASCII and the ISO 8859 standards, these codes are treated as
belonging to three ranges: "C0" (for U+0000..U+001F), "C1" (for
U+0080...U+009F), and the single control character "DEL" (U+007F).
<UNICODE>
The 65 characters in the ranges U+0000..U+001F and U+007F..U+009F.
The basic space character, U+0020, is often considered as a
control character as well, making the total number 66. They are
also known as control codes. In terminology adopted by Unicode
from ASCII and the ISO 8859 standards, these codes are treated as
belonging to three ranges: "C0" (for U+0000..U+001F), "C1" (for
U+0080...U+009F), and the single control character "DEL" (U+007F).
<UNICODE>
Occasionally, in other vocabularies, the term "control character" is used to describe any character that does not normally have an associated glyph; it is also sometimes used for device control sequences [ISO6429]. Neither of those usages is appropriate to internationalization terminology in the IETF.
偶尔，在其他词汇表中，术语“控制字符”用于描述通常没有相关字形的任何字符；它有时也用于设备控制序列[ISO6429]。这两种用法都不适用于IETF中的国际化术语。
formatting character
格式化字符
Characters that are inherently invisible but that have an effect on the surrounding characters. <UNICODE>
本质上看不见但对周围角色有影响的角色<UNICODE>
Examples of formatting characters include characters for specifying the direction of text and characters that specify how to join multiple characters.
格式化字符的示例包括用于指定文本方向的字符和用于指定如何连接多个字符的字符。
compatibility character or compatibility variant
兼容字符或兼容变体
A graphic character included as a coded character of ISO/IEC 10646 primarily for compatibility with existing coded character sets. <ISOIEC10646)>
作为ISO/IEC 10646编码字符包含的图形字符，主要用于与现有编码字符集兼容<ISO10646）>
The Unicode definition of compatibility charter also includes characters that have been incorporated for other reasons. Their list includes several separate groups of characters included for compatibility purposes: halfwidth and fullwidth characters used with East Asian scripts, Arabic contextual forms (e.g., initial or final forms), some ligatures, deprecated formatting characters, variant forms of characters (or even copies of them) for particular uses (e.g., phonetic or mathematical applications), font variations, CJK compatibility ideographs, and so on. For additional information and the separate term "compatibility decomposable character", see the Unicode standard.
Unicode兼容性宪章的定义还包括因其他原因合并的字符。他们的列表包括几个独立的字符组，用于兼容性目的：与东亚脚本一起使用的半宽和全宽字符、阿拉伯语上下文形式（例如，首字母或末字母形式）、一些连字、不推荐使用的格式字符、特殊用途的字符变体（甚至是副本）（例如，语音或数学应用）、字体变化、CJK兼容表意文字等。有关其他信息和单独术语“兼容可分解字符”，请参阅Unicode标准。
For example, U+FF01 (FULLWIDTH EXCLAMATION MARK) was included for compatibility with Asian charsets that include full-width and half-width ASCII characters.
例如，包含U+FF01（全宽感叹号）是为了与包含全宽和半宽ASCII字符的亚洲字符集兼容。
Some efforts in the IETF have concluded that it would be useful to support mapping of some groups of compatibility equivalents and not others (e.g., supporting or mapping width variations while preserving or rejecting mathematical variations). See the IDNA Mapping document [RFC5895] for one example.
IETF中的一些工作得出结论，支持某些兼容性等价物组的映射而不是其他组的映射是有用的（例如，支持或映射宽度变化，同时保留或拒绝数学变化）。参见IDNA映射文档[RFC5895]中的一个示例。
Especially as existing IETF standards are internationalized, it is necessary to describe collections of characters including especially various subsets of Unicode. Because Unicode includes ways to code substantially all characters in contemporary use, subsets of the Unicode repertoire can be a useful tool for defining these collections as repertoires independent of specific Unicode coding.
特别是随着现有IETF标准的国际化，有必要描述字符集合，特别是Unicode的各种子集。由于Unicode包含了对当前使用的几乎所有字符进行编码的方法，因此Unicode指令集的子集可以成为一个有用的工具，用于将这些集合定义为独立于特定Unicode编码的指令集。
However specific collections are defined, it is important to remember that, while older CCSs such as ASCII and the ISO 8859 family are close-ended and fixed, Unicode is open-ended, with new character definitions, and often new scripts, being added every year or so. So, while, e.g., an ASCII subset, such as "uppercase letters", can be specified as a range of code points (4/1 to 5/10 for that example), similar definitions for Unicode either have to be specified in terms of Unicode properties or are very dependent on Unicode versions (and the relevant version must be identified in any specification). See the IDNA code point specification [RFC5892] for an example of specification by combinations of properties.
尽管定义了特定的集合，但重要的是要记住，虽然旧的CCS（如ASCII和ISO 8859系列）是封闭式和固定式的，但Unicode是开放式的，每年左右都会添加新的字符定义，通常还会添加新的脚本。因此，例如，虽然ASCII子集（如“大写字母”）可以指定为一系列代码点（例如4/1到5/10），但Unicode的类似定义要么必须根据Unicode属性指定，要么非常依赖Unicode版本（任何规范中都必须标识相关版本）。请参阅IDNA代码点规范[RFC5892]，以了解通过属性组合进行规范的示例。
Some terms are commonly used in the IETF to define character ranges and subsets. Some of these are imprecise and can cause confusion if not used carefully.
IETF中通常使用一些术语来定义字符范围和子集。其中一些是不精确的，如果不小心使用，可能会造成混淆。
non-ASCII
非ASCII码
The term "non-ASCII" strictly refers to characters other than those that appear in the ASCII repertoire, independent of the CCS or encoding used for them. In practice, if a repertoire such as that of Unicode is established as context, "non-ASCII" refers to characters in that repertoire that do not appear in the ASCII repertoire. "Outside the ASCII repertoire" and "outside the ASCII range" are practical, and more precise, synonyms for "non-ASCII".
术语“非ASCII”严格地指ASCII指令表中出现的字符以外的字符，与CCS或用于它们的编码无关。实际上，如果将Unicode等指令集建立为上下文，“非ASCII”指的是该指令集中未出现在ASCII指令集中的字符。“在ASCII指令集之外”和“在ASCII范围之外”是“非ASCII”的实用、更准确的同义词。
letters
信件
The term "letters" does not have an exact equivalent in the Unicode standard. Letters are generally characters that are used to write words, but that means very different things in different languages and cultures.
“字母”一词在Unicode标准中没有确切的等价物。字母通常是用来写单词的字符，但这在不同的语言和文化中意味着非常不同的东西。
Although the IETF does not standardize user interfaces, many protocols make assumptions about how a user will enter or see text that is used in the protocol. Internationalization challenges assumptions about the type and limitations of the input and output devices that may be used with applications that use various protocols. It is therefore useful to consider how users typically interact with text that might contain one or more non-ASCII characters.
尽管IETF没有标准化用户界面，但许多协议都假设用户将如何输入或查看协议中使用的文本。国际化挑战了关于输入和输出设备的类型和限制的假设，这些设备可能与使用各种协议的应用程序一起使用。因此，考虑用户通常如何与可能包含一个或多个非ASCII字符的文本交互是有用的。
input methods
输入法
An input method is a mechanism for a person to enter text into an application. <RFC6365>
输入法是一种用于将文本输入应用程序的机制<RFC6365>
Text can be entered into a computer in many ways. Keyboards are by far the most common device used, but many characters cannot be entered on typical computer keyboards in a single stroke. Many operating systems come with system software that lets users input characters outside the range of what is allowed by keyboards.
文本可以通过多种方式输入计算机。键盘是目前最常用的设备，但许多字符无法在典型的计算机键盘上一笔输入。许多操作系统都配有系统软件，允许用户输入键盘允许范围以外的字符。
For example, there are dozens of different input methods for Han characters in Chinese, Japanese, and Korean. Some start with phonetic input through the keyboard, while others use the number of strokes in the character. Input methods are also needed for scripts that have many diacritics, such as European or Vietnamese characters that have two or three diacritics on a single alphabetic character.
例如，汉语、日语和韩语中有几十种不同的汉字输入方法。一些是通过键盘输入语音，而另一些是使用字符的笔划数。对于具有许多变音符号的脚本，也需要输入方法，例如在单个字母字符上具有两个或三个变音符号的欧洲或越南字符。
The term "input method editor" (IME) is often used generically to describe the tools and software used to deal with input of characters on a particular system.
术语“输入法编辑器”（IME）通常用于描述用于处理特定系统上字符输入的工具和软件。
rendering rules
渲染规则
A rendering rule is an algorithm that a system uses to decide how to display a string of text. <RFC6365>
渲染规则是系统用来决定如何显示文本字符串的算法<RFC6365>
Some scripts can be directly displayed with fonts, where each character from an input stream can simply be copied from a glyph system and put on the screen or printed page. Other scripts need rules that are based on the context of the characters in order to render text for display.
有些脚本可以直接用字体显示，其中输入流中的每个字符可以简单地从字形系统复制并放在屏幕或打印页面上。其他脚本需要基于字符上下文的规则来呈现文本以供显示。
Some examples of these rendering rules include:
这些渲染规则的一些示例包括：
* Scripts such as Arabic (and many others), where the form of the letter changes depending on the adjacent letters, whether the letter is standing alone, at the beginning of a word, in the middle of a word, or at the end of a word. The rendering rules must choose between two or more glyphs.
* 诸如阿拉伯语（以及许多其他）的脚本，其中字母的形式取决于相邻字母，无论字母是独立的，在单词的开头，在单词的中间，或在单词的结尾。渲染规则必须在两个或多个图示符之间进行选择。
* Scripts such as the Indic scripts, where consonants may change their form if they are adjacent to certain other consonants or may be displayed in an order different from the way they are stored and pronounced. The rendering rules must choose between two or more glyphs.
* 例如印度语脚本，如果辅音与某些其他辅音相邻，则辅音可能改变其形式，或者可能以不同于其存储和发音方式的顺序显示。渲染规则必须在两个或多个图示符之间进行选择。
* Arabic and Hebrew scripts, where the order of the characters displayed are changed by the bidirectional properties of the alphabetic and other characters and with right-to-left and left-to-right ordering marks. The rendering rules must choose the order that characters are displayed.
* 阿拉伯文和希伯来文脚本，其中显示的字符顺序由字母和其他字符的双向属性更改，并带有从右到左和从左到右的顺序标记。渲染规则必须选择字符的显示顺序。
* Some writing systems cannot have their rendering rules suitably defined using mechanisms that are now defined in the Unicode Standard. None of those languages are in active non-scholarly use today.
* 某些书写系统无法使用Unicode标准中现在定义的机制适当地定义其呈现规则。今天，这些语言中没有一种在非学术领域被积极使用。
* Many systems use a special rendering rule when they lack a font or other mechanism for rendering a particular character correctly. That rule typically involves substitution of a small open box or a question mark for the missing character. See "undisplayable character" below.
* 许多系统在缺少正确渲染特定字符的字体或其他机制时使用特殊的渲染规则。该规则通常涉及用一个小的开口框或问号替换缺少的字符。请参阅下面的“无法显示的字符”。
graphic symbol
图形符号
A graphic symbol is the visual representation of a graphic character or of a composite sequence. <ISOIEC10646>
图形符号是图形字符或复合序列的视觉表示<ISO10646>
font
字体
A font is a collection of glyphs used for the visual depiction of character data. A font is often associated with a set of parameters (for example, size, posture, weight, and serifness), which, when set to particular values, generates a collection of imagable glyphs. <UNICODE>
字体是用于可视化描述字符数据的字形集合。字体通常与一组参数（例如，大小、姿势、重量和衬度）相关联，当设置为特定值时，这些参数会生成一组可想象的字形<UNICODE>
The term "font" is often used interchangeably with "typeface". As historically used in typography, a typeface is a family of one or more fonts that share a common general design. For example, "Times Roman" is actually a typeface, with a collection of fonts
术语“字体”经常与“字体”互换使用。正如历史上在印刷术中使用的那样，字体是一个或多个字体的家族，它们共享一个通用的设计。例如，“Times Roman”实际上是一种字体，带有一系列字体
such as "Times Roman Bold", "Times Roman Medium", "Times Roman Italic", and so on. Some sources even consider different type sizes within a typeface to be different fonts. While those distinctions are rarely important for internationalization purposes, there are exceptions. Those writing specifications should be very careful about definitions in cases in which the exceptions might lead to ambiguity.
如“时代罗马粗体”、“时代罗马中体”、“时代罗马斜体”等。一些来源甚至认为字体内不同的字体大小是不同字体。虽然这些区别对于国际化目的很少重要，但也有例外。在异常可能导致歧义的情况下，编写规范的人应该非常小心定义。
bidirectional display
双向显示
The process or result of mixing left-to-right oriented text and right-to-left oriented text in a single line is called bidirectional display, often abbreviated as "bidi". <UNICODE>
将从左到右的文本和从右到左的文本混合在一行中的过程或结果称为双向显示，通常缩写为“bidi”<UNICODE>
Most of the world's written languages are displayed left-to-right. However, many widely-used written languages such as ones based on the Hebrew or Arabic scripts are displayed primarily right-to-left (numerals are a common exception in the modern scripts). Right-to-left text often confuses protocol writers because they have to keep thinking in terms of the order of characters in a string in memory, an order that might be different from what they see on the screen. (Note that some languages are written both horizontally and vertically and that some historical ones use other display orderings.)
世界上大多数书面语言都是从左到右显示的。然而，许多广泛使用的书面语言，如基于希伯来语或阿拉伯语的文字，主要从右向左显示（数字是现代文字中常见的例外）。从右到左的文本通常会让协议编写者感到困惑，因为他们必须不断思考内存中字符串中字符的顺序，这种顺序可能不同于他们在屏幕上看到的顺序。（请注意，有些语言是水平和垂直书写的，有些历史语言使用其他显示顺序。）
Further, bidirectional text can cause confusion because there are formatting characters in ISO/IEC 10646 that cause the order of display of text to change. These explicit formatting characters change the display regardless of the implicit left-to-right or right-to-left properties of characters. Text that might contain those characters typically requires careful processing before being sorted or compared for equality.
此外，双向文本可能导致混淆，因为ISO/IEC 10646中存在导致文本显示顺序改变的格式化字符。无论字符的隐式从左到右或从右到左属性如何，这些显式格式字符都会更改显示。可能包含这些字符的文本在排序或比较是否相等之前通常需要仔细处理。
It is common to see strings with text in both directions, such as strings that include both text and numbers, or strings that contain a mixture of scripts.
在两个方向上都有文本的字符串很常见，例如同时包含文本和数字的字符串，或者包含混合脚本的字符串。
Unicode has a long and incredibly detailed algorithm for displaying bidirectional text [UAX9].
Unicode有一个长且非常详细的算法来显示双向文本[UAX9]。
undisplayable character
不可展开字符
A character that has no displayable form. <RFC6365>
没有可显示形式的字符<RFC6365>
For instance, the zero-width space (U+200B) cannot be displayed because it takes up no horizontal space. Formatting characters such as those for setting the direction of text are also undisplayable. Note, however, that every character in [UNICODE]
例如，零宽度空间（U+200B）无法显示，因为它不占用水平空间。格式化字符（如用于设置文本方向的字符）也不可显示。但是，请注意，[UNICODE]中的每个字符
has a glyph associated with it, and that the glyphs for undisplayable characters are enclosed in a dashed square as an indication that the actual character is undisplayable.
具有与其关联的标志符号，并且不可显示字符的标志符号包含在虚线方框中，以指示实际字符不可显示。
The property of a character that causes it to be undisplayable is intrinsic to its definition. Undisplayable characters can never be displayed in normal text (the dashed square notation is used only in special circumstances). Printable characters whose Unicode definitions are associated with glyphs that cannot be rendered on a particular system are not, in this sense, undisplayable.
导致字符无法显示的字符属性是其定义的固有属性。无法显示的字符永远不能在普通文本中显示（虚线方形符号仅在特殊情况下使用）。从这个意义上讲，Unicode定义与无法在特定系统上呈现的字形关联的可打印字符不是不可打印的。
writing style
写作风格
Conventions of writing the same script in different styles. <RFC6365>
用不同的风格写同一个脚本的惯例<RFC6365>
Different communities using the script may find text in different writing styles difficult to read and possibly unintelligible. For example, the Perso-Arabic Nastalique writing style and the Arabic Naskh writing style both use the Arabic script but have very different renderings and are not mutually comprehensible. Writing styles may have significant impact on internationalization; for example, the Nastalique writing style requires significantly more line height than Naskh writing style.
使用该脚本的不同社区可能会发现不同书写风格的文本难以阅读，甚至可能无法理解。例如，Perso-Arabic-Nastalique书写风格和Arabic-Naskh书写风格都使用阿拉伯语脚本，但呈现方式非常不同，无法相互理解。写作风格可能对国际化产生重大影响；例如，纳斯塔利克写作风格比纳斯克写作风格需要更多的线条高度。
Many IETF protocols started off being fully internationalized, while others have been internationalized as they were revised. In this process, IETF members have seen patterns in the way that many protocols use text. This section describes some specific protocol interactions with text.
许多IETF协议一开始是完全国际化的，而其他协议在修订时已经国际化。在这个过程中，IETF成员看到了许多协议使用文本的方式。本节介绍一些与文本的特定协议交互。
protocol elements
协议要素
Protocol elements are uniquely named parts of a protocol. <RFC6365>
协议元素是协议的唯一命名部分<RFC6365>
Almost every protocol has named elements, such as "source port" in TCP. In some protocols, the names of the elements (or text tokens for the names) are transmitted within the protocol. For example, in SMTP and numerous other IETF protocols, the names of the verbs are part of the command stream. The names are thus part of the protocol standard. The names of protocol elements are not normally seen by end users, and it is rarely appropriate to internationalize protocol element names (even while the elements themselves can be internationalized).
几乎每个协议都有命名元素，例如TCP中的“源端口”。在某些协议中，元素的名称（或名称的文本标记）在协议中传输。例如，在SMTP和许多其他IETF协议中，动词的名称是命令流的一部分。因此，这些名称是协议标准的一部分。终端用户通常看不到协议元素的名称，因此很少适合国际化协议元素名称（即使元素本身可以国际化）。
name spaces
名称空间
A name space is the set of valid names for a particular item, or the syntactic rules for generating these valid names. <RFC6365>
名称空间是特定项的有效名称集，或者是生成这些有效名称的语法规则<RFC6365>
Many items in Internet protocols use names to identify specific instances or values. The names may be generated (by some prescribed rules), registered centrally (e.g., such as with IANA), or have a distributed registration and control mechanism, such as the names in the DNS.
Internet协议中的许多项使用名称来标识特定实例或值。这些名称可以（通过某些规定的规则）生成、集中注册（例如，使用IANA），或者具有分布式注册和控制机制，例如DNS中的名称。
on-the-wire encoding
论有线编码
The encoding and decoding used before and after transmission over the network is often called the "on-the-wire" (or sometimes just "wire") format. <RFC6365>
在通过网络传输之前和之后使用的编码和解码通常称为“在线”（有时只是“在线”）格式<RFC6365>
Characters are identified by code points. Before being transmitted in a protocol, they must first be encoded as bits and octets. Similarly, when characters are received in a transmission, they have been encoded, and a protocol that needs to process the individual characters needs to decode them before processing.
字符由代码点标识。在协议中传输之前，必须首先将其编码为位和八位字节。类似地，当在传输中接收到字符时，它们已经被编码，并且需要处理单个字符的协议需要在处理之前对它们进行解码。
parsed text
解析文本
Text strings that have been analyzed for subparts. <RFC6365>
已分析子部分的文本字符串<RFC6365>
In some protocols, free text in text fields might be parsed. For example, many mail user agents (MUAs) will parse the words in the text of the Subject: field to attempt to thread based on what appears after the "Re:" prefix.
在某些协议中，可以解析文本字段中的自由文本。例如，许多邮件用户代理（MUA）将解析Subject:字段文本中的单词，以尝试根据“Re:”前缀后出现的内容执行线程。
Such conventions are very sensitive to localization. If, for example, a form like "Re:" is altered by an MUA to reflect the language of the sender or recipient, a system that subsequently does threading may not recognize the replacement term as a delimiter string.
这些约定对本地化非常敏感。例如，如果MUA修改了“Re:”等形式以反映发送方或接收方的语言，则随后不执行线程处理的系统可能无法将替换术语识别为分隔符字符串。
charset identification
字符集识别
Specification of the charset used for a string of text. <RFC6365>
用于文本字符串的字符集的规范<RFC6365>
Protocols that allow more than one charset to be used in the same place should require that the text be identified with the appropriate charset. Without this identification, a program looking at the text cannot definitively discern the charset of the text. Charset identification is also called "charset tagging".
允许在同一位置使用多个字符集的协议应要求使用适当的字符集标识文本。如果没有此标识，查看文本的程序就无法最终识别文本的字符集。字符集标识也称为“字符集标记”。
language identification
语言识别
Specification of the human language used for a string of text. <RFC6365>
用于文本字符串的人类语言规范<RFC6365>
Some protocols (such as MIME and HTTP) allow text that is meant for machine processing to be identified with the language used in the text. Such identification is important for machine processing of the text, such as by systems that render the text by speaking it. Language identification is also called "language tagging". The IETF "LTRU" standards [RFC5646] and [RFC4647] provide a comprehensive model for language identification.
某些协议（如MIME和HTTP）允许使用文本中使用的语言来标识用于机器处理的文本。这种识别对于文本的机器处理非常重要，例如通过系统通过说出文本来呈现文本。语言识别也称为“语言标记”。IETF“LTRU”标准[RFC5646]和[RFC4647]提供了语言识别的综合模型。
MIME
哑剧表演
MIME (Multipurpose Internet Mail Extensions) is a message format that allows for textual message bodies and headers in character sets other than US-ASCII in formats that require ASCII (most notably RFC 5322, the standard for Internet mail headers [RFC5322]). MIME is described in RFCs 2045 through 2049, as well as more recent RFCs. <RFC6365>
MIME（Multipurpose Internet Mail Extensions，多用途Internet邮件扩展）是一种消息格式，允许文本消息正文和字符集（US-ASCII除外）中的标题采用需要ASCII的格式（最著名的是RFC 5322，Internet邮件标题的标准[RFC5322]）。MIME在RFCs 2045到2049以及最近的RFCs中有描述<RFC6365>
transfer encoding syntax
传输编码语法
A transfer encoding syntax (TES) (sometimes called a transfer encoding scheme) is a reversible transform of already encoded data that is represented in one or more character encoding schemes. <RFC6365>
传输编码语法（TES）（有时称为传输编码方案）是在一个或多个字符编码方案中表示的已编码数据的可逆转换<RFC6365>
TESs are useful for encoding types of character data into another format, usually for allowing new types of data to be transmitted over legacy protocols. The main examples of TESs used in the IETF include Base64 and quoted-printable. MIME identifies the transfer encoding syntax for body parts as a Content-transfer-encoding, occasionally abbreviated C-T-E.
TESs用于将字符数据类型编码为另一种格式，通常用于允许通过传统协议传输新类型的数据。IETF中使用的TESs的主要示例包括Base64和引用的printable。MIME将身体部位的传输编码语法标识为内容传输编码，有时缩写为C-T-E。
Base64
Base64
Base64 is a transfer encoding syntax that allows binary data to be
represented by the ASCII characters A through Z, a through z, 0
through 9, +, /, and =. It is defined in [RFC2045]. <RFC6365>
Base64 is a transfer encoding syntax that allows binary data to be
represented by the ASCII characters A through Z, a through z, 0
through 9, +, /, and =. It is defined in [RFC2045]. <RFC6365>
quoted printable
引用可打印
Quoted printable is a transfer encoding syntax that allows strings that have non-ASCII characters mixed in with mostly ASCII printable characters to be somewhat human readable. It is described in [RFC2047]. <RFC6365>
Quoted printable是一种传输编码语法，它允许非ASCII字符与大部分ASCII可打印字符混合的字符串具有一定的可读性。[RFC2047]对此进行了描述<RFC6365>
The quoted printable syntax is generally considered to be a failure at being readable. It is jokingly referred to as "quoted unreadable".
引用的可打印语法通常被认为是不可读的。它被戏称为“引用的不可读”。
XML
XML
XML (which is an approximate abbreviation for Extensible Markup
Language) is a popular method for structuring text. XML text that
is not encoded as UTF-8 is explicitly tagged with charsets, and
all text in XML consists only of Unicode characters. The
specification for XML can be found at <http://www.w3.org/XML/>.
<RFC6365>
XML (which is an approximate abbreviation for Extensible Markup
Language) is a popular method for structuring text. XML text that
is not encoded as UTF-8 is explicitly tagged with charsets, and
all text in XML consists only of Unicode characters. The
specification for XML can be found at <http://www.w3.org/XML/>.
<RFC6365>
ASN.1 text formats
ASN.1文本格式
The ASN.1 data description language has many formats for text data. The formats allow for different repertoires and different encodings. Some of the formats that appear in IETF standards based on ASN.1 include IA5String (all ASCII characters), PrintableString (most ASCII characters, but missing many punctuation characters), BMPString (characters from ISO/IEC 10646 plane 0 in UTF-16BE format), UTF8String (just as the name implies), and TeletexString (also called T61String).
ASN.1数据描述语言有多种文本数据格式。这些格式允许不同的曲目和不同的编码。基于ASN.1的IETF标准中出现的一些格式包括IA5String（所有ASCII字符）、PrintableString（大多数ASCII字符，但缺少许多标点字符）、BMPString（UTF-16BE格式的ISO/IEC 10646平面0中的字符）、UTF8String（顾名思义）和TeletextString（也称为T61String）。
ASCII-compatible encoding (ACE)
ASCII兼容编码（ACE）
Starting in 1996, many ASCII-compatible encoding schemes (which are actually transfer encoding syntaxes) have been proposed as possible solutions for internationalizing host names and some other purposes. Their goal is to be able to encode any string of ISO/IEC 10646 characters using the preferred syntax for domain names (as described in STD 13). At the time of this writing, only the ACE produced by Punycode [RFC3492] has become an IETF standard.
从1996年开始，许多ASCII兼容编码方案（实际上是传输编码语法）被提出作为国际化主机名和其他目的的可能解决方案。他们的目标是能够使用域名的首选语法（如STD 13所述）对ISO/IEC 10646字符的任何字符串进行编码。在撰写本文时，只有Punycode[RFC3492]生产的ACE已成为IETF标准。
The choice of ACE forms to internationalize legacy protocols must be made with care as it can cause some difficult side effects [RFC6055].
选择ACE形式来国际化遗留协议时必须小心，因为它可能会导致一些困难的副作用[RFC6055]。
LDH label
乳酸脱氢酶标签
The classical label form used in the DNS and most applications that call on it, albeit with some additional restrictions, reflects the early syntax of "hostnames" [RFC0952] and limits those names to ASCII letters, digits, and embedded hyphens. The hostname syntax is identical to that described as the "preferred name syntax" in Section 3.5 of RFC 1034 [RFC1034] as modified by
DNS和大多数调用它的应用程序中使用的经典标签形式（尽管有一些附加限制）反映了“主机名”[RFC0952]的早期语法，并将这些名称限制为ASCII字母、数字和嵌入连字符。主机名语法与RFC 1034[RFC1034]第3.5节中描述的“首选名称语法”相同，由修改
RFC 1123 [RFC1123]. LDH labels are defined in a more restrictive and precise way for internationalization contexts as part of the IDNA2008 specification [RFC5890].
RFC 1123[RFC1123]。作为IDNA2008规范[RFC5890]的一部分，LDH标签在国际化上下文中以更严格和精确的方式定义。
The current specification for Internationalized Domain Names (IDNs), known formally as Internationalized Domain Names for Applications or IDNA, is referred to in the IETF and parts of the broader community as "IDNA2008" and consists of several documents. Section 2.3 of the first of those documents, commonly known as "IDNA2008 Definitions" [RFC5890] provides definitions and introduces some specialized terms for differentiating among types of DNS labels in an IDN context. Those terms are listed in the table below; see RFC 5890 for the specific definitions if needed.
当前的国际化域名规范（IDN），正式称为应用程序国际化域名或IDNA，在IETF和更广泛的社区中称为“IDNA2008”，由多个文档组成。第一份文件的第2.3节，通常称为“IDNA2008定义”[RFC5890]提供了定义，并介绍了一些专门术语，用于区分IDN上下文中的DNS标签类型。下表列出了这些术语；如有需要，具体定义见RFC 5890。
ACE Prefix A-label Domain Name Slot IDNA-valid string Internationalized Domain Name (IDN) Internationalized Label LDH Label Non-Reserved LDH label (NR-LDH label) U-label
ACE前缀A标签域名插槽IDNA有效字符串国际化域名（IDN）国际化标签LDH标签非保留LDH标签（NR-LDH标签）U标签
Two additional terms entered the IETF's vocabulary as part of the earlier IDN effort [RFC3490] (IDNA2003):
作为早期IDN工作[RFC3490]（IDNA2003）的一部分，另外两个术语进入了IETF的词汇表：
Stringprep
Stringprep
Stringprep [RFC3454] provides a model and character tables for preparing and handling internationalized strings. It was used in the original IDN specification (IDNA2003) via a profile called "Nameprep" [RFC3491]. It is no longer in use in IDNA, but continues to be used in profiles by a number of other protocols. <RFC6365>
Stringprep[RFC3454]提供用于准备和处理国际化字符串的模型和字符表。它通过名为“Nameprep”[RFC3491]的概要文件在原始IDN规范（IDNA2003）中使用。它不再在IDNA中使用，但仍由许多其他协议在概要文件中使用<RFC6365>
Punycode
小码
This is the name of the algorithm [RFC3492] used to convert otherwise-valid IDN labels from native-character strings expressed in Unicode to an ASCII-compatible encoding (ACE). Strictly speaking, the term applies to the algorithm only. In practice, it is widely, if erroneously, used to refer to strings that the algorithm encodes.
这是用于将原本有效的IDN标签从Unicode表示的本机字符串转换为ASCII兼容编码（ACE）的算法[RFC3492]的名称。严格来说，该术语仅适用于算法。在实践中，它被广泛地（如果有错误的话）用于指代算法编码的字符串。
The term "variant" was introduced into the IETF i18n vocabulary with the JET recommendations [RFC3743]. As used there, it referred strictly to the relationship between Traditional Chinese characters and their Simplified equivalents. The JET recommendations provided a model for identifying these pairs of characters and labels that used them. Specific recommendations for variant handling for the Chinese language were provided in a follow-up document [RFC4713].
术语“变体”与JET建议一起引入IETF i18n词汇表[RFC3743]。在这里，它严格地指的是繁体汉字和简化汉字之间的关系。JET建议提供了一个识别这些字符对和使用它们的标签的模型。后续文件[RFC4713]中提供了中文变体处理的具体建议。
In more recent years, the term has also been used to describe other collections of characters or strings that might be perceived as equivalent. Those collections have involved one or more of several categories of characters and labels containing them including:
近年来，该术语还被用于描述其他可能被视为等效的字符或字符串集合。这些集合涉及一个或多个类别的字符和包含它们的标签，包括：
o "visually similar" or "visually confusable" characters. These may be limited to characters in different scripts, characters in a single script, or both, and may be those that can appear to be alike even when high-distinguishability reference fonts are used or under various circumstances that may involve malicious choices of typefaces or other ways to trick user perception. Trivial examples include ASCII "l" and "1" and Latin and Cyrillic "a".
o “视觉相似”或“视觉易混淆”字符。这些可能仅限于不同脚本中的字符、单个脚本中的字符或两者，并且可能是那些即使在使用高分辨率参考字体时，或在可能涉及恶意字体选择或其他欺骗用户感知的方式的各种情况下，也可能看起来相似的字符。简单的例子包括ASCII“l”和“1”以及拉丁语和西里尔语“a”。
o Characters assigned more than one Unicode code point because of some special property. These characters may be considered "the same" for some purposes and different for others (or by other users). One of the most commonly cited examples is the Arabic YEH, which is encoded more than once because some of its shapes are different across different languages. Another example are the Greek lowercase sigma and final sigma: if the latter were viewed purely as a positional presentation variation on the former, it should not have been assigned a separate code point.
o 由于某些特殊属性，字符分配了多个Unicode代码点。这些字符在某些情况下可能被视为“相同”，而在其他情况下（或其他用户）可能被视为“不同”。最常被引用的例子之一是阿拉伯语YEH，它被多次编码，因为它的一些形状在不同的语言中是不同的。另一个例子是希腊字母小写的sigma和final sigma：如果后者纯粹被视为前者的位置表示变体，则不应为其分配单独的代码点。
o Numerals and labels including them. Unlike letters, the "meaning" of decimal digits is clear and unambiguous regardless of the script with which they are associated. Some scripts are routinely used almost interchangeably with European digits and digits native to that script. The Arabic script has two sets of digits (U+0660..U+0669 and U+06F0..U=06F9), written identically for zero through three and seven through nine but differently for four through six; European digits predominate in other areas. Substitution of digits with the same numeric value in labels may give rise to another type of variant.
o 数字和标签，包括它们。与字母不同，十进制数字的“含义”是明确的，无论它们与哪个脚本相关联。一些脚本通常与欧洲数字和该脚本固有的数字互换使用。阿拉伯文字有两组数字（U+0660..U+0669和U+06F0..U=06F9），以相同的方式表示零到三和七到九，但以不同的方式表示四到六；欧洲数字在其他领域占主导地位。替换标签中具有相同数值的数字可能会产生另一种变体。
o Orthographic differences within a language. Many languages have alternate choices of spellings or spellings that differ by locale. Users of those languages generally recognize the spellings as equivalent, at least as much so as the variations described above.
o 一种语言中的正字法差异。许多语言都有不同的拼写选择，或因语言环境而异的拼写选择。这些语言的使用者通常认为拼写是等效的，至少与上述变体一样。
Examples include "color" and "colour" in English, German words spelled with o-umlaut or "oe", and so on. Some of these relationships may also create other types of language-specific perceived differences that do not exist for other languages using the same script. For example, in Arabic language usage at the end of words, ARABIC LETTER TEH MARBUTA (U+0629) and ARABIC LETTER HEH (U+0647) are differently shaped (one has 2 dots in top of it), but they are used interchangeably in writing: they "sound" similar when pronounced at the end of phrase, and hence the LETTER TEH MARBUTA sometimes is written as LETTER HEH and the two are considered "confusable" in that context.
例如英语中的“color”和“color”，德语中拼写为o-umlaut或“oe”的单词等等。其中一些关系还可能产生其他类型的特定于语言的感知差异，这些差异对于使用相同脚本的其他语言来说是不存在的。例如，在阿拉伯语单词末尾的用法中，阿拉伯字母TEH MARBUTA（U+0629）和阿拉伯字母HEH（U+0647）的形状不同（其中一个字母顶部有两个点），但在书写中可以互换使用：它们在短语末尾发音时“发音”相似，因此，字母TEH MARBUTA有时被写成字母HEH，在这种情况下，这两个字母被认为是“可混淆的”。
The term "variant" as used in this section should also not be confused with other uses of the term in this document or in Unicode terminology (e.g., those in Section 4.1 above). If the term is to be used at all, context should clearly distinguish among these different uses and, in particular, between variant characters and variant labels. Local text should identify which meaning, or combination of meanings, are intended.
本节中使用的术语“变体”也不应与本文件或Unicode术语（例如，上文第4.1节中的术语）中该术语的其他用法混淆。如果要使用该术语，上下文应清楚区分这些不同的用途，尤其是变体字符和变体标签。本地文本应确定拟使用的含义或含义组合。
This is a hodge-podge of other terms that have appeared in internationalization discussions in the IETF.
这是IETF国际化讨论中出现的其他术语的大杂烩。
locale
场所
Locale is the user-specific location and cultural information managed by a computer. <RFC6365>
Locale是由计算机管理的用户特定位置和文化信息<RFC6365>
Because languages and orthographic conventions differ from country to country (and even region to region within a country), the locale of the user can often be an important factor. Typically, the locale information for a user includes the language(s) used.
由于语言和正字法惯例因国家而异（甚至一个国家内的不同地区），因此用户的语言环境往往是一个重要因素。通常，用户的区域设置信息包括所使用的语言。
Locale issues go beyond character use, and can include things such as the display format for currency, dates, and times. Some locales (especially the popular "C" and "POSIX" locales) do not include language information.
区域设置问题超出了字符使用范围，可能包括货币、日期和时间的显示格式等内容。某些地区（特别是流行的“C”和“POSIX”地区）不包含语言信息。
It should be noted that there are many thorny, unsolved issues with locale. For example, should text be viewed using the locale information of the person who wrote the text, information that would apply to the location of the system storing or providing the text, or the person viewing it? What if the person viewing it is traveling to different locations? Should only some of the locale information affect creation and editing of text?
应该注意的是，locale有许多棘手的、未解决的问题。例如，是否应使用编写文本的人员的区域设置信息、适用于存储或提供文本的系统位置的信息或查看文本的人员的信息来查看文本？如果观看它的人要去不同的地方怎么办？是否只有部分区域设置信息会影响文本的创建和编辑？
Latin characters
拉丁字符
"Latin characters" is a not-precise term for characters historically related to ancient Greek script as modified in the Roman Republic and Empire and currently used throughout the world. <RFC6365>
“拉丁字符”是一个不精确的术语，用于表示历史上与古希腊文字有关的字符，古希腊文字在罗马共和国和罗马帝国进行了修改，目前在世界各地使用<RFC6365>
The base Latin characters are a subset of the ASCII repertoire and have been augmented by many single and multiple diacritics and quite a few other characters. ISO/IEC 10646 encodes the Latin characters in including ranges U+0020..U+024F and U+1E00..U+1EFF.
基本拉丁字符是ASCII指令集的一个子集，并已由许多单个和多个变音符号以及许多其他字符扩展。ISO/IEC 10646编码范围包括U+0020..U+024F和U+1E00..U+1EFF的拉丁字符。
Because "Latin characters" is used in different contexts to refer to the letters from the ASCII repertoire, the subset of those characters used late in the Roman Republic period, or the different subset used to write Latin in medieval times, the entire ASCII repertoire, all of the code points in the extended Latin script as defined by Unicode, and other collections, the term should be avoided in IETF specifications when possible. Similarly, "Basic Latin" should not be used as a synonym for "ASCII".
因为“拉丁字符”在不同的上下文中用于指代ASCII指令表中的字母、罗马共和国晚期使用的这些字符的子集或中世纪用于书写拉丁语的不同子集、整个ASCII指令表、Unicode定义的扩展拉丁语脚本中的所有代码点，在IETF规范中应尽可能避免使用该术语。同样，“基本拉丁语”不应用作“ASCII”的同义词。
romanization
罗马化
The transliteration of a non-Latin script into Latin characters. <RFC6365>
将非拉丁文字音译成拉丁文字<RFC6365>
Because of their widespread use, Latin characters (or graphemes constructed from them) are often used to try to write text in languages that didn't previously have writing systems or whose writing systems were originally based on different scripts. For example, there are two popular romanizations of Chinese: Wade-Giles and Pinyin, the latter of which is by far more common today. Many romanization systems are inexact and do not give perfect round-trip mappings between the native script and the Latin characters.
由于拉丁字符的广泛使用，拉丁字符（或由其构成的字形）经常被用来尝试用以前没有书写系统或其书写系统最初基于不同脚本的语言书写文本。例如，汉语有两种流行的罗马化：韦德·吉尔斯（Wade Giles）和拼音，后者在今天更为常见。许多罗马化系统是不精确的，不能在本地脚本和拉丁字符之间提供完美的往返映射。
CJK characters and Han characters
汉字与汉字
The ideographic characters used in Chinese, Japanese, Korean, and traditional Vietnamese writing systems are often called "CJK characters" after the initial letters of the language names in English. They are also called "Han characters", after the term in Chinese that is often used for these characters. <RFC6365>
中文、日文、韩文和传统越南语书写系统中使用的表意字符通常在英文名称的首字母后称为“CJK字符”。他们也被称为“汉字”，在汉语中经常用于这些汉字<RFC6365>
Note that Han characters do not include the phonetic characters used in the Japanese and Korean languages. Users of the term "CJK characters" may or may not assume those additional characters are included.
请注意，汉字不包括日语和韩语中使用的拼音字符。术语“CJK字符”的用户可能会也可能不会认为这些附加字符包括在内。
In ISO/IEC 10646, the Han characters were "unified", meaning that each set of Han characters from Japanese, Chinese, and/or Korean that had the same origin was assigned a single code point. The positive result of this was that many fewer code points were needed to represent Han; the negative result of this was that characters that people who write the three languages think are different have the same code point. There is a great deal of disagreement on the nature, the origin, and the severity of the problems caused by Han unification.
在ISO/IEC 10646中，汉字是“统一”的，这意味着来自日语、汉语和/或韩语的具有相同来源的每组汉字都被分配一个代码点。这样做的积极结果是，代表汉族所需的代码点要少得多；这样做的负面结果是，编写这三种语言的人认为不同的字符具有相同的代码点。关于汉朝统一所造成的问题的性质、根源和严重性，存在着很大的分歧。
translation
翻译
The process of conveying the meaning of some passage of text in one language, so that it can be expressed equivalently in another language. <RFC6365>
用一种语言表达某段文字的意思，以便用另一种语言表达的过程<RFC6365>
Many language translation systems are inexact and cannot be applied repeatedly to go from one language to another to another.
许多语言翻译系统是不精确的，不能重复地应用于从一种语言到另一种语言的翻译。
transliteration
音译
The process of representing the characters of an alphabetical or syllabic system of writing by the characters of a conversion alphabet. <RFC6365>
用转换字母表的字符表示字母或音节书写系统的字符的过程<RFC6365>
Many script transliterations are exact, and many have perfect round-trip mappings. The notable exception to this is romanization, described above. Transliteration involves converting text expressed in one script into another script, generally on a letter-by-letter basis. There are many official and unofficial transliteration standards, most notably those from ISO TC 46 and the U.S. Library of Congress.
许多脚本的音译都是精确的，并且许多都有完美的往返映射。值得注意的例外是上文所述的罗马化。音译包括将一个脚本中表达的文本转换成另一个脚本，通常是逐字翻译。有许多官方和非官方的音译标准，尤其是来自ISO TC 46和美国国会图书馆的标准。
transcription
转录
The process of systematically writing the sounds of some passage of spoken language, generally with the use of a technical phonetic alphabet (usually Latin-based) or other systematic transcriptional orthography. Transcription also sometimes refers to the conversion of written text into a transcribed form, based on the sound of the text as if it had been spoken. <RFC6365>
系统地书写口语中某些段落的声音的过程，通常使用技术语音字母表（通常以拉丁语为基础）或其他系统的转录正字法。转录有时也指将书面文本转换成转录的形式，基于文本的声音，就好像它已经被说出来一样<RFC6365>
Unlike transliterations, which are generally designed to be round-trip convertible, transcriptions of written material are almost never round-trip convertible to their original form, at least without some supplemental information.
与音译不同，音译通常被设计成可来回转换的形式，书面材料的抄本几乎从来不会来回转换成原始形式，至少在没有一些补充信息的情况下是如此。
regular expressions
正则表达式
Regular expressions provide a mechanism to select specific strings from a set of character strings. Regular expressions are a language used to search for text within strings, and possibly modify the text found with other text. <RFC6365>
正则表达式提供了一种从一组字符串中选择特定字符串的机制。正则表达式是一种用于搜索字符串中的文本的语言，并且可能会修改与其他文本一起找到的文本<RFC6365>
Pattern matching for text involves being able to represent one or more code points in an abstract notation, such as searching for all capital Latin letters or all punctuation. The most common mechanism in IETF protocols for naming such patterns is the use of regular expressions. There is no single regular expression language, but there are numerous very similar dialects that are not quite consistent with each other.
文本模式匹配涉及到能够以抽象符号表示一个或多个代码点，例如搜索所有大写拉丁字母或所有标点符号。IETF协议中命名此类模式的最常见机制是使用正则表达式。没有单一的正则表达式语言，但是有许多非常相似的方言，它们之间并不完全一致。
The Unicode Consortium has a good discussion about how to adapt regular expression engines to use Unicode. [UTR18]
Unicode联盟就如何调整正则表达式引擎以使用Unicode进行了很好的讨论。[18]
private use character
专用字符
ISO/IEC 10646 code points from U+E000 to U+F8FF, U+F0000 to
U+FFFFD, and U+100000 to U+10FFFD are available for private use.
This refers to code points of the standard whose interpretation is
not specified by the standard and whose use may be determined by
private agreement among cooperating users. <UNICODE>
ISO/IEC 10646 code points from U+E000 to U+F8FF, U+F0000 to
U+FFFFD, and U+100000 to U+10FFFD are available for private use.
This refers to code points of the standard whose interpretation is
not specified by the standard and whose use may be determined by
private agreement among cooperating users. <UNICODE>
The use of these "private use" characters is defined by the parties who transmit and receive them, and is thus not appropriate for standardization. (The IETF has a long history of private use names for things such as "x-" names in MIME types, charsets, and languages. Most of the experience with these has been quite negative, with many implementors assuming that private use names are in fact public and long-lived.)
这些“专用”字符的使用由发送和接收它们的各方定义，因此不适合标准化。（IETF在诸如MIME类型、字符集和语言中的“x-”名称的私有使用名称方面有着悠久的历史。大多数使用这些名称的经验都是负面的，许多实现者认为私有使用名称实际上是公共的和长期存在的。）
Security is not discussed directly in this document. While the definitions here have no direct effect on security, they are used in many security contexts. For example, authentication usually involves comparing two tokens, and one or both of those tokens might be text; thus, some methods of comparison might involve using some of the internationalization concepts for which terms are defined in this document.
本文件不直接讨论安全性。虽然这里的定义对安全性没有直接影响，但它们被用于许多安全上下文中。例如，身份验证通常涉及比较两个令牌，其中一个或两个令牌可能是文本；因此，一些比较方法可能涉及使用本文档中定义的一些国际化概念。
Having said that, other RFCs dealing with internationalization have security consideration descriptions that may be useful to the reader of this document. In particular, the security considerations in RFC 3454, RFC 3629, RFC 4013 [RFC4013], and RFC 5890 go into a fair amount of detail.
话虽如此，其他涉及国际化的RFC都有安全考虑说明，这些说明可能对本文档的读者有用。特别是，RFC 3454、RFC 3629、RFC 4013[RFC4013]和RFC 5890中的安全注意事项非常详细。
[ISOIEC10646] ISO/IEC, "ISO/IEC 10646:2011. International Standard -- Information technology - Universal Multiple-Octet Coded Character Set (UCS)", 2011.
[ISOIEC10646]ISO/IEC，“ISO/IEC10646:2011.国际标准——信息技术——通用多八位编码字符集（UCS）”，2011年。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.0", (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6). <http://www.unicode.org/versions/Unicode6.0.0/>.
[UNICODE]UNICODE联盟，“UNICODE标准，版本6.0”（加利福尼亚州山景城：UNICODE联盟，2011年，ISBN 978-1-936213-01-6）<http://www.unicode.org/versions/Unicode6.0.0/>.
[CHARMOD] W3C, "Character Model for the World Wide Web 1.0", 2005, <http://www.w3.org/TR/charmod/>.
[CHARMOD]W3C，“万维网1.0的字符模型”，2005年<http://www.w3.org/TR/charmod/>.
[FRAMEWORK] ISO/IEC, "ISO/IEC TR 11017:1997(E). Information technology - Framework for internationalization, prepared by ISO/IEC JTC 1/SC 22/WG 20", 1997.
[框架]ISO/IEC，“ISO/IEC TR 11017:1997（E）.信息技术-国际化框架，由ISO/IEC JTC 1/SC 22/WG 20编制”，1997年。
[ISO3166] ISO, "ISO 3166-1:2006 - Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", 2006.
[ISO3166]ISO，“ISO 3166-1:2006——国家及其分支机构名称表示代码——第1部分：国家代码”，2006年。
[ISO639] ISO, "ISO 639-1:2002 - Code for the representation of names of languages - Part 1: Alpha-2 code", 2002.
[ISO639]ISO，“ISO 639-1:2002-语言名称表示代码-第1部分：Alpha-2代码”，2002年。
[ISO6429] ISO/IEC, "ISO/IEC, "ISO/IEC 6429:1992. Information technology -- Control functions for coded character sets"", ISO/IEC 6429:1992, 1992.
[ISO6429]ISO/IEC，“ISO/IEC”，ISO/IEC 6429:1992。信息技术编码字符集的控制功能，ISO/IEC 6429:1992，1992。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952]Harrenstien，K.，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC 952，1985年10月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，2000年10月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]Hoffman，P.和M.Blanchet，“Nameprep：国际化域名（IDN）的Stringprep配置文件”，RFC 3491，2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, April 2004.
[RFC3743]Konishi，K.，Huang，K.，Qian，H.，和Y.Ko，“中国，日本和韩国的国际域名（IDN）注册和管理联合工程团队（JET）指南”，RFC 37432004年4月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]Phillips，A.和M.Davis，“语言标记的匹配”，BCP 47，RFC 4647，2006年9月。
[RFC4713] Lee, X., Mao, W., Chen, E., Hsu, N., and J. Klensin, "Registration and Administration Recommendations for Chinese Domain Names", RFC 4713, October 2006.
[RFC4713]Lee，X.，Mao，W.，Chen，E.，Hsu，N.，和J.Klensin，“中文域名的注册和管理建议”，RFC 4713，2006年10月。
[RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", BCP 137, RFC 5137, February 2008.
[RFC5137]Klensin，J.，“Unicode字符的ASCII转义”，BCP 137，RFC 5137，2008年2月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892]Faltstrom，P.，“Unicode代码点和应用程序的国际化域名（IDNA）”，RFC 58922010年8月。
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010.
[RFC5895]Resnick，P.和P.Hoffman，“应用程序中国际化域名的映射字符（IDNA）2008”，RFC 58952010年9月。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055]Thaler，D.，Klensin，J.，和S.Cheshire，“IAB对国际化域名编码的思考”，RFC 60552011年2月。
[UAX34] The Unicode Consortium, "Unicode Standard Annex #34: Unicode Named Character Sequences", 2010, <http://www.unicode.org/reports/tr34>.
[UAX34]Unicode联盟，“Unicode标准附录34：Unicode命名字符序列”，2010年<http://www.unicode.org/reports/tr34>.
[UAX9] The Unicode Consortium, "Unicode Standard Annex #9: Unicode Bidirectional Algorithm", 2010, <http://www.unicode.org/reports/tr9>.
[UAX9]Unicode联盟，“Unicode标准附录#9:Unicode双向算法”，2010年<http://www.unicode.org/reports/tr9>.
[US-ASCII] ANSI, "Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986", 1986.
[US-ASCII]ANSI，“编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986”，1986年。
[UTN6] The Unicode Consortium, "Unicode Technical Note #5: BOCU-1: MIME-Compatible Unicode Compression", 2006, <http://www.unicode.org/notes/tn6/>.
[UTN6]Unicode联盟，“Unicode技术说明#5:BOCU-1:MIME兼容Unicode压缩”，2006年<http://www.unicode.org/notes/tn6/>.
[UTR15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2010, <http://www.unicode.org/reports/tr15>.
[UTR15]Unicode联盟，“Unicode标准附录#15：Unicode规范化格式”，2010年<http://www.unicode.org/reports/tr15>.
[UTR18] The Unicode Consortium, "Unicode Standard Annex #18: Unicode Regular Expressions", 2008, <http://www.unicode.org/reports/tr18>.
[UTR18]Unicode联盟，“Unicode标准附录#18:Unicode正则表达式”，2008年<http://www.unicode.org/reports/tr18>.
[UTR22] The Unicode Consortium, "Unicode Technical Standard #22: Unicode Character Mapping Markup Language", 2009, <http://www.unicode.org/reports/tr22>.
[UTR22]Unicode联盟，“Unicode技术标准#22:Unicode字符映射标记语言”，2009年<http://www.unicode.org/reports/tr22>.
[UTR6] The Unicode Consortium, "Unicode Technical Standard #6: A Standard Compression Scheme for Unicode", 2005, <http://www.unicode.org/reports/tr6>.
[UTR6]Unicode联盟，“Unicode技术标准#6：Unicode的标准压缩方案”，2005年<http://www.unicode.org/reports/tr6>.
[W3C-i18n-Def] W3C, "Localization vs. Internationalization", September 2010, <http://www.w3.org/International/ questions/qa-i18n.en>.
[W3C-i18n-Def]W3C，“本地化与国际化”，2010年9月<http://www.w3.org/International/ 问题/qa-i18n.en>。
Barry, Randall, ed. ALA-LC Romanization Tables. Washington: U.S. Library of Congress, 1997. ISBN 0844409405
Barry，Randall，ed.ALA-LC罗马化表。华盛顿：美国国会图书馆，1997年。ISBN 0844409405
Coulmas, Florian. Blackwell Encyclopedia of Writing Systems. Oxford: Blackwell Publishers, 1999. ISBN 063121481X
弗洛里安，库尔马斯。布莱克威尔写作系统百科全书。牛津：布莱克威尔出版社，1999年。ISBN 063121481X
Dalby, Andrew. Dictionary of Languages: The Definitive Reference to More than 400 Languages. New York: Columbia University Press, 2004. ISBN 978-0231115698
戴比，安德鲁。语言词典：对400多种语言的权威参考。纽约：哥伦比亚大学出版社，2004年。ISBN 978-0231115698
Daniels, Peter, and William Bright. The World's Writing Systems. New York: Oxford University Press, 1996. ISBN 0195079930
丹尼尔斯、彼得和威廉·布莱特。世界的书写系统。纽约：牛津大学出版社，1996年。ISBN 0195079930
DeFrancis, John. The Chinese Language: Fact and Fantasy. Honolulu: University of Hawaii Press, 1984. ISBN 0-8284-085505 and 0-8248-1058-6
德弗兰西斯，约翰。中文：事实与幻想。火奴鲁鲁：夏威夷大学出版社，1984。ISBN 0-8284-085505和0-8248-1058-6
Drucker, Joanna. The Alphabetic Labyrinth: The Letters in History and Imagination. London: Thames & Hudson, 1995. ISBN 0-500-28068-1
德鲁克，乔安娜。字母迷宫：历史和想象中的字母。伦敦：泰晤士河和哈德逊河，1995年。ISBN 0-500-28068-1
Fazzioli, Edoardo. Chinese Calligraphy. New York: Abbeville Press, 1986, 1987 (English translation). ISBN 0-89659-774-1
法齐奥利，埃多尔多。中国书法。纽约：艾比维尔出版社，1986年，1987年（英译）。ISBN 0-89659-774-1
Hooker, J.T., et al. Reading the Past: Ancient Writing from Cuneiform to the Alphabet. London: British Museum Press, 1990. ISBN 0-7141-8077-7
胡克，J.T.等人，《阅读过去：从楔形文字到字母表的古代书写》。伦敦：大英博物馆出版社，1990年。ISBN 0-7141-8077-7
Lunde, Ken. CJKV Information Processing. Sebastopol, CA: O'Reilly & Assoc., 1999. ISBN 1-56592-224-7
伦德，肯。CJKV信息处理。塞巴斯托波尔，加利福尼亚州：O'Reilly&Assoc.，1999年。ISBN 1-56592-224-7
Nakanishi, Akira. Writing Systems of the World. Rutland, VT: Charles E. Tuttle Company, 1980. ISBN 0804816549
中山昭一。世界的书写系统。佛蒙特州拉特兰：查尔斯·E·塔特尔公司，1980年。ISBN 0804816549
Robinson, Andrew. The Story of Writing: Alphabets, Hieroglyphs, & Pictograms. London: Thames & Hudson, 1995, 2000. ISBN 0-500-28156-4
安德鲁·罗宾逊。书写的故事：字母、象形文字和象形图。伦敦：泰晤士河和哈德逊河，1995年，2000年。ISBN 0-500-28156-4
Sacks, David. Language Visible. New York: Broadway Books (a division of Random House, Inc.), 2003. ISBN 0-7679-1172-5
萨克斯，大卫。语言可见。纽约：百老汇图书（兰登书屋公司的一个部门），2003年。ISBN 0-7679-1172-5
The definitions in this document come from many sources, including a wide variety of IETF documents.
本文件中的定义来自许多来源，包括各种IETF文件。
James Seng contributed to the initial outline of RFC 3536. Harald Alvestrand and Martin Duerst made extensive useful comments on early versions. Others who contributed to the development of RFC 3536 include Dan Kohn, Jacob Palme, Johan van Wingen, Peter Constable, Yuri Demchenko, Susan Harris, Zita Wenzel, John Klensin, Henning Schulzrinne, Leslie Daigle, Markus Scherer, and Ken Whistler.
James Seng对RFC 3536的初始大纲做出了贡献。哈拉尔德·阿尔韦斯特朗和马丁·杜尔斯特对早期版本作了大量有益的评论。其他对RFC3536的开发做出贡献的人包括丹·科恩、雅各布·帕尔梅、约翰·范文根、彼得·康斯特布尔、尤里·德姆琴科、苏珊·哈里斯、齐塔·温泽尔、约翰·克莱辛、亨宁·舒尔兹林内、莱斯利·戴格尔、马库斯·谢勒和肯·惠斯勒。
Abdulaziz Al-Zoman, Tim Bray, Frank Ellermann, Antonio Marko, JFC Morphin, Sarmad Hussain, Mykyta Yevstifeyev, Ken Whistler, and others identified important issues with, or made specific suggestions for, this new version.
Abdulaziz Al-Zoman、Tim Bray、Frank Ellermann、Antonio Marko、JFC Morpin、Sarmad Hussain、Mykyta Yevstifeyev、Ken Whistler和其他人确定了新版本的重要问题，或提出了具体建议。
This document mostly consists of additions to RFC 3536. The following is a list of the most significant changes.
本文件主要包括对RFC 3536的补充。以下是最重要的变化列表。
o Changed the document's status to BCP.
o 将文档的状态更改为BCP。
o Commonly used synonyms added to several descriptions and indexed.
o 添加到多个描述和索引中的常用同义词。
o A list of terms defined and used in IDNA2008 was added, with a pointer to RFC 5890. Those definitions have not been repeated in this document.
o 添加了IDNA2008中定义和使用的术语列表，并带有指向RFC 5890的指针。这些定义在本文件中没有重复。
o The much-abused term "variant" is now discussed in some detail.
o 现在详细讨论了被滥用的“变体”一词。
o A discussion of different subsets of the Unicode repertoire was added as Section 4.2 and associated definitions were included.
o 第4.2节增加了对Unicode指令集不同子集的讨论，并包括相关定义。
o Added a new term, "writing style".
o 增加了一个新术语“写作风格”。
o Discussions of case-folding and mapping were expanded.
o 扩大了对案例折叠和映射的讨论。
o Minor edits were made to some section titles and a number of other editorial improvements were made.
o 对一些章节标题进行了小的编辑，并对其他一些编辑进行了改进。
o The discussion of control codes was updated to include additional information and clarify that "control code" and "control character" are synonyms.
o 对控制代码的讨论进行了更新，以包括其他信息，并澄清“控制代码”和“控制字符”是同义词。
o Many terms were clarified to reflect contemporary usage.
o 许多术语被澄清以反映当代用法。
o The index to terms by section in RFC 3536 was replaced by an index to pages containing considerably more terms.
o RFC 3536中的条款索引被包含更多条款的页面索引所取代。
o The acknowledgments were updated.
o 确认已更新。
o Some of the references were updated.
o 一些参考资料已更新。
o The supplemental reading list was expanded somewhat.
o 补充阅读清单有所扩大。
Index
指数
A A-label 31 ACE 30, 31 ACE Prefix 31 alphabetic 20 ANSI 13 ASCII 15 ASCII-compatible encoding 30, 31 ASN.1 text formats 30
A标签31 ACE 30，31 ACE前缀31字母20 ANSI 13 ASCII 15 ASCII兼容编码30，31 ASN.1文本格式30
B Base64 29 Basic Multilingual Plane 13 bidi 26 bidirectional display 26 BMP 13 BMPString 30 BOCU-1 14 BOM 14 byte order mark 14
B Base64 29基本多语言平面13 bidi 26双向显示26 BMP 13 BMP字符串30 BOCU-1 14 BOM 14字节顺序标记14
C C-T-E 29 case 18 CCS 7 CEN/ISSS 13 character 6 character encoding form 7 character encoding scheme 8 character repertoire 7 charset 8 charset identification 28 CJK characters 34 code chart 19 code point 16 code table 19 coded character 6
C C-T-E 29案例18 CCS 7 CEN/ISSS 13字符6字符编码表7字符编码方案8字符表7字符集8字符集识别28 CJK字符34代码表19代码点16代码表19编码字符6
coded character set 7 collation 18 combining character 16 combining character sequence 16 compatibility character 22 compatibility variant 22 composite sequence 16 content-transfer-encoding 29 control character 21 control code 21 control sequence 22
编码字符集7排序规则18组合字符16组合字符序列16兼容字符22兼容变体22复合序列16内容传输编码29控制字符21控制代码21控制序列22
D decomposed character 16 diacritic 21 displaying and rendering text 10 Domain Name Slot 31
D分解字符16变音符号21显示和呈现文本10域名插槽31
E encoding forms 13
E编码表格13
F font 25 formatting character 22
F字体25格式字符22
G glyph 7 glyph code 7 graphic symbol 25
G字形7字形代码7图形符号25
H Han characters 34
H汉字34
I i18n 9 IA5String 30 ideographic 20 IDN 31 IDNA 31 IDNA-valid string 31 IDNA2003 31 IDNA2008 31 IME 24 input method editor 24 input methods 24 internationalization 8 Internationalized Domain Name 31 Internationalized Label 31
I i18n 9 IA5String 30表意文字20 IDN 31 IDNA 31 IDNA有效字符串31 IDNA2003 31 IDNA2008 31 IME 24输入法编辑器24输入法24国际化8国际化域名31国际化标签31
ISO 11 ISO 639 11 ISO 3166 11 ISO 8859 15 ISO TC 46 11
ISO 11 ISO 639 11 ISO 3166 11 ISO 8859 15 ISO TC 46 11
J JIS 13 JTC 1 11
J JIS 13 JTC 1 11
L l10n 9 language 5 language identification 29 Latin characters 34 LDH Label 30 letters 23 Local and regional standards organizations 13 locale 33 localization 9
L l10n 9语言5语言识别29个拉丁字符34个LDH标签30个字母23个地方和地区标准组织13个地区33本地化9
M MIME 29 multilingual 10
M MIME 29多语言10
N name spaces 28 Nameprep 31 NFC 17 NFD 17 NFKC 17 NFKD 17 non-ASCII 23 nonspacing character 21 normalization 17 NR-LDH label 31 NVT 15
N名称空间28 Nameprep 31 NFC 17 NFD 17 NFKC 17 NFKD 17非ASCII 23非空格字符21规范化17 NR-LDH标签31 NVT 15
O on-the-wire encoding 28
O导线上的编码28
P parsed text 28 precomposed character 16 PrintableString 30 private use charater 36 protocol elements 27 punctuation 21 Punycode 30, 31
P解析文本28预合成字符16可打印字符串30专用字符36协议元素27标点21 Punycode 30，31
Q quoted-printable 29
Q引用可打印29
R regular expressions 36 rendering rules 24 repertoire 7 romanization 34
R正则表达式36呈现规则24曲目7罗马化34
S SAC 13 script 5 SCSU 14 sorting 18 Stringprep 31 surrogate pair 14 symbol 21
S SAC 13脚本5 SCSU 14排序18 Stringprep 31代理项对14符号21
T T61String 30 TeletexString 30 TES 29 transcoding 7 transcription 35 transfer encoding syntax 29 transformation formats 13 translation 35 transliteration 34, 35 typeface 25
T T61字符串30电传字符串30 TES 29转码7转录35传输编码语法29转换格式13翻译35音译34，35字体25
U U-label 31 UCS-2 13 UCS-4 13 undisplayable character 26 Unicode Consortium 12 US-ASCII 15 UTC 12 UTF-8 14
U-label 31 UCS-2 13 UCS-4 13不可扩展字符26 Unicode联合体12 US-ASCII 15 UTC 12 UTF-8 14
UTF-16 14 UTF-16BE 14 UTF-16LE 14 UTF-32 14 UTF8String 30
UTF-16 14 UTF-16BE 14 UTF-16LE 14 UTF-32 14 UTF字符串30
V variant 32
V变式32
W W3C 13 World Wide Web Consortium 13 writing style 27 writing system 6
W W3C 13万维网联盟13书写风格27书写系统6
X XML 13, 30
xxml13,30
Authors' Addresses
作者地址
Paul Hoffman VPN Consortium
保罗·霍夫曼VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥322号马萨诸塞大道1770号约翰·C·克伦辛邮编：02140
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
Phone: +1 617 245 1457
EMail: john+ietf@jck.com