Internet Engineering Task Force (IETF) M. Davis
Request for Comments: 6067 Google
Category: Informational A. Phillips
ISSN: 2070-1721 Lab126
Y. Umaoka
IBM
December 2010
Internet Engineering Task Force (IETF) M. Davis
Request for Comments: 6067 Google
Category: Informational A. Phillips
ISSN: 2070-1721 Lab126
Y. Umaoka
IBM
December 2010
BCP 47 Extension U
BCP 47扩展U
Abstract
摘要
This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium.
本文档指定了BCP 47的扩展，该扩展提供了子标签，根据Unicode联盟所做的工作，这些子标签指定了基于语言和/或区域设置的行为或对语言标签的改进。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc6067.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6067.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 2
2. BCP 47 Required Information . . . . . . . . . . . . . . . . . . 2
2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Canonicalization . . . . . . . . . . . . . . . . . . . 5
2.2. Registration Form . . . . . . . . . . . . . . . . . . . . . 6
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 2
2. BCP 47 Required Information . . . . . . . . . . . . . . . . . . 2
2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Canonicalization . . . . . . . . . . . . . . . . . . . 5
2.2. Registration Form . . . . . . . . . . . . . . . . . . . . . 6
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
[BCP47] permits the definition and registration of language tag extensions "that contain a language component and are compatible with applications that understand language tags". This document defines an extension for identifying Unicode locale-based variations using language tags. The "singleton" identifier for this extension is 'u'.
[BCP47]允许定义和注册“包含语言组件且与理解语言标记的应用程序兼容”的语言标记扩展。本文档定义了一个扩展，用于使用语言标记识别基于Unicode语言环境的变体。此扩展的“单例”标识符为“u”。
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]中所述进行解释。
Language tags, as defined by [BCP47], are useful for identifying the language of content. They are also used as locale identifiers (or can be mapped to locales) in many operating environments and APIs. However, many locale identifiers also require additional "tailorings" or options for specific values within a language, culture, region, or other variation. This extension provides a mechanism for using these additional tailorings within language tags for general interchange.
[BCP47]定义的语言标记可用于标识内容的语言。在许多操作环境和API中，它们还用作区域设置标识符（或可以映射到区域设置）。但是，许多语言环境标识符还需要额外的“tailoring”或用于语言、区域性、区域或其他变体中特定值的选项。此扩展提供了一种机制，用于在语言标记中使用这些附加的tailoring进行一般交换。
The Unicode Consortium defines a standardized, structured set of locale data and identifiers for locale data in the "Common Locale Data Repository" or "CLDR". The maintaining authority for the extension defined by this document is the Unicode Consortium:
Unicode联盟在“公共语言环境数据存储库”或“CLDR”中为语言环境数据定义了一组标准化、结构化的语言环境数据和标识符。本文件定义的扩展的维护机构为Unicode联盟：
+---------------+---------------------------------------------------+
| Item | Value |
+---------------+---------------------------------------------------+
| Name | Unicode Consortium |
| Contact Email | cldr-contact@unicode.org |
| Discussion | cldr-users@unicode.org |
| List Email | |
| URL Location | cldr.unicode.org |
| Specification | Unicode Technical Standard #35 Unicode Locale |
| | Data Markup Language (LDML), |
| | http://unicode.org/reports/tr35/ |
| Section | Section 3 Unicode Language and Locale Identifiers |
+---------------+---------------------------------------------------+
+---------------+---------------------------------------------------+
| Item | Value |
+---------------+---------------------------------------------------+
| Name | Unicode Consortium |
| Contact Email | cldr-contact@unicode.org |
| Discussion | cldr-users@unicode.org |
| List Email | |
| URL Location | cldr.unicode.org |
| Specification | Unicode Technical Standard #35 Unicode Locale |
| | Data Markup Language (LDML), |
| | http://unicode.org/reports/tr35/ |
| Section | Section 3 Unicode Language and Locale Identifiers |
+---------------+---------------------------------------------------+
The specification of extension subtags is provided by Section 3, Key Type Definitions of Unicode Technical Standard #35: Unicode Locale Data Markup Language [UTS35]. As required by BCP 47, subtags follow the language tag ABNF and other rules for the formation of language tags and subtags, are restricted to the ASCII letters and digits, are not case sensitive, and do not exceed eight characters in length. Note that any "well-formed" language tag (see RFC 5646, Section 2.2.9 [BCP47]) is also a well-formed locale identifier.
第3节“Unicode技术标准#35:Unicode区域设置数据标记语言[UTS35]的键类型定义”提供了扩展子标记的规范。根据BCP 47的要求，子标签遵循语言标签ABNF和其他形成语言标签和子标签的规则，仅限于ASCII字母和数字，不区分大小写，长度不超过8个字符。请注意，任何“格式良好”的语言标记（参见RFC 5646，第2.2.9节[BCP47]）也是格式良好的区域设置标识符。
LDML [UTS35] specifies a canonical representation. LDML is available over the Internet and at no cost, and is available via a royalty-free license at http://unicode.org/copyright.html. LDML is versioned, and each version of LDML is numbered, dated, and stable. Extension subtags, once defined by LDML, are never retracted and never change in meaning in a substantial way.
LDML[UTS35]指定规范表示。LDML可通过互联网免费获得，并可通过以下网站获得免版税许可证：http://unicode.org/copyright.html. LDML是版本化的，并且LDML的每个版本都是编号、日期和稳定的。一旦LDML定义了扩展子标签，扩展子标签就不会被收回，也不会以实质性的方式改变其含义。
The structure of the Unicode locale extension is determined by the Unicode CLDR Technical Committee, in accordance with the policies and procedures in http://www.unicode.org/consortium/tc-procedures.html, and subject to the Unicode Consortium Policies on http://www.unicode.org/policies/policies.html.
Unicode语言环境扩展的结构由Unicode CLDR技术委员会根据http://www.unicode.org/consortium/tc-procedures.html，并受http://www.unicode.org/policies/policies.html.
Changes that can be made by successive versions of LDML [UTS35] by the Unicode Consortium without requiring a new RFC include: the allocation of new attributes, keywords, and types; clarifications or non-material changes to an existing attribute, keyword, or type; and compatible extensions to the overall syntactic structure of attributes, keywords, and types. A new RFC would be required for material changes to an existing attribute, keyword, or type, or an incompatible change to the overall syntactic structure of attributes, keywords, and types; however, such a change would be contrary to the policies of the Unicode Consortium, and thus is not anticipated.
Unicode Consortium连续版本的LDML[UTS35]可以在不需要新RFC的情况下进行更改，包括：分配新属性、关键字和类型；对现有属性、关键字或类型的澄清或非实质性更改；以及对属性、关键字和类型的整体语法结构的兼容扩展。对现有属性、关键字或类型进行重大更改，或对属性、关键字和类型的整体语法结构进行不兼容的更改，都需要新的RFC；然而，这样的改变将与Unicode联盟的政策相违背，因此不在预料之中。
The subtags available for use in the 'u' extension consist of a set of attributes, keys, and types. Attributes, keys, types, and their respective meanings are defined in Section 3 (Unicode Language and Locale Identifiers) of [UTS35]. The following is a summary of that definition:
“u”扩展中可用的子标签由一组属性、键和类型组成。[UTS35]第3节（Unicode语言和区域设置标识符）中定义了属性、键、类型及其各自的含义。以下是该定义的摘要：
o An 'attribute' is a subtag with a length of three to eight characters following the singleton and preceding any 'keyword' sequences. No attributes were defined at the time of this document's publication.
o “属性”是一个子标记，其长度为三到八个字符，紧跟在单例之后，紧跟在任何“关键字”序列之前。本文档发布时未定义任何属性。
o A 'keyword' is a sequence of subtags consisting of a 'key' subtag, followed by zero or more 'type' subtags (so a 'key' might appear alone and not be accompanied by a 'type' subtag). A 'key' MUST NOT appear more than once in a language tag's extension string. The order of the 'type' subtags within a 'keyword' is sometimes significant to their interpretation.
o “关键字”是一系列子标记，由“键”子标记组成，后跟零个或多个“类型”子标记（因此“键”可能单独出现，而不伴有“类型”子标记）。“键”在语言标记的扩展字符串中不得出现多次。“关键字”中“类型”子标签的顺序有时对它们的解释很重要。
A. A 'key' is a subtag with a length of exactly two characters. Each 'key' is followed by zero or more 'type' subtags.
A.“键”是长度正好为两个字符的子标记。每个“键”后面都有零个或多个“类型”子标记。
B. A 'type' is a subtag with a length of three to eight characters following a 'key'. 'Type' subtags are specific to a particular 'key' and the order of the 'type' subtags MAY be significant to the interpretation of the 'keyword'.
B.“类型”是一个子标记，在“键”后面有三到八个字符“类型”子标签特定于特定的“键”，“类型”子标签的顺序可能对“关键字”的解释有重要意义。
For example, the language tag "de-DE-u-attr-co-phonebk" consists of:
例如，语言标签“de-de-u-attr-co-phonebk”包括：
o The base language tag "de-DE" (German as used in Germany), exactly as defined by [BCP47] using subtags from the IANA Language Subtag Registry.
o 基本语言标记“de de”（德语，在德国使用），完全由[BCP47]使用IANA语言子标记注册表中的子标记定义。
o The singleton 'u', identifying this extension.
o 标识此扩展的单例“u”。
o The attribute 'attr', which is an example for illustration (no attributes were defined at the time this document was published).
o 属性“attr”，这是一个示例（本文档发布时未定义任何属性）。
o The keyword 'co-phonebk', consisting to the key 'co' (Collation) and the type 'phonebk' (Phonebook collation order).
o 关键字“co phonebk”，由键“co”（排序）和类型“phonebk”（电话簿排序顺序）组成。
Only the first occurrence of an attribute or key conveys meaning in a language tag. When interpreting tags containing the Unicode locale extension, duplicate attributes or keywords are ignored in the following way: ignore any attribute that has already appeared in the tag and ignore any keyword whose key has already occurred in the tag.
只有属性或键的第一次出现才能传达语言标记中的含义。在解释包含Unicode区域设置扩展的标记时，重复的属性或关键字将按以下方式被忽略：忽略标记中已出现的任何属性，忽略标记中已出现其关键字的任何关键字。
Successive versions of [UTS35] could define additional attributes, keys, and types. Once defined, attributes, keys, and types will never be removed.
[UTS35]的后续版本可以定义其他属性、键和类型。一旦定义，属性、键和类型将永远不会被删除。
Beginning with CLDR version 1.7.2, machine-readable files are available listing the valid attributes, keys, and types for each successive version of [UTS35]. These releases are listed on http://cldr.unicode.org/index/downloads. Each release has an associated data directory of the form "http://unicode.org/Public/cldr/<version>", where "<version>" is replaced by the release number. For example, for version 1.7.2, the "core.zip" file is located at http://unicode.org/Public/cldr/1.7.2/core.zip. Inside the "core.zip" file, the path "common/bcp47" contains the data files defining the valid attributes, keys, and types. The most recent version is always identified by the version "latest" and can be accessed by the URL in Section 2.2.
从CLDR版本1.7.2开始，可以使用机器可读文件，列出[UTS35]每个后续版本的有效属性、键和类型。这些版本列在http://cldr.unicode.org/index/downloads. 每个版本都有一个关联的数据目录，格式为“http://unicode.org/Public/cldr/<version>”，其中“<version>”替换为发行号。例如，对于版本1.7.2，“core.zip”文件位于http://unicode.org/Public/cldr/1.7.2/core.zip. 在“core.zip”文件中，路径“common/bcp47”包含定义有效属性、键和类型的数据文件。最新版本始终由“最新”版本标识，可通过第2.2节中的URL访问。
To get the version information in XML when working with the data files, the XML parser must be validating. When the 'core.zip' file is unzipped, the 'dtd' directory will be at the same level as the 'bcp47' directory; this is required for correct validation. For each release after CLDR 1.8, types introduced in that release are also marked in the data files by the XML attribute "since", such as in the following example: <type name="adp" since="1.9"/>
要在处理数据文件时获得XML版本信息，XML解析器必须进行验证。解压“core.zip”文件时，“dtd”目录将与“bcp47”目录处于同一级别；这是正确验证所必需的。对于CLDR 1.8之后的每个版本，在该版本中引入的类型也会在数据文件中用XML属性“begin”标记，例如在下面的示例中：<type name=“adp”begin=“1.9”/
The data is also currently maintained in a source code repository, with each release tagged, for viewing directly without unzipping. For example, see:
数据目前也保存在源代码存储库中，每个版本都有标记，以便在不解压缩的情况下直接查看。例如，请参见：
o http://unicode.org/repos/cldr/tags/release-1-7-2/common/bcp47/
o http://unicode.org/repos/cldr/tags/release-1-7-2/common/bcp47/
o http://unicode.org/repos/cldr/tags/release-1-8/common/bcp47/
o http://unicode.org/repos/cldr/tags/release-1-8/common/bcp47/
Some data in the CLDR data files might require reference to LDML [UTS35]. For specific information, see Appendix Q in that document. For example, LDML reserves the type 'codepoints' to define specific code point ranges in Unicode for specific purposes.
CLDR数据文件中的某些数据可能需要引用LDML[UTS35]。有关具体信息，请参见该文件中的附录Q。例如，LDML保留“codepoints”类型，以便在Unicode中为特定目的定义特定的代码点范围。
As required by [BCP47], the use of uppercase or lowercase letters is not significant in the subtags used in this extension. The canonical form for all subtags in the extension is lowercase. The canonical order of attributes is in [US-ASCII] order (that is, numbers before letters, with letters sorted as lowercase US-ASCII code points). The canonical order of keywords is in [US-ASCII] order by key. The order
根据[BCP47]的要求，在本扩展中使用的子标签中，大写或小写字母的使用并不重要。扩展中所有子标签的规范形式都是小写的。属性的规范顺序为[US-ASCII]顺序（即字母前的数字，字母按小写US-ASCII码点排序）。关键字的规范顺序是按键的[US-ASCII]顺序。命令
of subtags within a keyword is significant; the meaning of this extension is altered if those subtags are rearranged. Thus, the canonical form of the extension never reorders the subtags within a keyword.
关键字中子标签的数量是重要的；如果这些子标签被重新排列，则此扩展的含义将改变。因此，扩展的规范形式永远不会对关键字中的子标签重新排序。
Per RFC 5646, Section 3.7 [BCP47]:
根据RFC 5646第3.7节[BCP47]：
%%
Identifier: u
Description: Unicode Locale
Comments: Subtags for the identification of language and cultural
variations. Used to set behavior in locale APIs. Data is
located in the "common/bcp47" directory inside the referenced
URL. Unicode Technical Standard #35 (LDML) provides additional
reference material defining the keys and values.
For more details please see
<http://cldr.unicode.org/index/bcp47-extension>.
Added: 2010-09-02
RFC: RFC 6067
Authority: Unicode Consortium
Contact_Email: cldr-contact@unicode.org
Mailing_List: cldr-users@unicode.org
URL: http://www.unicode.org/Public/cldr/latest/core.zip
%%
%%
Identifier: u
Description: Unicode Locale
Comments: Subtags for the identification of language and cultural
variations. Used to set behavior in locale APIs. Data is
located in the "common/bcp47" directory inside the referenced
URL. Unicode Technical Standard #35 (LDML) provides additional
reference material defining the keys and values.
For more details please see
<http://cldr.unicode.org/index/bcp47-extension>.
Added: 2010-09-02
RFC: RFC 6067
Authority: Unicode Consortium
Contact_Email: cldr-contact@unicode.org
Mailing_List: cldr-users@unicode.org
URL: http://www.unicode.org/Public/cldr/latest/core.zip
%%
Thanks to John Emmons and the rest of the Unicode CLDR Technical Committee for their work in developing the BCP 47 subtags for LDML.
感谢John Emmons和Unicode CLDR技术委员会的其他成员为LDML开发BCP 47子标签所做的工作。
Thanks also to Doug Ewell, for his many suggestions for improvements to this document.
还要感谢Doug Ewell对本文档提出了许多改进建议。
According to this document, IANA has inserted the record in Section 2.2 into the Language Extensions Registry, according to Section 3.7 (Extensions and the Extensions Registry) of [BCP47], "Tags for Identifying Languages". Per Section 5.2 of [BCP47], there might be occasional (rare) requests by the Unicode Consortium (the "Authority" listed in the record) for maintenance of this record. Changes that can be submitted to IANA without the publication of a new RFC are limited to modification of the Comments, Contact_Email, Mailing_List, and URL fields. Any such requested changes MUST use the domain 'unicode.org' in any new addresses or URIs, MUST explicitly cite this document (so that IANA can reference these
根据本文件，IANA已根据[BCP47]“识别语言的标记”第3.7节（扩展和扩展注册表）将第2.2节中的记录插入语言扩展注册表。根据[BCP47]第5.2节，Unicode联盟（记录中列出的“机构”）可能会偶尔（罕见）要求维护该记录。在不发布新RFC的情况下，可以提交给IANA的更改仅限于修改注释、联系人电子邮件、邮件列表和URL字段。任何此类请求的更改必须在任何新地址或URI中使用域“unicode.org”，并且必须明确引用此文档（以便IANA可以引用这些
requirements), and MUST originate from the 'unicode.org' domain. The domain or authority can only be changed via a new RFC.
要求），并且必须来自“unicode.org”域。只能通过新的RFC更改域或权限。
The security considerations for this extension are the same as those for [BCP47]. See RFC 5646, Section 6, Security Considerations [BCP47].
此扩展的安全注意事项与[BCP47]的安全注意事项相同。见RFC 5646，第6节，安全注意事项[BCP47]。
[BCP47] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[BCP47]Phillips，A.，Ed.和M.Davis，Ed.，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[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月。
[US-ASCII] International Organization for Standardization, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991.
[US-ASCII]国际标准化组织，“ISO/IEC 646:1991，信息技术——信息交换用ISO 7位编码字符集”，1991年。
[UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data Markup Language (LDML)", December 2007, <http://www.unicode.org/reports/tr35/>.
[UTS35]Davis，M.“Unicode技术标准#35：语言环境数据标记语言（LDML）”，2007年12月<http://www.unicode.org/reports/tr35/>.
Section 3: http://unicode.org/reports/
tr35/#Unicode_Language_and_Locale_Identifiers
Section 3: http://unicode.org/reports/
tr35/#Unicode_Language_and_Locale_Identifiers
Appendix Q: http://unicode.org/reports/
tr35/#Locale_Extension_Key_and_Type_Data
Appendix Q: http://unicode.org/reports/
tr35/#Locale_Extension_Key_and_Type_Data
[ldml-registry] "Registry for Common Locale Data Repository tag elements", September 2009.
[ldml注册表]“通用语言环境数据存储库标记元素注册表”，2009年9月。
Authors' Addresses
作者地址
Mark Davis Google
马克·戴维斯谷歌
EMail: mark@macchiato.com
EMail: mark@macchiato.com
Addison Phillips Lab126
艾迪生菲利普斯实验室126
EMail: addison@lab126.com
EMail: addison@lab126.com
Yoshito Umaoka IBM
宇冈吉人IBM
EMail: yoshito_umaoka@us.ibm.com
EMail: yoshito_umaoka@us.ibm.com