网络工作组 A. Phillips, Ed. 请求评议：5646 Lab126 BCP: 47 M. Davis, Ed. 废止：4646 Google 类别：最佳当前实践 2009 年 9 月 用于标识语言的标签 摘要 本文档描述了语言标签的结构、内容、构造和 语义，用于需要指明信息对象中所用语言的场景。 它还描述了如何注册可用于语言标签的值，以及 为私有交换创建用户定义扩展的方法。 本备忘录状态 本文档规定了一项面向 Internet 社区的 Internet 最佳当前实践， 并请求讨论和改进建议。本文档的分发不受限制。 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Phillips & Davis 最佳当前实践 [第 1 页]
RFC 5646 语言标签 2009 年 9 月 目录 1. 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 语言标签 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 语法 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. 语言标签的格式化 . . . . . . . . . . . . . . . . 6 2.2. 语言子标签来源与解释 . . . . . . . . . . . . . . . . 8 2.2.1. 主语言子标签 . . . . . . . . . . . . . . . . . . 9 2.2.2. 扩展语言子标签 . . . . . . . . . . . . . . . . 11 2.2.3. 文字子标签 . . . . . . . . . . . . . . . . . . 12 2.2.4. 区域子标签 . . . . . . . . . . . . . . . . . . 13 2.2.5. 变体子标签 . . . . . . . . . . . . . . . . . . 15 2.2.6. 扩展子标签 . . . . . . . . . . . . . . . . . . 16 2.2.7. 私用子标签 . . . . . . . . . . . . . . . . . . 18 2.2.8. 祖父项和冗余注册 . . . . . . . . . . . . . . . 18 2.2.9. 符合性类别 . . . . . . . . . . . . . . . . . . 19 3. 注册表格式与维护 . . . . . . . . . . . . . . . . . . . 21 3.1. IANA 语言子标签注册表的格式 . . . . . . . . . . . . 21 3.1.1. 文件格式 . . . . . . . . . . . . . . . . . . . 21 3.1.2. 记录和字段定义 . . . . . . . . . . . . . . . . . 23 3.1.3. Type 字段 . . . . . . . . . . . . . . . . . . . 26 3.1.4. Subtag 和 Tag 字段 . . . . . . . . . . . . . . 26 3.1.5. Description 字段 . . . . . . . . . . . . . . . 26 3.1.6. Deprecated 字段 . . . . . . . . . . . . . . . . 28 3.1.7. Preferred-Value 字段 . . . . . . . . . . . . . 28 3.1.8. Prefix 字段 . . . . . . . . . . . . . . . . . . 31 3.1.9. Suppress-Script 字段 . . . . . . . . . . . . . 32 3.1.10. Macrolanguage 字段 . . . . . . . . . . . . . . 32 3.1.11. Scope 字段 . . . . . . . . . . . . . . . . . . 33 3.1.12. Comments 字段 . . . . . . . . . . . . . . . . . 34 3.2. 语言子标签审查员 . . . . . . . . . . . . . . . . . 35 3.3. 注册表的维护 . . . . . . . . . . . . . . . . . . . 35 3.4. IANA 注册表项的稳定性 . . . . . . . . . . . . . . . 36 3.5. 子标签注册程序 . . . . . . . . . . . . . . . . . . 41 3.6. 可注册的可能事项 . . . . . . . . . . . . . . . . . 46 3.7. 扩展和扩展注册表 . . . . . . . . . . . . . . . . . 49 3.8. 语言子标签注册表的更新 . . . . . . . . . . . . . . 52 3.9. 子标签注册表的适用性 . . . . . . . . . . . . . . . 52 4. 语言标签的形成和处理 . . . . . . . . . . . . . . . . . 53 4.1. 语言标签的选择 . . . . . . . . . . . . . . . . . . 53 4.1.1. 标记被涵盖语言 . . . . . . . . . . . . . . . . 58 4.1.2. 使用扩展语言子标签 . . . . . . . . . . . . . . 59 4.2. 语言标签的含义 . . . . . . . . . . . . . . . . . 61 4.3. 语言列表 . . . . . . . . . . . . . . . . . . . . . 63 4.4. 长度考虑事项 . . . . . . . . . . . . . . . . . . 63 4.4.1. 使用有限缓冲区大小 . . . . . . . . . . . . . . 64 4.4.2. 语言标签的截断 . . . . . . . . . . . . . . . . 65 4.5. 语言标签的规范化 . . . . . . . . . . . . . . . . 66 Phillips & Davis 最佳当前实践 [第 2 页]
RFC 5646 语言标签 2009 年 9 月 4.6. 私用子标签考虑事项 . . . . . . . . . . . . . . . . . 68 5. IANA 考虑事项 . . . . . . . . . . . . . . . . . . . . 69 5.1. 语言子标签注册表 . . . . . . . . . . . . . . . . . 69 5.2. 扩展注册表 . . . . . . . . . . . . . . . . . . . 71 6. 安全考虑事项 . . . . . . . . . . . . . . . . . . . . 71 7. 字符集考虑事项 . . . . . . . . . . . . . . . . . . . . 72 8. 相对 RFC 4646 的变更 . . . . . . . . . . . . . . . . 73 9. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . 76 9.1. 规范性参考文献 . . . . . . . . . . . . . . . . . . 76 9.2. 资料性参考文献 . . . . . . . . . . . . . . . . . . 78 附录 A. 语言标签示例（资料性） . . . . . . . . . . . . . . 80 附录 B. 注册表单示例 . . . . . . . . . . . . . . . . . . 82 附录 C. 致谢 . . . . . . . . . . . . . . . . . . . . . . 83 1. 引言 地球上的人类，无论过去还是现在，都使用过许多种 语言。在呈现或请求信息时，人们有许多理由希望标识 所使用的语言。 信息项的语言或用户的语言偏好通常需要被标识，以便 应用适当的处理。例如，Web 浏览器中的用户语言偏好 可用于适当地选择 Web 页面。语言信息还可用于在各种 工具（例如词典）之间进行选择，以辅助处理或理解 不同语言的内容。了解某段信息内容所使用的特定语言， 对某些类型的处理可能有用，甚至可能是必需的，例如 拼写检查、计算机合成语音、盲文转写或高质量的打印 呈现。 表示所用语言的一种方法是用标识符或“标签”标记 信息内容。这些标签还可用于在选择信息内容时指定 用户偏好，或用于标记内容和相关资源的附加属性。 有时，语言标签用于表示内容的附加语言属性。例如， 指明文档或资源中所用方言、书写系统或正字法的特定 信息，可能使用户能够以其可以理解的形式获得信息， 或者在将给定内容处理或呈现为适当形式或样式时很 重要。 本文档规定了一种特定的标识符机制（语言标签）， 以及一个用于标签构成值的注册功能。 Phillips & Davis 最佳当前实践 [第 3 页]
RFC 5646 语言标签 2009 年 9 月 它还定义了私用值和未来扩展的机制。 本文档取代 [RFC4646]（后者废止了 [RFC3066]，而 [RFC3066] 又取代了 [RFC1766]）。本文档与 [RFC4647] 一起构成 BCP 47。关于本文档中的变更列表， 请参见第 8 节。 本文档中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、 “SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY” 和 “OPTIONAL” 应按 [RFC2119] 中的说明解释。 2. 语言标签 语言标签用于帮助标识语言，不论其是口语、书面语、 手语，还是以其他方式发信号表达，其目的都是通信。 这包括构造语言和人工语言，但不包括并非主要用于 人类通信的语言，例如编程语言。 2.1. 语法 语言标签由一个或多个“子标签”的序列组成，每个 子标签都会细化或缩小整个标签所标识的语言范围。 子标签本身又是一串字母数字字符（字母和数字）， 在标签中通过连字符（“-”，[Unicode] U+002D）与其他子标签 区分并分隔。 子标签有不同类型，每种类型都通过长度、在标签中的 位置以及内容来区分：每个子标签的类型仅凭这些特征 即可识别。这使得即便无法识别具体的子标签值，也可 从子标签中提取并分配一些语义信息。因此，语言标签 处理器不需要拥有有效标签或子标签列表（即某个版本 的 IANA 语言子标签注册表副本），即可执行常见的搜索 和匹配操作。唯一不能从子标签结构推断含义的例外， 是下面的产生式 'regular' 和 'irregular' 中列出的 祖父标签。这些标签是在 [RFC3066] 下注册的，是一个 永远不会改变的固定列表。 语言标签的 ABNF [RFC5234] 语法如下： Language-Tag = langtag ; normal language tags / privateuse ; private use tag / grandfathered ; grandfathered tags Phillips & Davis 最佳当前实践 [第 4 页]
RFC 5646 语言标签 2009 年 9 月 langtag = language ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse] language = 2*3ALPHA ; shortest ISO 639 code ["-" extlang] ; sometimes followed by ; extended language subtags / 4ALPHA ; or reserved for future use / 5*8ALPHA ; or registered language subtag extlang = 3ALPHA ; selected ISO 639 codes *2("-" 3ALPHA) ; permanently reserved script = 4ALPHA ; ISO 15924 code region = 2ALPHA ; ISO 3166-1 code / 3DIGIT ; UN M.49 code variant = 5*8alphanum ; registered variants / (DIGIT 3alphanum) extension = singleton 1*("-" (2*8alphanum)) ; Single alphanumerics ; "x" reserved for private use singleton = DIGIT ; 0 - 9 / %x41-57 ; A - W / %x59-5A ; Y - Z / %x61-77 ; a - w / %x79-7A ; y - z privateuse = "x" 1*("-" (1*8alphanum)) grandfathered = irregular ; non-redundant tags registered / regular ; during the RFC 3066 era irregular = "en-GB-oed" ; irregular tags do not match / "i-ami" ; the 'langtag' production and / "i-bnn" ; would not otherwise be / "i-default" ; considered 'well-formed' / "i-enochian" ; These tags are all valid, / "i-hak" ; but most are deprecated / "i-klingon" ; in favor of more modern / "i-lux" ; subtags or subtag / "i-mingo" ; combination Phillips & Davis 最佳当前实践 [第 5 页]
RFC 5646 语言标签 2009 年 9 月 / "i-navajo" / "i-pwn" / "i-tao" / "i-tay" / "i-tsu" / "sgn-BE-FR" / "sgn-BE-NL" / "sgn-CH-DE" regular = "art-lojban" ; these tags match the 'langtag' / "cel-gaulish" ; production, but their subtags / "no-bok" ; are not extended language / "no-nyn" ; or variant subtags: their meaning / "zh-guoyu" ; is defined by their registration / "zh-hakka" ; and all of these are deprecated / "zh-min" ; in favor of a more modern / "zh-min-nan" ; subtag or sequence of subtags / "zh-xiang" alphanum = (ALPHA / DIGIT) ; letters and numbers 图 1：语言标签 ABNF 关于语言标签示例，请参见附录 A。 所有子标签的最大长度均为八个字符。语言标签中不允许 出现空白。ABNF 产生式 'variant' 中有一个细微之处： 以数字开头的变体最小长度为四个字符，而以字母开头的 变体最小长度为五个字符。 尽管 [RFC5234] 指的是八位组，但本文档所述的语言标签 是来自 US-ASCII [ISO646] 字符集的字符序列。只要文档和 应用程序使用的其他编码涵盖 US-ASCII 字符集中相关的 部分，就可以在其中使用语言标签。一个例子是使用 [Unicode] 的 UTF-16LE [RFC2781] 编码的 XML 文档。 2.1.1. 语言标签的格式化 在任何时候，语言标签及其子标签，包括私用和扩展， 都应被视为不区分大小写：某些子标签存在大小写书写 约定，但这些约定 MUST NOT 被认为承载含义。 因此，标签 "mn-Cyrl-MN" 与 "MN-cYRL-mn" 或 "mN- cYrL-Mn"（或任何其他组合）没有区别，并且这些变体 Phillips & Davis 最佳当前实践 [第 6 页]
RFC 5646 语言标签 2009 年 9 月 均传达相同含义：在蒙古国使用的、以西里尔文字书写的 蒙古语。 ABNF 语法也不区分大小写：范围 'A' 到 'Z' 的大写 US-ASCII 字母始终被视为等价，并直接映射到范围 'a' 到 'z' 中对应的 US-ASCII 小写字母。因此，标签 "I-AMI" 被视为等同于 'irregular' 产生式中的值 "i-ami"。 尽管语言标签中的大小写区别不承载含义，语言标签的一致 格式和呈现有助于用户。建议使用注册表中子标签的格式 作为语言标签中的格式。该格式通常对应于产生这些子标签 的各种 ISO 标准中的通用约定。 这些约定包括： o [ISO639-1] 建议语言代码用小写书写 （'mn' 蒙古语）。 o [ISO15924] 建议文字代码使用小写并将首字母大写 （'Cyrl' 西里尔文）。 o [ISO3166-1] 建议国家代码大写（'MN' 蒙古国）。 实现可以在不访问注册表的情况下按如下方式再现此格式。 所有子标签，包括扩展和私用子标签，都使用小写字母， 但有两个例外：不出现在标签开头且不出现在 singleton 之后的两字母和四字母子标签。这样的两字母子标签全部 大写（如标签 "en-CA-x-ca" 或 "sgn-BE-FR"），四字母 子标签使用标题式大小写（如标签 "az-Latn-x-latn"）。 注：某些区域设置中的 ASCII 字母大小写折叠，如果未 谨慎处理，有时会产生非 ASCII 字符值。Unicode 字符 数据库文件 "SpecialCasing.txt" [SpecialCasing] 定义了已知 会导致此类问题的具体情形。特别是，土耳其语和阿塞拜疆语 中的字母 'i'（U+0069）大写后会变为 U+0130 （LATIN CAPITAL LETTER I WITH DOT ABOVE）。实现者 SHOULD 指定与区域设置无关的大小写操作，以确保对子标签进行 大小写折叠不会产生此值，因为它在语言标签中是非法的。 例如，如果使用土耳其语区域设置规则将区域子标签 'in' 转为大写，则会得到序列 U+0130 U+004E，而不是预期的 'IN'。 Phillips & Davis 最佳当前实践 [第 7 页]
RFC 5646 语言标签 2009 年 9 月 2.2. 语言子标签来源与解释 语言标签及其子标签的命名空间由 Internet Assigned Numbers Authority（IANA）按照本文档第 5 节中的规则管理。 IANA 维护的语言子标签注册表是有效子标签的来源：本节 引用的其他标准为该注册表提供源材料。 本文档中使用的术语： o “Tag” 指完整的语言标签，例如 "sr-Latn-RS" 或 "az-Arab-IR"。本文档中的标签示例用双引号括起 （"en-US"）。 o “Subtag” 指标签中由连字符分隔的特定部分，例如标签 "zh-Hant-CN" 中的子标签 'zh'、'Hant' 和 'CN'。 本文档中的子标签示例用单引号括起（'Hant'）。 o “Code” 指外部标准中定义的值（并在本文档中用作 子标签）。例如，'Hant' 是一个 [ISO15924] 文字代码， 它被用于定义可在语言标签中使用的 'Hant' 文字 子标签。本文档中的代码示例用单引号括起 （'en'、'Hant'）。 语言标签的设计方式使每种子标签类型都有唯一的长度和 内容限制。即使子标签自身内容未被识别，这些限制也使 子标签类型的识别成为可能。这允许在不引用底层标准或 IANA 注册表最新版本的情况下解析和处理标签，并使解析 标签时相关的异常处理更加简单。 IANA 注册表中的某些子标签并不来自底层标准。它们只能 出现在标签中的特定位置：只能作为主语言子标签或变体 子标签出现。 私用和扩展子标签序列 MUST 出现在子标签序列的末尾， 并且 MUST NOT 与本文档其他地方定义的子标签交错出现。 这些序列由单字符子标签引入，其保留方式如下： o 单字母子标签 'x' 引入一串私用子标签。任何私用 子标签的解释仅由私下协议定义，而不由本节中的 Phillips & Davis 最佳当前实践 [第 8 页]
RFC 5646 语言标签 2009 年 9 月 规则或本文档定义的任何标准或注册表定义。 o 单字母子标签 'i' 被某些祖父标签使用，例如 "i-default"，其中它总是出现在第一位置，并且不会 与扩展混淆。 o 所有其他单字母和单数字子标签均保留，用于按照 第 3.7 节所述引入标准化的扩展子标签序列。 2.2.1. 主语言子标签 主语言子标签是语言标签中的第一个子标签，且不能省略， 但有两个例外： o 单字符子标签 'x' 作为主子标签时，表示该语言标签 完全由含义通过私下协议定义的子标签组成。例如， 在标签 "x-fr-CH" 中，除非存在私下协议，否则子标签 'fr' 和 'CH' 不表示法语或瑞士这个国家（也不表示 IANA 注册表中的任何其他值）。参见第 4.6 节。 o 单字符子标签 'i' 被某些祖父标签使用（见 第 2.2.8 节），例如 "i-klingon" 和 "i-bnn"。 （其他祖父标签在其第一位置具有主语言子标签。） 以下规则适用于主语言子标签： 1. 两字符主语言子标签根据标准 “ISO 639-1:2002, Codes for the representation of names of languages -- Part 1: Alpha-2 code” [ISO639-1] 中的分配，或 ISO 639-1 注册机构（RA）或主管标准化机构随后作出的分配， 在 IANA 注册表中定义。 2. IANA 注册表中的三字符主语言子标签，根据以下 附加 ISO 639 部分之一中的分配，或相关 ISO 639 注册机构或主管标准化机构随后作出的分配来定义： A. “ISO 639-2:1998 - Codes for the representation of names of languages -- Part 2: Alpha-3 code - edition 1” [ISO639-2] Phillips & Davis 最佳当前实践 [第 9 页]
RFC 5646 语言标签 2009 年 9 月 B. “ISO 639-3:2007 - Codes for the representation of names of languages -- Part 3: Alpha-3 code for comprehensive coverage of languages” [ISO639-3] C. “ISO 639-5:2008 - Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups” [ISO639-5] 3. 范围 'qaa' 到 'qtz' 的子标签保留用于语言标签中的 私用。这些子标签对应于 ISO 639-2 为私用而保留的 代码。这些代码 MAY 用于未注册的主语言子标签 （而不是使用跟在 'x-' 后面的私用子标签）。关于私用 子标签的更多信息，请参阅第 4.6 节。 4. 四字符语言子标签保留用于可能的未来标准化。 5. IANA 注册表中任何长度为五到八个字符的语言子标签， 都是通过第 3.5 节中的注册过程定义的，并且 MAY 用于 形成主语言子标签。此类注册可能包含的一个示例是 祖父 IANA 注册项 "i-enochian"。子标签 'enochian' 可以在 IANA 注册表中注册为主语言子标签（假设 ISO 639 未先注册该语言），从而使 "enochian-AQ" 和 "enochian-Latn" 这样的标签有效。 在本文档创建时，并没有这种子标签的示例。未来不 鼓励进行此类注册：任何新提议的主语言注册都 MUST 先提交给 ISO 639 注册机构。被 ISO 639 注册机构拒绝 的提案，不太可能满足主语言子标签的标准，因此也 不太可能被注册。 6. 除非通过本文档的修订或更新，否则 MUST NOT 将其他 值分配给主子标签。 当一种语言同时具有 ISO 639-1 两字符代码和三字符代码 （由 ISO 639-2、ISO 639-3 或 ISO 639-5 分配）时，IANA 注册表中只定义 ISO 639-1 两字符代码。 当一种语言没有 ISO 639-1 两字符代码，而该语言的 ISO 639-2/T（术语）代码与 ISO 639-2/B（书目）代码不同时， IANA 注册表中只定义术语代码。在本文档创建时，所有同时 具有这两类三字符代码的语言也都分配了 Phillips & Davis 最佳当前实践 [第 10 页]
RFC 5646 语言标签 2009 年 9 月 两字符代码；预计未来不会再发生这种性质的分配。 为避免标签规范形式的不稳定性，如果 ISO 639-1 为某种 已经在 ISO 639-2 或 ISO 639-3 中包含三字符代码的 语言添加两字符代码，则该两字符代码 MUST NOT 被注册。 参见第 3.4 节。 例如，如果某些内容被标记为 'haw'（夏威夷语），该语言 当前没有两字符代码，那么即使 ISO 639-1 将来为夏威夷语 分配了两字符代码，该标签也无需更改。 为了避免版本和子标签选择方面的问题（如从 RFC 1766 过渡到 RFC 3066 时所经历的那样），并确保本文档定义 的子标签具有规范性，ISO 639 Registration Authority Joint Advisory Committee（ISO 639/RA-JAC）在 [iso639.prin] 中纳入了以下声明： “在 ISO 639-1 冻结时已经存在于 ISO 639-2 中的语言 代码，之后不得添加到 ISO 639-1。这样做是为了确保 随时间推移的使用一致性，因为在 Internet 应用中， 当该语言没有 alpha-2 代码可用时，用户被指示使用 alpha-3 代码。” 2.2.2. 扩展语言子标签 扩展语言子标签用于标识某些经过特别选择的语言，这些 语言由于各种历史和兼容性原因，与现有主语言子标签 密切相关，或使用现有主语言子标签进行标记。扩展语言 子标签在用于形成语言标签时，总是与其所隶属的主语言 子标签一起使用（在注册表中以 'Prefix' 字段表示）。 注册表中具有扩展语言子标签的所有语言，也都有一个 相同的主语言子标签记录。形成语言标签时 RECOMMENDED 使用此主语言子标签。以下规则适用于扩展语言子标签： 1. 扩展语言子标签完全由三字母子标签组成。注册表中 定义的所有扩展语言子标签记录，均根据 [ISO639-3] 中的分配来定义。语言集合和分组，例如 [ISO639-5] 中定义的那些，明确排除在扩展语言子标签之外。 Phillips & Davis 最佳当前实践 [第 11 页]
RFC 5646 语言标签 2009 年 9 月 2. 扩展语言子标签记录 MUST 恰好包含一个 'Prefix' 字段， 指示该扩展语言子标签的适当子标签或子标签序列。 3. 扩展语言子标签记录 MUST 包含一个 'Preferred- Value'。'Preferred-Value' 和 'Subtag' 字段 MUST 相同。 4. 尽管 ABNF 产生式 'extlang' 允许语言标签中最多有三个 扩展语言标签，但扩展语言子标签的 'Prefix' 中 MUST NOT 包含另一个扩展语言子标签。也就是说，语言标签中的 第二和第三个扩展语言子标签位置是永久保留的，包含 这些位置上的此类子标签的标签现在以及将来都始终 无效。 例如，宏语言中文（'zh'）涵盖若干语言。出于兼容性 原因，这些语言中的每一种在注册表中都同时具有主语言 子标签和扩展语言子标签。这些语言的一些选定示例包括 赣语（'gan'）、粤语（'yue'）和普通话/官话（'cmn'）。 每一种都被宏语言 'zh'（中文）涵盖。因此，它们在注册表 记录中都具有前缀 "zh"。因此，赣语可用以 "zh-gan" 或 "gan" 开头的标签表示，粤语可用以 "yue" 或 "zh-yue" 开头的标签表示，普通话/官话可用 "zh-cmn" 或 "cmn" 表示。语言子标签 'zh' 仍可在没有扩展语言子标签的 情况下，用于将资源标记为某种未指明的中文变体，而 主语言子标签（'gan'、'yue'、'cmn'）优先于使用扩展 语言形式（"zh-gan"、"zh-yue"、"zh-cmn"）。 2.2.3. 文字子标签 文字子标签用于表示区分某种语言或其方言书面形式的 文字或书写系统变体。以下规则适用于文字子标签： 1. 文字子标签 MUST 跟在任何主语言和扩展语言子标签 之后，并且 MUST 位于任何其他类型的子标签之前。 2. 文字子标签由四个字母组成，并根据 [ISO15924] （“Information and documentation -- Codes for the representation of names of scripts”）中的分配，或 ISO 15924 注册机构或主管标准化机构随后作出的分配来 定义。只有 ISO 15924 分配的代码才会被考虑注册。 Phillips & Davis 最佳当前实践 [第 12 页]
RFC 5646 语言标签 2009 年 9 月 3. 文字子标签 'Qaaa' 到 'Qabx' 保留用于语言标签中的 私用。这些子标签对应于 ISO 15924 为私用而保留的 代码。这些代码 MAY 用于未注册的文字值。关于私用 子标签的更多信息，请参阅第 4.6 节。 4. 语言标签中 MUST 最多只有一个文字子标签，并且当 文字子标签不会为标签增加区分价值，或当主语言或 扩展语言子标签在子标签注册表中的记录包含列出适用 文字子标签的 'Suppress-Script' 字段时，该文字子标签 SHOULD 被省略。 例如："sr-Latn" 表示以拉丁文字书写的塞尔维亚语。 2.2.4. 区域子标签 区域子标签用于表示与特定国家、领土或区域相关联或 适合该区域的语言变体。通常，区域子标签用于表示区域 方言或用法等变体，或特定区域的拼写约定。它还可用于 表示内容以适合整个区域使用的方式表达，例如针对整个 拉丁美洲都实用的西班牙语内容。 以下规则适用于区域子标签： 1. 区域子标签 MUST 跟在任何主语言、扩展语言或文字 子标签之后，并且 MUST 位于任何其他类型的子标签 之前。 2. 两字母区域子标签根据 [ISO3166-1]（“Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes”）中的分配来定义，使用 alpha-2 国家代码列表，或使用 ISO 3166-1 维护机构或主管 标准化机构随后作出的分配。此外，在 ISO 3166-1 中 “例外保留”（而非“已分配”）的代码也被定义在注册表中， 但 'UK' 除外，因为它是已分配代码 'GB' 的完全同义词。 3. 区域子标签 'AA'、'QM'-'QZ'、'XA'-'XZ' 和 'ZZ' 保留用于语言标签中的私用。这些子标签对应于 ISO 3166 为私用而保留的代码。这些代码 MAY 用于私用区域 子标签（而不是使用私用子标签序列）。关于私用子标签 的更多信息，请参阅第 4.6 节。 Phillips & Davis 最佳当前实践 [第 13 页]
RFC 5646 语言标签 2009 年 9 月 4. 三字符区域子标签完全由数字（数值）字符组成，并根据 UN Standard Country or Area Codes for Statistical Use [UN_M.49] 中的分配或主管标准机构随后作出的分配来 定义。并非所有 UN M.49 代码都在 IANA 注册表中定义。 以下规则定义哪些代码会作为有效子标签录入注册表： A. 分配给“宏观地理（大陆）”或次区域的 UN 数字代码 MUST 在注册表中注册。这些代码不与已分配的 ISO 3166-1 alpha-2 代码关联，表示超国家区域，通常 覆盖不止一个国家、州、省或领土。 B. 用于“经济分组”或“其他分组”的 UN 数字代码 MUST NOT 注册到 IANA 注册表中，并且 MUST NOT 用于形成语言标签。 C. 当 ISO 3166-1 将一个以前用于某个国家或区域的 代码重新分配给另一个国家或区域，而该代码已经 存在于注册表中时，该国家或区域的 UN 数字代码 MUST 按第 3.4 节所述注册到注册表中，并且 MUST 用于形成表示其所定义的国家或区域的语言标签 （而不是使用回收的 ISO 3166-1 代码）。 D. 对于注册表中存在关联 ISO 3166-1 alpha-2 代码的 国家或区域，其 UN 数字代码 MUST NOT 录入注册表， 并且 MUST NOT 用于形成语言标签。注意，注册表中的 基于 ISO 3166 的子标签 MUST 确实与所涉 UN M.49 代码相关联。 E. 出于历史原因，UN 数字代码 830（海峡群岛）在本文档 被采纳时尚未注册，且当时没有对应的 ISO 3166-1 代码；只要此前没有注册具有完全相同含义的 ISO 3166-1 代码，该代码 MAY 通过第 3.5 节所述过程 录入 IANA 注册表。 F. 所有其他没有关联 ISO 3166-1 alpha-2 代码的国家或 区域 UN 数字代码，MUST NOT 录入注册表，并且 MUST NOT 用于形成语言标签。关于这些代码的更多信息， 见第 3.4 节。 Phillips & Davis 最佳当前实践 [第 14 页]
RFC 5646 语言标签 2009 年 9 月 5. UN 文档附录 X中的字母数字代码 MUST NOT 录入注册表， 并且 MUST NOT 用于形成语言标签。（在本文档创建时， 这些值与 ISO 3166-1 alpha-2 代码相匹配。） 6. 语言标签中 MUST 最多只有一个区域子标签，并且区域 子标签 MAY 被省略，例如当它不会为标签增加区分价值时。 例如： "de-AT" 表示在奥地利（'AT'）使用的德语（'de'）。 "sr-Latn-RS" 表示以拉丁文字（'Latn'）书写、在塞尔维亚 （'RS'）使用的塞尔维亚语（'sr'）。 "es-419" 表示适合 UN 定义的拉丁美洲和加勒比地区 （'419'）的西班牙语（'es'）。 2.2.5. 变体子标签 变体子标签用于表示额外的、公认的变体，这些变体定义 一种语言或其方言，且不能由其他可用子标签覆盖。以下 规则适用于变体子标签： 1. 变体子标签 MUST 跟在任何主语言、扩展语言、文字或 区域子标签之后，并且 MUST 位于任何扩展或私用子标签 序列之前。 2. 作为一个集合，变体子标签并不与任何特定外部标准 关联。注册表中变体子标签的含义是在第 3.5 节 定义的注册过程中定义的。注意，某个特定变体子标签 可能与某个外部标准相关联。然而，注册并不要求与 标准关联。 3. 可以使用多个变体来形成语言标签。 4. 在用于形成语言标签之前，变体子标签 MUST 按照本文档 第 3.5 节中的规则向 IANA 注册。为了将变体与其他类型的 子标签区分开，注册 MUST 满足以下长度和内容限制： 1. 以字母（a-z, A-Z）开头的变体子标签 MUST 至少 有五个字符长。 Phillips & Davis 最佳当前实践 [第 15 页]
RFC 5646 语言标签 2009 年 9 月 2. 以数字（0-9）开头的变体子标签 MUST 至少有四个 字符长。 5. 同一个变体子标签 MUST NOT 在一个语言标签中使用 超过一次。 * 例如，标签 "de-DE-1901-1901" 无效。 语言子标签注册表中的变体子标签记录 MAY 包含一个或多个 'Prefix'（第 3.1.8 节）字段。每个 'Prefix' 指示在使用 该变体时，用于形成语言标签（酌情与其他子标签一起）的 合适子标签序列。 大多数共享同一前缀的变体是互斥的。例如，德语正字法 变体 '1996' 和 '1901' SHOULD NOT 用在同一标签中，因为 它们表示不同拼写改革的日期。若某个变体可以有意义地 与另一个变体组合使用，则其注册表记录 SHOULD 包含列出 该另一个变体的 'Prefix' 字段。例如，如果创建了另一个 德语变体 'example'，且它适合与 '1996' 一起使用，则 'example' 应包含两个 'Prefix' 字段："de" 和 "de-1996"。 例如： "sl-nedis" 表示斯洛文尼亚语的 Natisone 或 Nadiza 方言。 "de-CH-1996" 表示在瑞士使用、并按公元 1996 年开始的 拼写改革书写的德语。 2.2.6. 扩展子标签 扩展提供了一种机制，用于在各种应用中扩展语言标签。 它们旨在标识通常与语言或语言标签相关联、但不属于 语言标识本身的信息。参见第 3.7 节。以下规则适用于 扩展： 1. 扩展 MUST 至少跟在一个主语言子标签之后。也就是说， 语言标签不能以扩展开头。扩展用于扩展语言标签， 而不是覆盖或替换它们。例如，"a-value" 不是格式良好的 语言标签，而 "de-a-value" 是。注意，扩展不能用于 完全私用的标签（即以 "x-" 开头的标签）。 Phillips & Davis 最佳当前实践 [第 16 页]
RFC 5646 语言标签 2009 年 9 月 2. 扩展子标签通过一个单字符子标签（称为 "singleton"） 与本文档定义的其他子标签分隔。该 singleton MUST 是 通过第 3.7 节所述机制分配给注册机构的 singleton， 并且 MUST NOT 是字母 'x'，因为 'x' 保留用于私用 子标签序列。 3. 每个 singleton 子标签在每个标签中 MUST 最多出现 一次（作为私用子标签时除外）。也就是说，singleton 子标签 MUST NOT 重复。例如，标签 "en-a-bbb-a-ccc" 无效，因为子标签 'a' 出现了两次。注意，标签 "en-a-bbb-x-a-ccc" 有效，因为 singleton 'a' 的第二次 出现位于私用序列中。 4. 扩展子标签 MUST 满足定义其 singleton 前缀的文档所 设定的任何要求，以及维护机构提供的任何要求。注意， 这些子标签可能没有注册表，且验证处理器不要求验证 扩展。 5. 每个扩展子标签 MUST 长度为二到八个字符，且仅由字母 或数字组成，每个子标签之间以单个 '-' 分隔。扩展中 忽略大小写区别（与任何语言子标签一样），并且此类 规范化子标签预期采用小写。 6. 每个 singleton MUST 后跟至少一个扩展子标签。例如， 标签 "tlh-a-b-foo" 无效，因为第一个 singleton 'a' 后面立即跟着另一个 singleton 'b'。 7. 扩展子标签 MUST 跟在标签中的所有主语言、扩展语言、 文字、区域和变体子标签之后，并且 MUST 位于任何私用 子标签序列之前。 8. 跟在 singleton 之后、另一个 singleton 之前的所有 子标签都是该扩展的一部分。示例：在标签 "fr-a-Latn" 中，子标签 'Latn' 不表示 IANA 语言子标签注册表中 定义的文字子标签 'Latn'。它的含义由扩展 'a' 定义。 9. 如果一个标签中出现多个扩展，则该标签 SHOULD 按 第 4.5 节所述进行规范化，即将各种扩展序列按不区分 大小写的 ASCII 顺序排序。 例如，如果为 singleton 'r' 定义了一个扩展，并且它定义了 所示子标签，则以下标签将是一个有效示例： "en-Latn-GB-boont-r-extended-sequence-x-private"。 Phillips & Davis 最佳当前实践 [第 17 页]
RFC 5646 语言标签 2009 年 9 月 2.2.7. 私用子标签 私用子标签用于通过私下协议，表示在给定上下文中重要的 语言差异。以下规则适用于私用子标签： 1. 私用子标签通过保留的单字符子标签 'x' 与本文档定义的 其他子标签分隔。 2. 私用子标签 MUST 符合所有子标签在 ABNF 中定义的格式和 内容约束；也就是说，它们 MUST 仅由字母和数字组成， 且长度不超过八个字符。 3. 私用子标签 MUST 跟在标签中的所有主语言、扩展语言、 文字、区域、变体和扩展子标签之后。换一种说法，跟在 singleton 'x' 之后的所有子标签 MUST 被视为私用。 示例：标签 "en-x-US" 中的子标签 'US' 是私用子标签。 4. 一个标签 MAY 完全由私用子标签组成。 5. 不为私用子标签定义来源。私用子标签的使用仅由私下 协议决定。 6. 当存在替代方案或用于一般交换时，不建议使用私用 子标签。关于私用子标签选择的更多信息，见第 4.6 节。 例如，假设一组学者正在研究一些中古希腊语文本。他们 可能约定使用某组私用子标签来标识文本中不同的写作风格。 例如，他们可能用 'el-x-koine' 表示“通俗”风格的文档， 而用 'el-x-attic' 表示模仿阿提卡风格的其他文档。这些 子标签不会被外部过程或系统识别，但可能有助于该小组中 的人员对各种文本进行研究分类。 注册表中也有来自 ISO 639、ISO 15924 或 ISO 3166 为私用 而保留的代码的子标签。不要将这些与跟在子标签 'x' 之后 的私用子标签序列混淆。参见第 4.6 节。 2.2.8. 祖父项和冗余注册 在 RFC 4646 之前，完整语言标签是按照 RFC 1766 和/或 RFC 3066 中的规则注册的。所有这些已注册标签仍作为 语言标签有效。 Phillips & Davis 最佳当前实践 [第 18 页]
RFC 5646 语言标签 2009 年 9 月 这些已注册标签中的许多，由于 RFC 4646 或本文档的出现而 变得冗余。冗余标签是这样一种祖父注册项：其各个子标签 以相同语义含义出现在注册表中。例如，标签 "zh-Hant" （繁体中文）现在可由子标签 'zh'（中文）和 'Hant' （汉字传统变体）组成。这些冗余标签在注册表中作为 'redundant' 类型的记录保留，主要出于历史记录的考虑。 其余先前注册的标签则是“祖父项”。这些标签分为两组： 'regular' 和 'irregular'。 看起来匹配图 1 中 'langtag' 产生式的祖父标签，被视为 'regular' 祖父标签。这些标签包含一个或多个子标签，这些 子标签要么不单独出现在注册表中，要么虽出现但具有不同 语义含义：每个标签整体代表一种语言或一组语言。 不匹配 ABNF 中 'langtag' 产生式、否则会无效的祖父标签， 被视为 'irregular' 祖父标签。除 "en-GB-oed"（它是 "en-GB" 的一个变体）外，它们每个整体都代表一种语言。 许多祖父标签已被随后添加的新子标签取代：每条被取代 的记录都包含一个 'Preferred-Value' 字段，应该使用该字段 来形成表示该值的语言标签。例如，标签 "art-lojban" 被 主语言子标签 'jbo' 取代。 2.2.9. 符合性类别 实现有时需要描述其相对于本文档所述规则和实践的能力。 标签可以通过多种方式检查或验证，但这里正式定义了两种 特定的标签符合性类别。 如果一个标签符合 ABNF（第 2.1 节），则认为它是“格式良好”的。 语言标签在语法上可能是格式良好的，但在内容上并不有效。 然而，许多涉及语言标签的操作即使不了解子标签的含义或 有效性，也能良好工作。 如果一个标签满足以下条件，则认为它是“有效”的： o 该标签格式良好。 Phillips & Davis 最佳当前实践 [第 19 页]
RFC 5646 语言标签 2009 年 9 月 o 该标签要么在祖父标签列表中，要么其所有主语言、扩展 语言、文字、区域和变体子标签，在特定注册表日期的 IANA 语言子标签注册表中出现。 o 没有重复的变体子标签。 o 没有重复的 singleton（扩展）子标签。 注意，标签的有效性取决于用于验证该标签的注册表日期。 较新的注册表副本可能包含旧版本没有的子标签。 如果某标签（截至某特定版本、修订和日期）对给定扩展 （第 3.7 节）有效，则它满足上述“有效”的标准，并且还满足 以下条件： 标签扩展部分中使用的每个子标签都按照该扩展有效。 较早的规范或语言标签实现有时引用 [RFC3066]。在该文档 下，更广泛的一组标签被认为是格式良好的。任何在 RFC 3066 下有效使用的标签，在本文档语法下都是格式良好且 有效的；只有无效或非法的标签在较早定义下曾被视为 格式良好，而现在不再如此。RFC 3066 下的语言标签语法为： obs-language-tag = primary-subtag *( "-" subtag ) primary-subtag = 1*8ALPHA subtag = 1*8(ALPHA / DIGIT) 图 2：RFC 3066 语言标签语法 指定为私用的子标签以及由 'x' 子标签引入的私用序列， 可用于没有已分配子标签且注册并非合适选择的情况。 例如，可以使用 "no-QQ" 这样的标签，其中 'QQ' 是一组 私用 ISO 3166-1 代码之一，用于表示其他未定义的区域。 用户 MUST NOT 分配使用未出现在注册表中的子标签的语言 标签，除非是在私用序列中（例如标签 "en-x- personal" 中的子标签 'personal'）。除了无效之外，用户 还会冒与未来可能的分配或注册发生冲突的风险。 特别注意：尽管本文档中出现的 'Language-Tag' 产生式在 功能上等价于 [RFC4646] 中的产生式，但它已经 Phillips & Davis 最佳当前实践 [第 20 页]
RFC 5646 语言标签 2009 年 9 月 被修改，以防止旧的 'grandfathered' 产生式导致某些格式 良好性错误。 3. 注册表格式与维护 IANA 语言子标签注册表（“注册表”）包含语言标签中所有 有效子标签的完整列表。这为实现者提供了一种直接可靠的 方法来验证语言标签。注册表将得到维护，以便除扩展子标签 外，能够验证根据本文档或其修订版或后继文档的规定出现 在语言标签中的所有子标签。此外，各种子标签的含义将随 时间保持明确和稳定。（当然，私用子标签的含义不由注册表 定义。） 本节定义注册表，以及与其相关的维护和更新程序，并且还 定义一个用于语言标签扩展的注册表（第 3.7 节）。 3.1. IANA 语言子标签注册表的格式 IANA 语言子标签注册表是一个机器可读文件，采用本节 描述的格式，并包括按照第 3.5 节所述过程批准的注册 表单副本。 从 RFC 3066 取得的祖父标签和冗余标签的现有注册表单， 已作为废止的 RFC 3066 注册表的一部分予以维护。由 [RFC4645] 或 [RFC5645] 添加到注册表的子标签没有单独的 注册表单（因此这些添加项没有归档表单）。 3.1.1. 文件格式 注册表是一个 [Unicode] 文本文件，由一系列记录组成，其格式 基于 “record-jar”（见 [record-jar]）。每条记录又由一系列 字段组成，这些字段描述各种子标签和标签。实际注册表文件 使用 UTF-8 [RFC3629] 字符编码进行编码。 每个字段可视为单个逻辑字符行。每个字段包含一个 “field-name”和一个“field-body”。它们由一个“field-separator” 分隔。field-separator 是 COLON 字符（U+003A）加上任何 周围空白。每个字段以换行序列 CRLF 结束。每个字段中的 文本 MUST 采用 Unicode Normalization Form C（NFC）。 Phillips & Davis 最佳当前实践 [第 21 页]
RFC 5646 语言标签 2009 年 9 月 一组字段构成一条“record”。记录之间由仅包含序列 "%%" （U+0025 U+0025）的行分隔。 尽管字段在逻辑上是单行文本，但文件格式中的每一行文本 限制为 72 字节。为适应这一限制，field-body 可拆分为多行 表示；这称为“折行”。折行按照常规换行约定进行。通常在 空白边界处进行，但当值不包含空格时（例如某种语言在词 之间不使用空白），也可在其他字符之间发生。无论如何， MUST NOT 在多字节 UTF-8 序列内部或组合字符序列中间断行。 更多信息见 [UAX14]。 尽管文件格式使用 Unicode 字符集，并且文件本身使用 UTF-8 编码，但除非特定字段说明（第 3.1.2 节）中另有说明， 字段仅限于 US-ASCII [ISO646] 字符集中可打印字符。 注册表格式由以下 ABNF [RFC5234] 描述。字符编号（码点） 取自 Unicode，并且 ABNF 产生式中的终结符以字符而非字节 表示。 registry = record *("%%" CRLF record) record = 1*field field = ( field-name field-sep field-body CRLF ) field-name = (ALPHA / DIGIT) [*(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] field-sep = *SP ":" *SP field-body = *([[*SP CRLF] 1*SP] 1*CHARS) CHARS = (%x21-10FFFF) ; Unicode code points 图 3：注册表格式 ABNF field-body 中的序列 '..'（U+002E U+002E）表示一个值范围。 这样的范围表示在该范围内、按字母或数字顺序排列且长度 相同的所有子标签，包括明确提到的值。例如，'a..c' 表示 值 'a'、'b' 和 'c'，'11..13' 表示值 '11'、'12' 和 '13'。 所有 field-body 包含日期值的字段，都使用 [RFC3339] 中 规定的 “full-date” 格式。例如，"2004-06-28" 表示公历 2004 年 6 月 28 日。 Phillips & Davis 最佳当前实践 [第 22 页]
RFC 5646 语言标签 2009 年 9 月 3.1.2. 记录和字段定义 注册表中有三种记录类型："File-Date"、"Subtag" 和 "Tag"。 注册表中的第一条记录始终是 "File-Date" 记录。该记录在 文件中只出现一次，并包含一个字段，其 field-name 为 "File-Date"。该记录的 field-body 包含一个日期（见 第 5.1 节），从而可以轻松识别注册表的不同版本。 File-Date: 2004-06-28 %% 图 4：File-Date 记录示例 后续记录包含多个字段，表示关于子标签或标签的信息。 两种记录类型的结构相同，只是 "Subtag" 记录包含一个 field-name 为 "Subtag" 的字段，而不出所料，"Tag" 记录 包含一个 field-name 为 "Tag" 的字段。除 'Description'、 'Comments' 和 'Prefix' 字段外，field-name 在每条记录中 MUST NOT 出现超过一次。 每条记录 MUST 至少包含以下每个字段之一： o 'Type' * Type 的 field-body MUST 由以下字符串之一组成： "language"、"extlang"、"script"、"region"、"variant"、 "grandfathered" 和 "redundant"；它表示标签或子标签的 类型。 o 'Subtag' 或 'Tag' 之一 * Subtag 的 field-body 包含所定义的子标签。该字段 MUST 出现在所有 'Type' 具有以下值之一的记录中： "language"、"extlang"、"script"、"region" 或 "variant"。 * Tag 的 field-body 包含一个完整语言标签。该字段 MUST 出现在所有 'Type' 具有以下值之一的记录中： "grandfathered" 或 "redundant"。如果 'Type' 为 "grandfathered"，则 'Tag' field-body 将是第 2.1 节 中 'regular' 或 'irregular' 产生式列出的标签之一。 Phillips & Davis 最佳当前实践 [第 23 页]
RFC 5646 语言标签 2009 年 9 月 o 'Description' * Description 的 field-body 包含对子标签或标签的非规范性 描述。 o 'Added' * Added 的 field-body 包含记录被注册的日期；对于祖父 标签或冗余标签，则包含对应标签按 [RFC1766] 或 [RFC3066] 规则注册的日期。 每条记录 MAY 还包含以下字段： o 'Deprecated' * Deprecated 的 field-body 包含记录被弃用的日期。在某些 情况下，此值早于同一记录中 'Added' 字段的值。也就是说， 弃用日期早于该记录被添加到注册表的日期。 o 'Preferred-Value' * Preferred-Value 的 field-body 包含从本记录值到其 首选现代等价项的规范映射。根据 'Type' 字段的值， 此值可采用不同形式： + 对于类型为 'language' 的字段，'Preferred-Value' 包含在形成语言标签时首选的主语言子标签。 + 对于类型为 'script'、'region' 或 'variant' 的字段， 'Preferred-Value' 包含在形成语言标签时首选的同类 型子标签。 + 对于类型为 'extlang'、'grandfathered' 或 'redundant' 的字段，'Preferred-Value' 包含一个在 形成语言标签时首选的“扩展语言范围” [RFC4647]。 也就是说，首选语言标签将按顺序包含 'Preferred-Value' 中出现的每个子标签；语言标签中 还可以包含附加字段，如本文档其他地方所述。例如， 祖父标签 "zh-min-nan"（闽南语）的替代项是 "nan"， 它可作为 Phillips & Davis 最佳当前实践 [第 24 页]
RFC 5646 语言标签 2009 年 9 月 "nan-Hant" 或 "nan-TW" 等标签的基础（注意，扩展 语言子标签形式如 "zh-nan-Hant" 或 "zh- nan-TW" 也可以使用）。 o 'Prefix' * Prefix 的 field-body 包含一个有效语言标签，RECOMMENDED 作为本记录子标签的一个可能前缀。该字段 MAY 出现在 'Type' field-body 为 'extlang' 或 'variant' 的记录中 （它 MUST NOT 出现在任何其他记录类型中）。 o 'Suppress-Script' * Suppress-Script 的 field-body 包含一个文字子标签，在 与相关主语言或扩展语言子标签形成语言标签时 SHOULD NOT 使用该文字子标签。该字段 MUST 只出现在 'Type' field-body 为 'language' 或 'extlang' 的记录中。见 第 4.1 节。 o 'Macrolanguage' * Macrolanguage 的 field-body 包含一个主语言子标签，该 子标签由 ISO 639 定义为涵盖此语言子标签的“宏语言”。 该字段 MUST 只出现在 'Type' field-body 为 'language' 或 'extlang' 的记录中。 o 'Scope' * Scope 的 field-body 包含关于主语言或扩展语言子标签的 信息，指示根据 ISO 639 的语言代码类型。该字段允许的 值为 "macrolanguage"、"collection"、"special" 和 "private-use"。该字段只出现在 'Type' field-body 为 'language' 或 'extlang' 的记录中。当省略该字段时， 该语言为一种个体语言。 o 'Comments' * Comments 的 field-body 包含关于子标签的附加信息，视 为理解注册表以及使用该子标签或标签实现语言标签所需。 本文档未来版本可能向注册表添加其他字段；实现 SHOULD 忽略注册表中发现但本文档未定义的字段。 Phillips & Davis 最佳当前实践 [第 25 页]
RFC 5646 语言标签 2009 年 9 月 3.1.3. Type 字段 字段 'Type' 包含标识其所在记录类型的字符串。'Type' field-body 的值为："language"（第 2.2.1 节）；"extlang" （第 2.2.2 节）；"script"（第 2.2.3 节）；"region" （第 2.2.4 节）；"variant"（第 2.2.5 节）；"grandfathered" 或 "redundant"（第 2.2.8 节）。 3.1.4. Subtag 和 Tag 字段 字段 'Subtag' 包含记录中定义的子标签。字段 'Tag' 出现在 'Type' 为 'grandfathered' 或 'redundant' 的记录中，并包含 在 [RFC3066] 下注册的标签。 'Subtag' field-body MUST 遵循第 2.1.1 节中所述的大小写 约定。field-body 中的所有子标签均使用小写字母，但有 两个例外： 'Type' 字段为 'script' 的子标签（换言之，由 ISO 15924 定义的子标签）MUST 使用标题式大小写。 'Type' 字段为 'region' 的子标签（换言之，由 ISO 3166-1 定义的非数字区域子标签）MUST 全部大写。 'Tag' field-body MUST 按第 2.1.1 节所述规则格式化。 3.1.5. Description 字段 字段 'Description' 包含记录中标签或子标签的描述。 'Description' 字段 MAY 在每条记录中出现多次。'Description' 字段 MAY 包含完整范围的 Unicode 字符。至少一个 'Description' 字段 MUST 以拉丁文字书写或转写；其他 'Description' 字段 MAY 使用任何文字或语言。 'Description' 字段用于标识目的。描述 SHOULD 包含全部且 仅包含为区分一个子标签与可能混淆的其他子标签所必需的 信息。它们并不旨在提供一般背景信息，也不旨在提供所有 可能的替代名称或称谓。'Description' 字段不一定表示记录 中项目的实际本地名称，也不保证任何描述采用某种特定 语言（例如英语或法语）。 Phillips & Davis 最佳当前实践 [第 26 页]
RFC 5646 语言标签 2009 年 9 月 注册表中对应于 ISO 639、ISO 15924、ISO 3166-1 或 UN M.49 代码的描述，仅旨在表示该标识符在加入注册表时或随后在 稳定性规则（第 3.4 节）范围内通过后续注册修改时，由源 标准定义的含义。'Description' 不取代源标准本身的内容。 'Description' 字段并不旨在作为子标签的本地化英文名称。 语言标签和子标签描述的本地化或翻译超出本文档范围。 对于来自源标准（如 ISO 639 或 ISO 15924）的子标签，记录 中的 'Description' 字段也最初取自该源标准。源标准中的 多个描述被拆分为单独的 'Description' 字段。源标准的描述 MAY 在插入之前或通过注册过程进行编辑或修改，并可省略或 移除附加或多余的描述。每个 'Description' 字段在其出现的 记录中 MUST 唯一，并且同一描述的格式变体 SHOULD NOT 出现 在该特定记录中。例如，尽管 ISO 639-1 代码 'fy' 在该标准中 同时具有描述 "Western Frisian" 和描述 "Frisian, Western"， 但注册表中只出现其中一个描述。 为帮助确保用户不会混淆应使用哪个子标签，分配给任何特定 类型（'language'、'extlang'、'script' 等）记录的 'Description' 字段，在该给定记录类型内 MUST 唯一，但有以下 例外：如果某个特定 'Description' 字段出现在给定类型的多条 记录中，则最多只有其中一条记录可以省略 'Deprecated' 字段。 所有共享某个 'Description' 的已弃用记录 MUST 具有相同的 'Preferred-Value'，且所有未弃用记录 MUST 是该 'Preferred- Value'。这意味着共享某个 'Description' 的同类型两条记录 也是语义等价的，并且对于某个给定 'Description' 的含义， 首选记录不会超过一条。 例如，考虑 'language' 子标签 'zza'（Zaza）和 'diq' （Dimli）。恰好 'zza' 是涵盖 'diq' 的宏语言，因此在 ISO 639-3 中也有描述 "Dimli"。为防止冲突，在 'zza' 的 注册表记录中，该描述被编辑为 "Dimli (macrolanguage)"。 相比之下，子标签 'he' 和 'iw' 共享 "Hebrew" 这个 'Description' 值；这是允许的，因为 'iw' 已被弃用，且其 'Preferred-Value' 为 'he'。 Phillips & Davis 最佳当前实践 [第 27 页]
RFC 5646 语言标签 2009 年 9 月 对于类型为 'language' 的字段，注册表中出现的第一个 'Description' 字段尽可能对应于 ISO 639-3 分配的 Reference Name。这有助于在 ISO 639 和注册表之间进行交叉引用。 当由于某个源标准的行动而创建或更新记录时，Language Subtag Reviewer MAY 在将拟议记录提交给 ietf-languages@iana.org 列表审议之前，编辑描述以纠正格式不规则（如拼写错误、 不适当的撇号或其他标点、过多或缺失的空格）。 3.1.6. Deprecated 字段 字段 'Deprecated' 包含记录被弃用的日期，并且 MAY 通过 第 3.3 节所述维护过程或通过第 3.5 节所述注册过程， 添加到任何记录、更改或移除。通常，添加 'Deprecated' 字段是由于某个标准机构（如 ISO 3166）撤销代码的行动。 尽管带有 'Deprecated' 字段的子标签和标签在语言标签中 有效，但它们已被弃用，验证处理器 SHOULD NOT 生成这些 子标签。注意，包含 'Deprecated' 字段但没有对应 'Preferred-Value' 字段的记录没有替代映射。 在某些历史情形中，可能无法重构原始弃用日期。对于这些 情况，注册表中会出现一个近似日期。一些子标签以及一些 祖父标签或冗余标签在注册表初始创建之前已经被弃用。 其确切规则见 [RFC4645] 第 2 节。注意，这些记录具有一个 'Deprecated' 字段，其日期早于对应的 'Added' 字段！ 3.1.7. Preferred-Value 字段 字段 'Preferred-Value' 包含其所在记录与另一个标签或子标签 （取决于记录的 'Type'）之间的映射。该字段中的值用于 规范化（见第 4.5 节）。在子标签或标签也有 'Deprecated' 字段的情况下，'Preferred-Value' 是表示该记录值时选择语言 标签的 RECOMMENDED 最佳选择。 包含 'Preferred-Value' 的记录分为以下四组： Phillips & Davis 最佳当前实践 [第 28 页]
RFC 5646 语言标签 2009 年 9 月 1. 后来被撤销、改用其他代码的 ISO 639 语言代码。这些值 大多只是历史遗留。上面的 'he'/'iw' 配对就是一个例子。 2. 来自已被撤销并改用新代码的代码或值的子标签（类型不 是 language 或 extlang）。这尤其适用于来自 ISO 3166-1 的区域子标签，因为有时一个国家会以足以需要新区域代码 的方式更改其名称或行政管理。在某些情况下，国家会恢复 旧名称，而该名称可能已经被编码。例如，当国家名称改变 时，子标签 'ZR'（扎伊尔）被子标签 'CD'（刚果民主共和国） 替代。 3. 因其所表示的值后来被编码而变得过时的标签或子标签。 许多祖父标签或冗余标签后来被 ISO 639 编码，例如， 并属于这一类。例如，"i-klingon" 在子标签 'tlh' 被添加时 被弃用。"i-klingon" 的记录具有 'Preferred-Value' 'tlh'。 4. 扩展语言子标签始终映射到其相同的主语言子标签。例如， 扩展语言子标签 'yue'（粤语）可用于形成标签 "zh-yue"。 它有一个到主语言子标签 'yue' 的 'Preferred-Value' 映射， 这意味着 "zh-yue-Hant-HK" 这样的标签可以规范化为 "yue-Hant-HK"。 除类型为 'extlang' 的记录外，包含 'Preferred-Value' 字段的 记录 MUST 也具有 'Deprecated' 字段。该字段包含标签或子标签 因首选值而被弃用的日期。 对于类型为 'extlang' 的记录，'Preferred-Value' 字段出现时 没有对应的 'Deprecated' 字段。实现 MAY 忽略这些首选值映射， 但如果忽略映射，SHOULD 以一致方式这样做。它 SHOULD 还将 'Preferred-Value' 视为等价于被映射项。例如，标签 "zh-yue-Hant-HK" 和 "yue-Hant-HK" 在语义上等价，应当被 视为相同标签。 有时，已弃用的代码在某些上下文中是首选的。例如，"iw" 和 "he" 都可以在 Java 编程语言中使用，但 "he" 在输入时会 转换为 "iw"，因此 "iw" 是 Java 中的规范形式。 Phillips & Davis 最佳当前实践 [第 29 页]
RFC 5646 语言标签 2009 年 9 月 类型为 'region' 的记录中的 'Preferred-Value' 映射，有时并不 表示与原始值完全相同的含义。国家代码改变有许多原因， 这对语言标签形成的影响将取决于相关变更的性质。例如， 当两个国家在 1990 年统一时，区域子标签 'YD'（民主也门） 被弃用，改用子标签 'YE'（也门）。 'Preferred-Value' MAY 按第 3.3 节中的规则添加到记录、 更改或移除。记录中 'Preferred-Value' 字段的添加、修改或 移除，并不意味着使用受影响子标签的内容需要重新标记。 类型为 "grandfathered" 和 "redundant" 的记录中的 'Preferred-Value' 字段各自包含一个“扩展语言范围” [RFC4647]， 强烈 RECOMMENDED 用来替代记录的值。在许多情况下，这些 映射是在 [RFC4646] 被采用之前，通过弃用标签而创建的。 例如，标签 "no-nyn" 被弃用，改用 ISO 639-1 定义的语言代码 'nn'。 类型为 "extlang" 的子标签记录中的 'Preferred-Value' 字段也 包含一个“扩展语言范围”。这允许该子标签被弃用，改用单个 主语言子标签或新的 language-extlang 序列。 通常，子标签中 'Preferred-Value' 字段的添加、移除或更改， 是为了反映某个源标准中的变更。例如，如果 ISO 3166-1 区域代码被弃用并改用另一个代码，则 SHOULD 导致添加 'Preferred-Value' 字段。 一个子标签的变更也可能影响其他子标签：在提议对注册表 进行变更时，Language Subtag Reviewer MUST 审查注册表中 是否存在此类影响，并使用第 3.5 节中的过程提出必要的变更， 尽管任何人 MAY 请求此类变更。例如： 假设子标签 'XX' 具有 'Preferred-Value' 'YY'。如果 'YY' 后来变更为具有 'Preferred-Value' 'ZZ'，则 'XX' 的 'Preferred-Value' MUST 也变更为 'ZZ'。 假设某个已注册语言子标签 'dialect' 表示尚未在 ISO 639 任何部分中可用的语言。若 ISO 639 后来添加了对应语言 代码，SHOULD 导致为 'dialect' 添加 'Preferred-Value'。 Phillips & Davis 最佳当前实践 [第 30 页]
RFC 5646 语言标签 2009 年 9 月 3.1.8. Prefix 字段 字段 'Prefix' 包含一个有效语言标签，RECOMMENDED 作为本记录 子标签的一个可能前缀，也许还带有其他子标签。也就是说， 在语言标签中包含一个具有至少一个 'Prefix' 的扩展语言或 变体子标签时，生成的标签 SHOULD 使用 “Extended Filtering” 算法（见 [RFC4647]）匹配该子标签的至少一个 'Prefix' 字段，并且该 'Prefix' 中的每个子标签 SHOULD 出现在该子标签 本身之前。 'Prefix' 字段 MUST 在类型为 'extlang' 的记录中恰好出现一次。 'Prefix' 字段 MAY 在类型为 'variant' 的记录中出现多次（或 完全不出现）。只要该 'variant' 记录已经至少有一个 'Prefix' 字段，就 MAY 通过注册过程向 'variant' 记录添加 此类附加字段。 每个 'Prefix' 字段都指示与此子标签一起形成有意义标签的 特定子标签序列。例如，扩展语言子标签 'cmn'（普通话/官话） 只有与其前缀 'zh'（中文）一起使用才有意义。类似地， 'rozaj'（斯洛文尼亚语的一种方言 Resian）与其前缀 'sl' （斯洛文尼亚语）一起使用时是适当的，而 "is-1994" 这样的 标签则不适当（且可能没有意义）。尽管 'rozaj' 的 'Prefix' 是 "sl"，其他子标签可能出现在它们之间。例如，标签 "sl-IT-rozaj"（斯洛文尼亚语、意大利、Resian）匹配 'Prefix' "sl"。 'Prefix' 还指示变体子标签何时适合一起使用（许多本来共享 同一 'Prefix' 的变体是互斥的），以及变体的相对顺序应当是 什么。例如，变体 '1994'（标准化 Resian 正字法）在注册表中 具有多个 'Prefix' 字段（"sl-rozaj"、"sl-rozaj-biske"、 "sl-rozaj-njiva"、"sl-rozaj-osojs" 和 "sl-rozaj- solba"）。这不仅表示 '1994' 适合与这五个 Resian 变体子标签 （'rozaj'、'biske'、'njiva'、'osojs' 和 'solba'）一起使用， 也表示它 SHOULD 出现在标签中这些变体之后。因此，语言标签 应采用 "sl-rozaj-biske-1994" 这种形式，而不是 "sl-1994- rozaj-biske" 或 "sl-rozaj-1994-biske"。 如果一条记录不包含 'Prefix' 字段，则之后 MUST NOT 向该记录 添加 'Prefix' 字段。否则，只要严格扩大推荐语言标签的范围， 就 MAY 注册对 'Prefix' 字段集合的变更（添加、删除或修改）。 例如，值为 "be- Latn"（白俄罗斯语、拉丁文字）的 'Prefix' 可以替换为值 "be" （白俄罗斯语），但不能替换为值 "ru-Latn"（俄语、拉丁文字） Phillips & Davis 最佳当前实践 [第 31 页]
RFC 5646 语言标签 2009 年 9 月 或值 "be-Latn-BY"（白俄罗斯语、拉丁文字、白俄罗斯），因为 后两者要么改变、要么缩小了建议标签的范围。 'Prefix' 字段的 field-body MUST NOT 与给定记录已经注册的任何 'Prefix' 冲突。当无法构造包含该前缀的有效标签时，就会出现 这种冲突，例如两个子标签各自具有包含对方子标签的 'Prefix'。 例如，假设子标签 'avariant' 具有前缀 "es-bvariant"。那么 子标签 'bvariant' 不能被分配前缀 'avariant'，因为这将要求 形成 "es-avariant-bvariant-avariant" 形式的标签，而该标签 无效。 3.1.9. Suppress-Script 字段 字段 'Suppress-Script' 包含一个文字子标签（其记录出现在 注册表中）。'Suppress-Script' 字段 MUST 只出现在 'Type' field-body 为 'language' 或 'extlang' 的记录中。该字段 MUST NOT 在一条记录中出现超过一次。 该字段指示一种用于书写给定语言绝大多数文档的文字。因此， 这种文字的子标签不会为语言标签增加区分信息，因而 SHOULD NOT 用于该语言的大多数文档。省略该字段指示的文字子标签， 有助于确保按照本文档规则生成的语言标签与基于 RFC 3066 的语言标签及标签处理器或消费者之间具有更好的兼容性。 例如，几乎所有冰岛语文档都用拉丁文字书写，因此标签 "is-Latn" 中的子标签 'Latn' 是冗余的。 许多语言子标签记录没有 'Suppress-Script' 字段。缺少 'Suppress-Script' 可能表示该语言通常以多种文字书写，或该 语言通常不书写。它也可能意味着记录创建时没有足够信息， 因此仍是未来注册的候选项。 3.1.10. Macrolanguage 字段 字段 'Macrolanguage' 包含一个主语言子标签（其记录出现在 注册表中）。该字段指示根据 ISO 639-3 作出的分配，涵盖此 子标签语言的一种语言。 ISO 639-3 将注册表中的某些语言标记为“宏语言”。ISO 639-3 将术语“宏语言”定义为“由关系密切的语言变体组成的簇， 这些变体 [...] 可被视为不同的个体语言，但在某些使用 Phillips & Davis 最佳当前实践 [第 32 页]
RFC 5646 语言标签 2009 年 9 月 上下文中，需要所有变体的单一语言身份”。这些对应于 ISO 639-2 中注册为个体语言、后来发现对应于 ISO 639-3 中 不止一种语言的代码。 宏语言所包含的语言称为“被涵盖语言”。每种被涵盖语言的 记录在注册表中包含一个 'Macrolanguage' 字段；宏语言自身 并没有被特别标记。注意，一些被涵盖语言具有 ISO 639-1 或 ISO 639-2 代码。 'Macrolanguage' 字段只能出现在类型为 'language' 或 'extlang' 的记录中。只有 ISO 639-3 分配的值才会被考虑纳入。每当 ISO 639-3 定义新值或撤销旧值时，'Macrolanguage' 字段 MAY 通过正常注册过程添加或移除。宏语言是资料性的，并且如果 ISO 639-3 改变这些值，MAY 被移除或更改。关于此字段的使用 以及在宏语言和被涵盖语言子标签之间进行选择的更多信息， 见第 4.1.1 节。 例如，语言子标签 'nb'（挪威博克马尔语）和 'nn' （挪威尼诺斯克语）各自都有一个值为 'no'（挪威语）的 'Macrolanguage' 字段。更多信息见第 4.1 节。 3.1.11. Scope 字段 字段 'Scope' 包含关于源自 ISO 639 的主语言或扩展语言子标签 的分类信息。大多数语言的 scope 为 'individual'，这意味着 该语言不是宏语言、集合、特殊代码或私用。也就是说，它是 通常意义上的“一种语言”。任何没有 'Scope' 字段的主语言或 扩展语言子标签都是一种个体语言。 'Scope' 信息有时有助于选择语言标签，因为它指示 ISO 639 中 代码分配的目的或“范围”。可用值为： o 'macrolanguage' - 表示 ISO 639-3 定义的宏语言（见 第 3.1.10 节）。宏语言是一组关系密切、在某些情况下被 视为单一语言的语言簇。 o 'collection' - 表示代表一组语言的子标签，这些语言通常 通过某种历史、地理或语言学关联联系在一起。与宏语言 Phillips & Davis 最佳当前实践 [第 33 页]
RFC 5646 语言标签 2009 年 9 月 不同，集合可以包含只有松散关联的语言，且集合不能与 属于它的语言互换使用。 o 'special' - 表示特殊语言代码。这些子标签用于标识并不 特别与某种具体语言相关联的语言属性。这包括语言未定 或非语言内容的代码。 o 'private-use' - 表示底层标准中保留用于私用的代码。具有 此 scope 的子标签可用于表示没有 ISO 639 或已注册分配的 主语言。 'Scope' 字段 MAY 出现在类型为 'language' 或 'extlang' 的记录 中。注意，许多扩展语言子标签的前缀将具有 'macrolanguage' 的 'Scope'（尽管有些不会），且许多具有 'macrolanguage' 'Scope' 的语言会有与其相关联的扩展语言子标签。 'Scope' 字段 MAY 通过注册过程添加、修改或移除，前提是 该变更反映 ISO 639 对该分配分类所作的变更。预计这种变更 很少发生。 例如，主语言子标签 'zh'（中文）具有 'macrolanguage' 的 'Scope'，而其所包含的语言 'nan'（闽南语）具有 'individual' 的 'Scope'。特殊值 'und'（未定）具有 'special' 的 'Scope'。 ISO 639-5 集合 'gem'（日耳曼语族）具有 'collection' 的 'Scope'。 3.1.12. Comments 字段 字段 'Comments' 包含关于记录的附加信息，并且 MAY 在每条 记录中出现多次。field-body MAY 包含完整范围的 Unicode 字符，且不受任何特定文字限制。该字段 MAY 通过注册过程 插入或更改，且不提供稳定性保证。 该字段的内容不受限制，但受注册信息的需要、请求的适宜性 以及合理实际大小限制的约束。'Comments' 字段的主要原因是 子标签标识——帮助将该子标签与可能混淆的其他子标签区分 开来，作为使用上的辅助。关于子标签使用、历史或一般背景 的大量信息不受鼓励，因为这些通常属于注册请求，而不是 注册表。 Phillips & Davis 最佳当前实践 [第 34 页]
RFC 5646 语言标签 2009 年 9 月 3.2. 语言子标签审查员 语言子标签审查员主持 ietf-languages@iana.org 邮件列表， 响应注册请求，并履行第 3.3 节中描述的其他注册表维护 职责。只有语言子标签审查员被允许请求 IANA 对语言子标签 注册表中的记录进行更改、更新或添加。语言子标签审查员 MAY 根据需要委派列表主持和其他文书职责。 语言子标签审查员由 IESG 任命，任期不定，但可由 IESG 酌情免职或更换。IESG 将征集该职位的提名人（在本文档 被采纳时或出现空缺时），然后征集关于提名人资格的反馈。 合格候选人应熟悉 BCP 47 及其要求；愿意公平、及时、审慎地 管理注册过程；并且充分了解语言标识方面的问题，以便 审查员能够评估主张，并借助语言专家和子标签请求者的 贡献。 语言子标签审查员后续的履职或决定 MAY 按照与其他 IETF 决定相同的规则向 IESG 提起申诉（见 [RFC2026]）。IESG 可以 撤销或推翻语言子标签审查员的决定，提供指导，或采取其他 适当行动。 3.3. 注册表的维护 注册表的维护要求，当 ISO 639、ISO 15924、ISO 3166 和 UN M.49 分配或撤销代码时，语言子标签审查员 MUST 评估 每项变更，并根据本文档中的规则确定适当的行动方案。 此类更新遵循第 3.5 节中描述的注册过程。通常，语言子标签 审查员会填写并提交注册表单，从而为新的或更新的记录启动 该过程。如果这些标准之一发生变更，而语言子标签审查员 未及时这样做，则任何利害关系方 MAY 提交该表单。之后， 注册过程照常继续。 注意，某些注册会影响其他子标签——可能不止一个——例如当 某个区域子标签被弃用并改用新值时。语言子标签审查员负责 确保任何此类变更都被正确注册，且每项变更都需要自己的 注册表单。 Phillips & Davis 最佳当前实践 [第 35 页]
RFC 5646 语言标签 2009 年 9 月 语言子标签审查员 MUST 确保新子标签满足本文档其他地方 的要求（尤其是第 3.4 节中的要求），或提交该节所述的 适当注册表单以注册替代子标签。受某项变更影响的每个 单独子标签 MUST 以自己的注册表单和单独消息发送到 ietf-languages@iana.org 列表。 3.4. IANA 注册表项的稳定性 注册表中条目及其含义的稳定性，对语言标签的长期稳定性 至关重要。本节中的规则保证特定语言标签的含义会随时间 保持稳定且不会改变。 这些规则专门处理由 ISO 639、ISO 15924、ISO 3166 和 UN M.49 维护的代码发生变更（包括代码撤销和弃用）时， 如何反映到 IANA 语言子标签注册表中。向 IANA 语言子标签 注册表分配项 MUST 遵循以下稳定性规则： 1. 字段 'Type'、'Subtag'、'Tag' 和 'Added' 中的值 MUST NOT 更改，并保证随时间保持稳定。 2. 字段 'Preferred-Value' 和 'Deprecated' 中的值 MAY 通过 注册过程添加、更改或移除。这些变更 SHOULD 限于为 反映某个底层标准（ISO 639、ISO 15924、ISO 3166-1 或 UN M.49）中的变更而必要的变更，并且通常 'Preferred- Value' 的更改或移除专门限于区域代码。 3. 'Description' 字段中的值 MUST NOT 以会使任何现有标签 无效的方式更改。该描述 MAY 在范围上略微扩大、更改 以添加信息，或适应最常见的现代用法。例如，国家偶尔 会更改其名称；这方面的一个历史例子是 "Upper Volta" 更名为 "Burkina Faso"。 4. 对于类型为 'variant' 的现有记录，MAY 通过注册过程 添加字段 'Prefix' 中的值，前提是该 'variant' 已经 至少有一个 'Prefix'。对于任何没有现有 'Prefix' 字段 的 'variant'，SHALL NOT 注册 'Prefix' 字段。如果向 变体记录添加前缀，MAY 使用 'Comment' 字段解释不同 前缀下的不同用法。 Phillips & Davis 最佳当前实践 [第 36 页]
RFC 5646 语言标签 2009 年 9 月 5. 类型为 'variant' 的记录中的字段 'Prefix' 的值 MAY 被修改，只要这些修改扩大前缀集合即可。也就是说， 一个前缀 MAY 被其自身的某个前缀替换。例如，前缀 "en-US" 可被 "en" 替换，但不能被前缀 "en-Latn"、 "fr" 或 "en-US- boont" 替换。如果需要其中某个前缀值，则必须单独 注册。 6. 类型为 'extlang' 的记录中的字段 'Prefix' 的值 MUST NOT 被添加、修改或移除。 7. 字段 'Prefix' MUST NOT 从任何包含它的记录中移除。 该字段 SHOULD 包含在任何类型为 'variant' 的记录的 初始注册中，并且 MUST 包含在任何类型为 'extlang' 的 记录中。 8. 字段 'Comments' MAY 通过注册过程或本节中描述的任何 过程或考虑事项添加、更改、修改或移除。 9. 字段 'Suppress-Script' MAY 通过注册过程添加或移除。 10. 字段 'Macrolanguage' MAY 通过注册过程添加或移除，但 只能响应 ISO 639 作出的变更。当某种语言在 ISO 639 中有对应宏语言时，就会出现 'Macrolanguage' 字段。 也就是说，注册表中的 'Macrolanguage' 字段与 ISO 639 中的字段完全匹配。不会考虑注册任何其他宏语言映射。 11. 字段 'Scope' MAY 在初始注册之后添加到主语言或扩展 语言子标签中，或从其中移除，并且 MAY 修改以匹配 ISO 639 作出的任何变更。对 'Scope' 字段的变更 MUST 反映 ISO 639 作出的变更。注意，其记录不包含 'Scope' 字段的主语言或扩展语言子标签（也就是其中大多数）， 是第 3.1.11 节中所述的个体语言。 12. 主语言和扩展语言子标签（使用注册过程创建的独立注册 值除外）根据 ISO 639 各部分的分配创建，如下： A. ISO 639-1 分配的代码，如果不与现有两字母主语言 子标签冲突，并且注册表中没有已定义的对应三字母 主语言，则作为类型为 'language' 的新记录录入 IANA 注册表。注意，被赋予 ISO 639-1 代码的语言 不能被赋予扩展语言子标签，即使它被某个宏语言 涵盖也是如此。 Phillips & Davis 最佳当前实践 [第 37 页]
RFC 5646 语言标签 2009 年 9 月 B. ISO 639-3 或 ISO 639-5 分配的代码，如果不与现有 三字母主语言子标签冲突，并且没有被分配（或预期 被分配）ISO 639-1 代码，则作为类型为 'language' 的新记录录入 IANA 注册表。注意，这两个标准现在 构成 ISO 639-2 代码的超集。在注册时已定义 'macrolanguage' 映射的代码 MUST 包含一个 'Macrolanguage' 字段。 C. ISO 639-3 分配的代码 MAY 也被考虑用于扩展语言 子标签注册。注意，即使提出的是 'extlang' 记录， 它们也 MUST 被分配一个类型为 'language' 的主语言 子标签记录。在考虑扩展语言子标签分配时，适用 以下标准： 1. 如果一种语言具有宏语言映射，并且该宏语言还有 其他被赋予扩展语言子标签的被涵盖语言，则该 新语言 SHOULD 也被分配一个 'extlang' 记录。 例如，任何以 'zh' 或 'ar' 为宏语言的语言都会 被分配一个 'extlang' 记录。 2. 如果宏语言所涵盖的其他语言也未包含 'extlang' 记录，则 SHOULD NOT 为这些语言创建 'extlang' 记录。例如，如果注册一种新的塞尔维亚-克罗地亚语 （'sh'），它不会得到 extlang 记录，因为所涵盖的 其他语言，如塞尔维亚语（'sr'），在注册表中也 不包含此类记录。 3. 手语 SHOULD 具有一个 'Prefix' 为 'sgn' 的 'extlang' 记录。 4. MUST NOT 为已经在注册表中的项目创建 'Extlang' 记录。扩展语言子标签只会在初始注册时被考虑。 5. 扩展语言子标签记录 MUST 包含字段 'Prefix' 和 'Preferred-Value'，其字段值按第 2.2.2 节所述 分配。 D. ISO 639-2 分配的任何其他代码，如果不与现有三字母 主语言或扩展语言 Phillips & Davis 最佳当前实践 [第 38 页]
RFC 5646 语言标签 2009 年 9 月 子标签冲突，并且没有被分配 ISO 639-1 两字母代码， 则作为类型为 'language' 的新记录录入 IANA 注册表。 此类注册不应在未来发生。 13. ISO 15924 和 ISO 3166-1 分配的代码，如果不与相关类型 的现有子标签冲突，且其含义不同于同类型的现有子标签， 则作为新记录录入 IANA 注册表。 14. ISO 639、ISO 15924 或 ISO 3166-1 分配的代码，如果被 其各自的维护或注册机构撤销，则仍可在语言标签中保持 有效。MUST 向记录添加一个包含撤销日期的 'Deprecated' 字段。如果添加了同类型的新记录来表示替代值，则 MAY 也添加一个 'Preferred-Value' 字段。注册过程 MAY 用于 添加关于相应标准撤销该代码的注释。 例如：区域代码 'TL' 被分配给国家 'Timor-Leste'， 替代代码 'TP'（后者在该地由葡萄牙管理时分配给 'East Timor'）。子标签 'TP' 在语言标签中仍有效， 但其记录包含 'Preferred-Value' 'TL'，且其字段 'Deprecated' 包含新代码被分配的日期（'2004-07-06'）。 15. ISO 639、ISO 15924 或 ISO 3166-1 分配的代码，如果 与相关类型的现有子标签冲突，包括与已弃用的子标签 冲突，MUST NOT 录入注册表。以下附加考虑适用于被重新 分配的子标签值： A. 对于 ISO 639 代码，如果新分配代码的含义未由 IANA 注册表中的某个子标签表示，则语言子标签审查员 SHALL 按第 3.5 节所述，尽快准备一份提案，将一个 已注册语言子标签作为该新代码的替代值录入 IANA 注册表。已注册语言子标签的形式由语言子标签审查员 酌情决定，并且 MUST 符合本文档中对语言子标签的 其他限制。 B. 对于其含义源自外部标准（即由 ISO 639、ISO 15924、 ISO 3166-1 或 UN M.49 定义）的所有子标签，如果 某个现有代码被分配了新含义，并且新含义扩大了该 代码的含义，则相关子标签的含义 MAY 更改以匹配。 Phillips & Davis 最佳当前实践 [第 39 页]
RFC 5646 语言标签 2009 年 9 月 然而，子标签的含义 MUST NOT 被缩小，因为这可能 导致现有子标签用法中未知比例的用法变为无效。 注意：ISO 639 注册机构（RA）已采用类似的稳定性 策略。 C. 对于 ISO 15924 代码，如果新分配代码的含义未由 IANA 注册表中的某个子标签表示，则语言子标签审查员 SHALL 按第 3.5 节所述，尽快准备一份提案，将一个 已注册变体子标签作为该新代码的替代值录入 IANA 注册表。已注册变体子标签的形式由语言子标签审查员 酌情决定，并且 MUST 符合本文档中对变体子标签的 其他限制。 D. 对于 ISO 3166-1 代码，如果新分配代码的含义与 另一个 'region' 子标签关联到同一个 UN M.49 代码， 则现有区域子标签仍作为该区域的首选值，并且不会 创建新条目。MAY 向现有区域子标签添加注释，说明 其与新 ISO 3166-1 代码的关系。 E. 对于 ISO 3166-1 代码，如果新分配代码的含义关联到 一个未由现有区域子标签表示的 UN M.49 代码，则语言 子标签审查员 SHALL 按第 3.5 节所述，准备一份提案， 将适当的 UN M.49 国家代码作为条目录入 IANA 注册表。 F. 对于 ISO 3166-1 代码，如果没有关联的 UN 数字代码， 则语言子标签审查员 SHALL 请求 UN 创建一个。如果 自请求发送之日起 90 天内 UN 没有回应，则语言子标签 审查员 SHALL 尽快准备一份提案，将一个已注册变体 子标签作为该新代码的替代值录入 IANA 注册表。已注册 变体子标签的形式由语言子标签审查员酌情决定，并且 MUST 符合本文档中对变体子标签的其他限制。这种情况 极不可能发生。 16. UN M.49 同时具有“国家和地区”的代码（例如德国的 '276'）以及“地理区域和次区域”的代码（例如欧洲的 '150'）。没有对应 ISO 3166-1 代码的 UN M.49 国家或 地区代码 MUST NOT 被注册，除非它作为某个因现有子标签 而被阻止注册的 ISO 3166-1 代码的替代。 Phillips & Davis 最佳当前实践 [第 40 页]
RFC 5646 语言标签 2009 年 9 月 如果此类代码变为必要，则 SHALL 首先请求 ISO 3166-1 的维护机构为该区域分配一个代码。如果 ISO 3166-1 的 代码分配请求被拒绝或未被及时处理，则可使用第 3.5 节 中描述的注册过程来注册对应的 UN M.49 代码。这样， 在 ISO 3166-1 重新分配注册表中已弃用值的情况下， UN M.49 代码仍可作为最后手段的值。 17. 冗余条目和祖父条目共同构成根据 [RFC3066] 注册的 标签完整列表。冗余标签是那些以前注册、现在可使用 注册表中定义的子标签形成的标签。祖父条目包括那些 永远不能合法的条目，因为它们是 'irregular'（即它们 不匹配图 1 中的 'langtag' 产生式）、受规则限制（如 'nyn' 和 'min' 这样的子标签看起来像 extlang 产生式， 但不能注册为扩展语言子标签），或其子标签不适合注册。 所有祖父标签都列在 ABNF 的 'regular' 或 'irregular' 产生式中。在 [RFC4646] 下，祖父标签有可能变为冗余。 然而，所有可能发生这种情况的标签在本文档生成之前 已经变为冗余。因此，冗余标签和祖父标签的集合现在是 永久且不可变的：MUST NOT 添加任何一种类型的新条目， 且现有条目 MUST NOT 被移除。关于哪些标签最初被列为 祖父标签、哪些变为冗余标签的决策过程，见 [RFC4645]。 许多祖父标签已被弃用——实际上，它们甚至在 [RFC4646] 之前就已被弃用。例如，标签 "art-lojban" 被弃用，改用 主语言子标签 'jbo'。这些标签本可通过将其部分子标签 注册为 'variants' 而变为 'redundant'。祖父注册项中的 “类似变体”的子标签 SHALL NOT 在未来注册，即使具有相似 或相同含义也不行。 3.5. 子标签注册程序 任何想使用当前不在 IANA 语言子标签注册表中的子标签的人， 或希望按本文档允许的方式添加、修改、更新或移除现有记录 中信息的人，MUST 使用此处给出的程序。 只有类型为 'language' 和 'variant' 的子标签会被考虑用于 新子标签的独立注册。为 Phillips & Davis 最佳当前实践 [第 41 页]
RFC 5646 语言标签 2009 年 9 月 稳定性而需要的子标签，以及为了在本文档定义的限制内保持 注册表与 ISO 639、ISO 15924、ISO 3166 和 UN M.49 同步所 必需的子标签，也使用此过程，如第 3.3 节所述，并受 第 3.4 节所述稳定性规定的约束。 注册请求接受与子标签记录中 'Comments'、'Deprecated'、 'Description'、'Prefix'、'Preferred-Value'、'Macrolanguage' 或 'Suppress-Script' 字段的信息有关的事项，如第 3.4 节 所述。IANA 注册表中所有其他字段的变更均不被允许。 注册新子标签或请求修改现有标签或子标签，始于请求者填写 下方重现的注册表单。注意，每项响应的大小不受限制，以便 请求能够充分描述该注册。在记录获批之前，"Record Requested" 部分中的字段需要遵循第 3.1 节中的要求。 LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: 2. E-mail address of requester: 3. Record Requested: Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Macrolanguage: Comments: 4. Intended meaning of the subtag: 5. Reference to published description of the language (book or article): 6. Any other relevant information: 图 5：语言子标签注册表单 已完成注册表单的示例可在附录 B中找到。完整的已批准 注册表单列表可通过 http://www.iana.org 在线获得；读者应 注意，Language Tag Registry 现在已废止，应改为查找 Language Subtag Registry。 Phillips & Davis 最佳当前实践 [第 42 页]
RFC 5646 语言标签 2009 年 9 月 子标签注册表单 MUST 发送至 <ietf-languages@iana.org>。注册 请求在获批并提交给 IANA 以纳入注册表之前，会有两周的审查期。 如果在注册过程中对请求进行了修改（例如为满足第 3.1 节 中的要求而进行修正，或使 'Description' 字段在给定记录类型 中唯一），修改后的表单 MUST 也在提交给 IANA 至少一周前 发送至 <ietf-languages@iana.org>。 ietf-languages 列表是开放列表，可通过向 <ietf-languages-request@iana.org> 发送请求加入。该列表可由 IANA 托管，也可应 IESG 请求由任何第三方托管。 在将任何注册转发给 IANA 之前，语言子标签审查员 MUST 确保 满足本文档中的所有要求。这包括确保 'Subtag' 字段中的值 按第 3.1.4 节中的描述匹配大小写，并确保 'Description' 字段按第 3.1.5 节所述在给定记录类型中唯一。审查员 MUST 还确保请求中包含适当的 File-Date 记录，以协助 IANA 更新 注册表（见第 5.1 节）。 注册表单以及注册表记录本身中的某些字段允许使用非 ASCII 字符。为保持一致性和清晰性，注册请求 SHOULD 使用 UTF-8 编码。然而，由于某些邮件客户端不支持这种编码，注册请求 MAY 使用其他编码。语言子标签审查员负责确保归档的请求表单 和注册表记录中都出现正确的 Unicode 字符。如果 IANA 出现 转写或编码错误，语言子标签审查员将请求修复注册表，并向 IANA 提供任何必要的协助信息。 扩展语言子标签（类型 'extlang'）按定义始终被另一种语言 涵盖。因此，所有类型为 'extlang' 的记录 MUST 在注册时包含 一个 'Prefix' 字段。此 'Prefix' 字段永远不能更改或移除， 且这样做的请求 MUST 被拒绝。 变体子标签通常注册用于某个特定范围的语言标签，并鼓励 基于其所适用语言术语的变体子标签。例如，子标签 'rozaj' （Resian）旨在与以主语言子标签 "sl"（斯洛文尼亚语）开头 的语言标签一起使用，因为 Resian 是斯洛文尼亚语的一种方言。 因此，子标签 'rozaj' 适合用于 "sl-Latn-rozaj" 或 "sl-IT-rozaj" 等标签中。此信息存储在注册表中的 'Prefix' 字段中。变体 Phillips & Davis 最佳当前实践 [第 43 页]
RFC 5646 语言标签 2009 年 9 月 注册请求 SHOULD 在注册表单中至少包含一个 'Prefix' 字段。 请求为给定类型分配具有现有子标签值的附加记录，MUST 被拒绝。 例如，变体子标签 'rozaj' 已存在于注册表中，因此禁止添加 第二条类型为 'variant' 且子标签为 'rozaj' 的记录。 给定已注册变体子标签的 'Prefix' 字段存在于 IANA 注册表中， 作为使用指南。MAY 通过提交附加注册表单来添加额外的 'Prefix' 字段。在该表单中，"Any other relevant information:" 字段 MUST 指明这是添加前缀。 请求向变体子标签添加会暗示不同语义含义的 'Prefix' 字段， SHOULD 被拒绝。例如，请求向子标签 '1994' 添加前缀 "de"， 使标签 "de-1994" 表示某种德语方言或正字法形式，将被拒绝。 '1994' 子标签表示一种特定的斯洛文尼亚语正字法，而附加 注册会改变或模糊分配给该子标签的语义含义。应改为提出 一个单独的子标签。 向当前没有 'Prefix' 字段的变体子标签添加 'Prefix' 的请求 MUST 被拒绝。变体在注册时没有前缀，是因为它们可能可用于 许多甚至所有语言。添加一个或多个 'Prefix' 字段可能会损害 该变体的使用，因为这会显著缩小子标签的范围（这在稳定性 规则（第 3.4 节）下是不允许的），而不是扩大子标签的范围， 后者才是添加 'Prefix' 通常会产生的效果。此类“无前缀” 变体的一个示例是子标签 'fonipa'，它表示国际音标，这是一种 可用于转写许多语言的方案。 请求中提供的 'Description' 字段 MUST 至少包含一个以拉丁文字 书写或转写的描述；该请求 MAY 还包含以任何文字或语言书写的 其他 'Description' 字段。'Description' 字段用于标识目的， 并不一定表示该语言或变体的实际本地名称。它也不必采用任何 特定语言，但 SHOULD 适合且足以标识记录中的项目。语言子标签 审查员将检查并编辑任何拟议的 'Description' 字段，以确保 唯一性并防止与同类型其他记录中的 'Description' 字段发生冲突。 如果这种情况发生在独立注册请求中，语言子标签审查员 MUST 将该记录重新提交至 <ietf-languages@iana.org>，将其视为因讨论 而对请求作出的修改， Phillips & Davis 最佳当前实践 [第 44 页]
RFC 5646 语言标签 2009 年 9 月 如第 3.5 节所述，除非该请求的唯一目的就是引入重复的 'Description' 字段，在这种情况下该请求 SHALL 被拒绝。 'Description' 字段不保证稳定。意图的更正或澄清是可能的 变更示例。试图为注册表中的条目提供翻译或转写（按定义， 这些不提供新信息）不太可能被批准。 在两周审查期结束后不久，语言子标签审查员 MUST 采取以下 行动之一： o 明确接受该请求，并按照第 3.3 节中描述的程序，将包含 待插入或修改记录的表单转发至 <iana@iana.org>。 o 由于列表上提出了重大异议，或由于与本文档中的约束存在 问题（MUST 明确引用这些约束），明确拒绝该请求。 o 通过额外授予一个两周期限来延长审查期，以允许进一步讨论。 在每个额外的两周期限之后，语言子标签审查员 MUST 在列表上 指明注册已被接受、拒绝还是继续延长。 注意，如果语言子标签审查员愿意，他或她 MAY 在列表上提出 异议。重要的是，该异议 MUST 公开提出。 有时，由于审查期间的讨论或本文档中的要求，请求需要被修改。 申请人、语言子标签审查员或其他人 MAY 提交已完成注册表单的 修改版本，在申请人明确同意的情况下，该修改版本将取代原始 请求被考虑。此类变更不会重新开始两周讨论期，尽管包含提交 给 IANA 的最终记录的申请 MUST 在语言子标签审查员将记录转发 给 IANA 至少一周前出现在列表上。申请人 MAY 使用更适当或 附加的信息修改被拒绝的申请并再次提交；这将开始新的两周 评论期。 根据第 3.3 节或第 3.4 节规定发起的注册 SHALL NOT 被完全 拒绝（因为它们最终必须出现在注册表中），并且 SHOULD 尽快 完成。审查过程允许列表成员对表单中的具体信息及其包含的记录 发表评论，并 Phillips & Davis 最佳当前实践 [第 45 页]
RFC 5646 语言标签 2009 年 9 月 因而帮助确保其正确且一致。语言子标签审查员 MAY 拒绝表单的 某个特定版本，但 MUST 提出合适的替代版本，并按上述方式延长 审查期，直到表单格式值得审查员批准，并获得列表的粗略共识。 语言子标签审查员作出的决定 MAY 按与其他 IETF 决定相同的 规则，向 IESG [RFC2028] 提起申诉 [RFC2026]。这包括 延长审查期的决定，或未能以清晰及时的方式宣布决定。 已批准的记录出现在语言子标签注册表中。已批准的注册表单 可从 http://www.iana.org 在线获得。 对现有记录的更新或变更遵循与新注册相同的程序。语言子标签 审查员在两周审查期后决定是否存在更新注册的共识；通常， 原注册人的异议在形成此类共识时会具有额外权重。 注册是永久且稳定的。一旦注册，子标签将不会从注册表中移除， 并将继续作为指定特定语言或变体的有效方式。 注：注册表单中 "Reference to published description" 部分的 目的，是帮助验证某种语言是否已注册，或某个特定子标签指向 哪种语言或语言变体。在多数情况下，引用该语言的权威语法书 或词典会有帮助；在不存在此类作品的情况下，描述该语言或以 该语言写成的其他知名作品 MAY 是适当的。语言子标签审查员 决定什么构成“足够好”的参考材料。此要求并不旨在因说话者 人口规模或缺乏标准化正字法而排除特定语言或方言。少数民族 语言将按其自身价值受到同等考虑。 3.6. 可注册的可能事项 子标签或子标签相关信息的可注册事项包括： o 对于未列于 ISO 639 中，且不是任何已列出或已注册语言 的变体的语言，MAY 注册主语言子标签。在本文档创建时， 没有这种形式子标签的示例。在尝试注册语言子标签之前， MUST 先尝试将该语言注册到 Phillips & Davis 最佳当前实践 [第 46 页]
RFC 5646 语言标签 2009 年 9 月 ISO 639。对于由 ISO 639-1、ISO 639-2 或 ISO 639-3 中 已存在代码定义的语言；正在由 ISO 639 注册机构考虑的 语言；或从未尝试向这些机构注册的语言，MUST NOT 注册 子标签。如果 ISO 639 先前已拒绝某种语言的注册，则可 合理假定，在它作为主语言子标签注册到 IANA 注册表之前， 必须存在额外且非常有说服力的需求证据（以至于这种类型的 子标签极不可能被注册）。 o 语言内部的方言或其他划分或变体、其正字法、书写系统、 区域或历史用法、转写或其他转换，或可区分变体，MAY 注册为变体子标签。一个示例是 'rozaj' 子标签（斯洛文尼亚语 的 Resian 方言）。 o 允许按第 3.1 节所述添加或维护标签或子标签记录中的 字段（通常为资料性）。此类变更受第 3.4 节中稳定性 规定的约束。这包括过时或撤销代码的 'Description'、 'Comments'、'Deprecated' 和 'Preferred-Value' 字段， 或向主语言子标签添加 'Suppress-Script' 或 'Macrolanguage' 字段，以及本文档允许的其他变更，例如向变体子标签添加 适当的 'Prefix' 字段。 o 允许添加记录和相关字段值变更，以反映 ISO 639、ISO 15924、 ISO 3166-1 和 UN M.49 按第 3.4 节所述作出的分配。 拟议注册的子标签如果会导致祖父标签的全部或部分变为冗余， 但其含义与该祖父标签的含义冲突或改变其含义，MUST 被拒绝。 本文档将哪些子标签或对子标签的变更适当（或不适当）的决定 留给第 3.5 节中描述的注册过程。 注：四字符主语言子标签被保留，以允许 ISO 639 标准族未来 某些新增部分中可能出现 alpha4 代码。 ISO 639 为 ISO 639 语言列表中的添加和变更定义了一个注册 机构。该机构是： Phillips & Davis 最佳当前实践 [第 47 页]
RFC 5646 语言标签 2009 年 9 月 International Information Centre for Terminology (Infoterm) Aichholzgasse 6/12, AT-1120 Wien, Austria Phone: +43 1 26 75 35 Ext. 312 Fax: +43 1 216 32 72 ISO 639-2 为 ISO 639-2 语言列表中的添加和变更定义了一个 注册机构。该机构是： Library of Congress Network Development and MARC Standards Office Washington, DC 20540, USA Phone: +1 202 707 6237 Fax: +1 202 707 0115 URL: http://www.loc.gov/standards/iso639-2 ISO 639-3 为 ISO 639-3 语言列表中的添加和变更定义了一个 注册机构。该机构是： SIL International ISO 639-3 Registrar 7500 W. Camp Wisdom Rd. Dallas, TX 75236, USA Phone: +1 972 708 7400, ext. 2293 Fax: +1 972 708 7546 Email: iso639-3@sil.org URL: http://www.sil.org/iso639-3 ISO 639-5 为 ISO 639-5 语言列表中的添加和变更定义了一个 注册机构。该机构与 ISO 639-2 相同，即： Library of Congress Network Development and MARC Standards Office Washington, DC 20540, USA Phone: +1 202 707 6237 Fax: +1 202 707 0115 URL: http://www.loc.gov/standards/iso639-5 ISO 3166-1（国家代码）的维护机构是： ISO 3166 Maintenance Agency c/o International Organization for Standardization Case postale 56 CH-1211 Geneva 20, Switzerland Phone: +41 22 749 72 33 Fax: +41 22 749 73 49 URL: http://www.iso.org/iso/en/prods-services/iso3166ma/index.html Phillips & Davis 最佳当前实践 [第 48 页]
RFC 5646 语言标签 2009 年 9 月 ISO 15924（文字代码）的注册机构是： Unicode Consortium Box 391476 Mountain View, CA 94039-1476, USA URL: http://www.unicode.org/iso15924 United Nations Secretariat 的 Statistics Division 维护 Standard Country or Area Codes for Statistical Use，可通过以下 方式联系： Statistical Services Branch Statistics Division United Nations, Room DC2-1620 New York, NY 10017, USA Fax: +1-212-963-0623 Email: statistics@un.org URL: http://unstats.un.org/unsd/methods/m49/m49alpha.htm 3.7. 扩展和扩展注册表 扩展子标签是由除 'x' 以外的单字符子标签（"singletons"） 引入的子标签。它们保留用于生成包含语言组件，并且与理解 语言标签的应用兼容的标识符。 扩展的结构和形式由本文档定义，使实现能够与未来可能使用 singleton 创建的应用保持向前兼容。此外，定义维护 singleton 的机制将通过减少未来修订或更新的可能需求，增强本文档的 稳定性。 单字符子标签由 IANA 使用 [RFC5226] 定义的 “IETF Review” 策略分配。该策略要求制定一个 RFC，该 RFC SHALL 定义用于 维护这些子标签的名称、目的、流程和程序。RFC 中 MUST 明确 指明维护或注册机构，包括名称、联系电子邮件、讨论列表 电子邮件以及注册表的 URL 位置。RFC MUST 指定或包含以下 每一项： o 规范 MUST 引用管辖其创建的本文档的具体版本或修订版， 并且 MUST 引用本文档的本节。 o 规范以及该规范定义的所有子标签 MUST 遵循本文档中定义的 标签和子标签形成所用的 ABNF 和其他规则。特别是，它 MUST Phillips & Davis 最佳当前实践 [第 49 页]
RFC 5646 语言标签 2009 年 9 月 指定大小写不重要，且子标签 MUST NOT 超过八个字符长。 o 规范 MUST 指定规范表示。 o 有效子标签的规范 MUST 可通过 Internet 免费获得。 o 规范 MUST 属于公有领域，或通过 IETF 可接受并在 RFC 中 指定的免版税许可提供。 o 规范 MUST 进行版本化，并且规范的每个版本 MUST 编号、 注明日期且保持稳定。 o 规范 MUST 稳定。也就是说，扩展子标签一旦由规范定义， MUST NOT 被撤回，或以任何实质方式改变含义。 o 规范 MUST 在单独一节中包含本节（下文）重现的注册表单， 用于在作为 RFC 发布时注册该扩展。 o 联系信息和规范 URL 的变更 MUST 通知 IANA。 IANA 将维护一个已分配单字符（singleton）子标签的注册表。 该注册表 MUST 使用第 3.1.1 节中 ABNF 描述的 record-jar 格式。当扩展作为 RFC 发布时，RFC 中定义的维护机构 MUST 将 该注册表单转发给 <iesg@ietf.org>，后者 MUST 将请求转发给 <iana@iana.org>。扩展的维护机构 MUST 在内容发生变更时， 以主题行 "LANGUAGE TAG EXTENSION UPDATE" 向 <iana@iana.org> 发送该记录的更新完整副本，从而维护记录的准确性。这些更新 中只有 'Comments'、'Contact_Email'、'Mailing_List' 和 'URL' 字段 MAY 被修改。 未能维护此记录、维护对应注册表，或满足本文档本节施加的 其他条件，MAY 按与其他 IETF 决定相同的规则向 IESG [RFC2028] 提起申诉（见 [RFC2026]），并且 MAY 导致维护 该扩展的权限被 IESG 撤销或重新分配。 Phillips & Davis 最佳当前实践 [第 50 页]
RFC 5646 语言标签 2009 年 9 月 %% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %% 图 6：Language Tag Extensions Registry 中的记录格式 'Identifier' 包含分配给该扩展的单字符子标签（singleton）。 为定义该扩展而提交的 Internet-Draft SHOULD 指定使用哪个 字母或数字，尽管 IESG MAY 在批准 RFC 时更改该分配。 'Description' 包含该扩展的名称和描述。 'Comments' 是一个 OPTIONAL 字段，MAY 包含该扩展的更宽泛 描述。 'Added' 包含扩展 RFC 的发布日期，采用 [RFC3339] 中指定的 "full-date" 格式。例如：2004-06-28 表示公历 2004 年 6 月 28 日。 'RFC' 包含分配给该扩展的 RFC 编号。 'Authority' 包含该扩展维护机构的名称。 'Contact_Email' 包含用于联系维护机构的电子邮件地址。 'Mailing_List' 包含维护机构所用邮件列表的 URL 或订阅电子 邮件地址。 'URL' 包含此扩展注册表的 URL。 关于某个 Internet-Draft 是否满足上述条件，以及授予或拒绝 此类权限的决定，完全由 IESG 作出，并受与 RFC 过程相关的 正常审查和申诉流程约束。 强烈提醒扩展作者，许多处理器（包括大多数格式良好的处理器） 不会意识到扩展子标签顺序中固有的任何特殊关系 Phillips & Davis 最佳当前实践 [第 51 页]
RFC 5646 语言标签 2009 年 9 月 或含义。扩展作者 SHOULD 避免会干扰匹配，或干扰使用该扩展的 常见协议中有时存在的长度限制的子标签关系或规范化机制。 特别是，应用在进行匹配或适配有限长度时 MAY 截断子标签， 因此 RECOMMENDED 将最重要的信息放在最重要的（最左侧） 子标签中，并且规范应能优雅地处理被截断的子标签。 当语言标签要用于某个特定的已知协议时，RECOMMENDED 语言 标签不包含该协议不支持的扩展。此外，注意某些协议 MAY 对 用于存储或传输语言标签的字符串长度施加上限。 3.8. 语言子标签注册表的更新 在本文档被采纳后，IANA 语言子标签注册表需要一次更新， 以便它包含语言标签中有效的完整子标签集合。[RFC5645] 描述了 创建此更新所使用的过程。 当本文档被采纳时，按照 [RFC4646] 中定义的规则正在进行的 注册 MUST 按本文档中包含的规则完成。 3.9. 子标签注册表的适用性 语言子标签注册表是用于构造语言标签的数据元素来源，遵循 本文档中描述的规则。语言标签旨在表示各种内容的语言属性， 不仅包括文本，也包括大多数媒体格式，例如视频或音频。它们 也构成各种协议和 API 中语言及区域设置协商的基础。 因此，注册表适用于许多需要某种语言标识形式的应用，但有 以下限制： o 它并非设计为创建语言选择用户界面时的唯一数据源。例如， 注册表不包含子标签描述或由这些子标签组成的标签的翻译。 基于注册表的本地化数据来源通常可用，尤其是 [CLDR]。 注册表也不指明哪些子标签组合特别有用或相关。 Phillips & Davis 最佳当前实践 [第 52 页]
RFC 5646 语言标签 2009 年 9 月 o 它不提供表示不同语言之间关系的信息，例如可用于在用户界面中 以层级、区域或某种其他组织模型选择语言标签的信息。 o 它不提供关于不同语言标签之间潜在重叠的信息，因为何为 语言这一概念并不精确：对于同一给定内容片段，可能有若干 不同语言标签都是合理选择。 o 在执行语言协商时，它不包含关于适当回退选择的信息。良好的 回退语言可能在语言学上与指定语言无关。一种语言经常作为 另一种语言的回退语言，这一事实通常是外部因素的结果，例如 地理、历史或文化——这些因素并不一定适用于所有情况。例如， 大多数使用布列塔尼语（一种在法国西北部使用的凯尔特语言） 的人，如果布列塔尼语不可用，可能会更愿意获得法语（一种 罗曼语）的服务。 4. 语言标签的形成和处理 本节说明如何结合标签语法使用注册表中的信息，以选择、形成 和处理语言标签。 4.1. 语言标签的选择 形成语言标签的指导原则是“明智地标记内容”。有时，对于同一 内容，存在多个可能标签可供选择。选择使用哪个标签取决于所涉 内容和应用，在选择标签时可能需要一定判断。 始终使用相同语言标签表示同一种语言，最有利于互操作性。如果 某个应用具有使这里的规则不适用的要求，则该应用有损害互操作性 的风险。强烈 RECOMMENDED 用户不要为语言标签选择定义自己的规则。 规范、协议和应用如果规范性引用本文档，但应用了不同于本节 所给规则的规则，MUST 指定语言标签选择如何不同于此处给出的 指南。 为确保一致的向后兼容性，本文档包含若干规定，以处理用于定义 构成语言标签的子标签的标准中可能存在的不稳定性。 Phillips & Davis 最佳当前实践 [第 53 页]
RFC 5646 语言标签 2009 年 9 月 这些规定意味着，没有任何有效语言标签会变为无效，语言标签 在未来也不会具有更窄的范围（它可能具有更宽的范围）。对于 给定应用或内容项，最合适的语言标签可能会随时间演变，但 一旦应用，该标签本身不会变为无效，也不会完全改变其含义。 只有当子标签能为标签增加有用的区分信息时，才 SHOULD 使用 该子标签。多余的子标签会干扰语言标签的含义、理解和处理。 特别是，用户和实现 SHOULD 遵循注册表中的 'Prefix' 和 'Suppress-Script' 字段（定义于第 3.1 节）：这些字段为 何时 SHOULD 在语言标签中使用或避免特定附加子标签提供指导。 用于形成语言标签的子标签选择 SHOULD 遵循以下指南： 1. 使用尽可能精确的标签，但不要比有正当理由时更具体。 避免使用对于在应用中区分内容并不重要的子标签。 * 例如，'de' 可能足以标记一封用德语写成的电子邮件， 而 "de-CH-1996" 对此类任务来说可能过于精确。 * 注意，某些子标签序列可能并不表示普通用户可能预期的 语言。例如，瑞士德语（Schweizerdeutsch）由 "gsw-CH" 表示，而不是由 "de-CH" 表示。后者表示在瑞士（'CH'） 使用的德语（'de'），也称为瑞士标准德语 （Schweizer Hochdeutsch）。二者都是真实语言，并且 区分它们对应用可能很重要。 2. 除非文字能为标签增加某些区分信息，否则 script 子标签 SHOULD NOT 用于形成语言标签。Script 子标签最早在 [RFC4646] 中被正式定义。它们的使用会影响 [RFC1766] 或 [RFC3066]（已由本文档废止）的实现中的匹配和子标签 标识，因为这些子标签出现在主语言和区域子标签之间。 只要在给定上下文中使用一致，某些应用可以从在语言标签中 使用 script 子标签获益。Script 子标签绝不适合未书写的 内容（例如录音）。注册表中主语言或扩展语言记录中的 'Suppress-Script' 字段指示那些对于多数应用不会增加 区分信息的 script 子标签；该字段 Phillips & Davis 最佳当前实践 [第 54 页]
RFC 5646 语言标签 2009 年 9 月 定义了用户何时 SHOULD NOT 将 script 子标签与特定主语言 子标签一起包含。 例如，如果某个实现使用 Basic Filtering [RFC4647] （最初描述于 [RFC2616] 第 14.4 节）选择内容，而用户 请求了语言范围 "en-US"，则标记为 "en-Latn-US" 的内容 不会匹配该请求，因此不会被选择。因此，了解何时通常会 使用 script 子标签以及何时不应使用它们非常重要。 例如： * 子标签 'Latn' 不应与主语言 'en' 一起使用，因为几乎 所有英文文档都用拉丁文字书写，它不会增加区分信息。 然而，如果某篇文档用英语书写，但混合了拉丁文字和 另一种文字（如盲文 'Brai'），则选择指明两种文字以 辅助内容选择（例如样式表的应用）可能是适当的。 * 标记未书写内容（如人类语音录音）时，即使该语言通常 用多种文字书写，也不应使用 script 子标签。因此， 某部电影的字幕可能使用标签 "uz-Arab"（乌兹别克语， 阿拉伯文字），但同一语言的音轨则会简单标记为 "uz"。 （当内容未书写时，也可以使用标签 "uz-Zxxx"，因为 子标签 'Zxxx' 表示“未书写文档代码”。） 3. 如果某个标签或子标签在其注册表项中具有 'Preferred-Value' 字段，则 SHOULD 优先使用该字段的值 来形成语言标签，而不是使用出现该首选值的标签或子标签。 * 例如，对 Lojban 使用 'jbo'，而不是祖父标签 "art-lojban"。 4. 优先使用表示个体语言的子标签或子标签序列，而不是表示 语言集合的子标签。“语言集合”是一组源自共同祖先、在同一 地理区域使用，或以其他方式相关的语言。某些语言集合由 [ISO639-5] 分配代码（其中一些 [ISO639-5] 代码也在 [ISO639-2] 中定义为集合）。这些代码作为主语言子标签包含 在注册表中。注册表中表示语言集合的子标签具有值为 'collection' 的 'Scope' 字段。表示语言集合的子标签 Phillips & Davis 最佳当前实践 [第 55 页]
RFC 5646 语言标签 2009 年 9 月 总是优先于较不具体的替代项，如 'mul' 和 'und'（见下文）， 并且在没有更具体的语言信息时，MAY 使用表示语言集合的 子标签。然而，大多数用户和实现并不知道集合与其个体语言 之间存在关系。此外，集合中个体语言之间的关系并未被良好 定义；特别是，这些语言通常并不能相互理解。由于子标签 不同，对集合的请求通常只会产生标记为该集合子标签的项目， 而不是产生用集合中个体语言子标签标记的项目。 * 例如，集合按包含方式解释，因此子标签 'gem'（日耳曼 语言）可以用于本应更适合用 "en"（英语）、"de"（德语） 或 "gsw"（瑞士德语，阿勒曼尼语）标记的内容，但 SHOULD NOT 这样使用。虽然 'gem' 汇集了所有这些（以及 其他）语言，但多数实现不会将 'gem' 匹配到个体语言； 因此，使用该子标签不会产生期望的结果。 5. [ISO639-2] 定义了若干包含在子标签注册表中的代码，在选择 语言标签时需要额外注意。在多数此类情况下，如果允许省略 语言标签，则省略优于使用这些代码。除非附加信息能为应用 传达某种价值，否则语言标签 SHOULD NOT 将这些子标签作为 前缀包含。 * 'mul'（Multiple）主语言子标签标识多语言内容。当可以 改用语言列表或为每个内容元素使用单独标签时，SHOULD NOT 使用该子标签。例如，'Content- Language' 头字段 [RFC3282] 允许使用语言列表，而不仅仅 是单个语言标签。 * 'und'（Undetermined）主语言子标签标识语言未确定的 语言内容。除非需要语言标签且语言信息不可用或无法 确定，否则 SHOULD NOT 使用该子标签。在允许的情况下， 省略语言标签是首选。对于要求提供语言标签的协议，或在 需要主语言子标签的场合（如 "und-Latn"），'und' 子标签 可能有用。在某些情况下匹配语言标签时，'und' 子标签 MAY 也有用。 Phillips & Davis 最佳当前实践 [第 56 页]
RFC 5646 语言标签 2009 年 9 月 * 'zxx'（Non-Linguistic, Not Applicable）主语言子标签 标识不适合或不适用语言分类的内容。一些示例可能包括 器乐或电子音乐；由非言语声音组成的录音；没有旁白、 对话、印刷标题或字幕的视听材料；由机器语言或字符代码 组成的机器可读数据文件；或编程源代码。 * 'mis'（Uncoded）主语言子标签标识语言已知但当前没有 对应子标签的内容。SHOULD NOT 使用该子标签。由于未来 添加其他代码可能使其应用无效，它本质上是不稳定的， 因此与 BCP 47 的稳定性目标不兼容。始终最好使用其他 子标签：要么使用 'und'，要么（经事先约定）使用私用 子标签。 6. 谨慎使用变体子标签，并按正确顺序使用。多数变体子标签 在注册表中有一个或多个 'Prefix' 字段，表示它们适用的 子标签列表。变体 SHOULD 只与出现在这些 'Prefix' 字段之一 中的子标签一起使用。如果某个变体在其某个 'Prefix' 字段中 列出第二个变体，则在任何同时出现二者的语言标签中，第一个 变体 SHOULD 直接出现在第二个变体之后。通用变体（完全没有 'Prefix' 字段的变体）SHOULD 出现在任何其他变体子标签之后。 对所有剩余变体排序时，将最重要的子标签放在前面。如果没有 哪个子标签更重要，或无法确定关系，则按字母顺序排列这些 子标签。由于变体非常专门化，同时使用多个变体通常会使标签 过于狭窄，从而抵消获得的附加精度。将子标签放入另一种顺序 会干扰互操作性以及标签的整体解释。 例如： * 标签 "en-scotland-fonipa"（英语，苏格兰方言，IPA 音标转写）排序正确，因为 'scotland' 的 'Prefix' 为 "en"，而 'fonipa' 没有 'Prefix' 字段。 * 标签 "sl-IT-rozaj-biske-1994" 排序正确：'rozaj' 将 "sl" 列为其唯一 'Prefix'；'biske' 将 "sl-rozaj" 列为其唯一 'Prefix'。子标签 '1994' 有多个前缀， Phillips & Davis 最佳当前实践 [第 57 页]
RFC 5646 语言标签 2009 年 9 月 包括 "sl-rozaj"。然而，它跟在 'rozaj' 和 'biske' 之后，因为其 'Prefix' 字段之一是 "sl-rozaj- biske"。 7. 祖父标签 "i-default"（默认语言）最初按照 [RFC1766] 注册，以满足 [RFC2277] 的需要。它不用于指示某种特定 语言，而是用于标识无法确定用户语言偏好的情况下所使用的 条件或内容。除非用于标记要求默认语言内容必须用该特定 标签标记的应用或协议中的默认内容，否则 SHOULD NOT 使用它。 它 MAY 也由应用或协议用于标识正在返回默认语言内容的情形。 4.1.1. 标记被涵盖语言 注册表中的某些主语言记录具有 'Macrolanguage' 字段 （第 3.1.10 节），该字段包含从每种“被涵盖语言”到其宏语言 的映射。'Macrolanguage' 映射不定义被涵盖语言与其宏语言 之间是什么关系，也不定义同一宏语言涵盖的语言彼此之间如何 相关。由同一宏语言涵盖的两种不同语言之间的差异，可能比 法语和西班牙语之间的差异还要大。 少数特定宏语言，如中文（'zh'）和阿拉伯语（'ar'），会以 不同方式处理。见第 4.1.2 节。 SHOULD 使用更具体的被涵盖语言子标签来形成语言标签，不过 宏语言的主语言子标签或被涵盖语言的子标签 MAY 任一使用。 这意味着，例如，应使用 'crk' 而不是 'cr'（克里语）来标记 Plains Cree，依此类推。 根据定义，每个宏语言子标签的范围包括其所有被涵盖语言。 由于被涵盖语言之间的关系各不相同，用户不能假定宏语言子标签 表示任何特定被涵盖语言，也不能假定任意一对被涵盖语言可以 相互理解或以其他方式互换。 应用 MAY 使用宏语言信息来改进匹配或语言协商。例如，'sr' （塞尔维亚语）和 'hr'（克罗地亚语）共享一个宏语言这一信息， 表示这些语言之间的关系比例如 'sr'（塞尔维亚语）和 'ma' （马其顿语）之间的关系更密切。然而，这种关系既不保证成立， 也不是排他的。例如，罗马尼亚语（'ro'）和 Phillips & Davis 最佳当前实践 [第 58 页]
RFC 5646 语言标签 2009 年 9 月 摩尔多瓦语（'mo'）不共享宏语言，但二者之间的关系远比同样 共享宏语言的粤语（'yue'）和吴语（'wuu'）之间的关系密切。 4.1.2. 使用扩展语言子标签 为适应本文档采纳之前使用的语言标签形式，语言标签提供了一种 特殊兼容性机制：扩展语言子标签。若干选定语言同时提供主语言 子标签和扩展语言子标签。这些包括一些宏语言，例如马来语 （'ms'）和乌兹别克语（'uz'），它们有一种通常与该宏语言同义的 特定主导变体。其他语言，例如中文（'zh'）和阿拉伯语（'ar'） 宏语言，以及各种手语（'sgn'），传统上使用其主语言子标签， 可能与各种区域子标签结合，或作为已注册祖父标签的一部分， 来指示语言。 随着本文档的采纳，特定 ISO 639-3 子标签可用于标识这些多样 语言族或分组中包含的语言。这使得过去没有选择的地方出现了 语言标签选择： o 每种被涵盖语言的子标签 SHOULD 用作主语言子标签。例如， 普通话文档应标记为 "cmn"（普通话的子标签），优先于 "zh"（中文）。 o 如果希望或需要兼容性，则被涵盖子标签 MAY 用作扩展语言 子标签。例如，普通话文档可以标记为 "zh-cmn"，而不是 "cmn" 或 "zh"。 o 仍然 MAY 使用宏语言或前缀子标签来形成标签，而不是使用 更具体的被涵盖语言子标签。也就是说，"zh-HK" 或 "sgn-RU" 这样的标签仍然有效。 中文（'zh'）提供了一个有用的说明。过去，各种内容使用以 'zh' 子标签开头的标签，并将应用特定含义与区域代码、私用 序列或祖父注册值关联起来。这是因为从历史上看，只有宏语言 子标签 'zh' 可用于形成语言标签。然而，由中文子标签 'zh' 涵盖的语言，在口语上总体而言并不能相互理解，而且这些语言 的书面形式在形式和用法上也表现出广泛差异。 Phillips & Davis 最佳当前实践 [第 59 页]
RFC 5646 语言标签 2009 年 9 月 为提供兼容性，由 'zh' 子标签涵盖的中文语言在注册表中同时 作为主语言子标签和扩展语言子标签存在。例如，粤语的 ISO 639-3 代码是 'yue'。粤语内容过去可能使用诸如 "zh-HK" 这样的标签（因为粤语在香港通常使用），尽管该标签实际表示 在香港使用的任何类型中文。随着 ISO 639-3 代码在注册表中 可用，粤语内容可以直接使用 'yue' 子标签进行标记。该内容 可以将其用作主语言子标签，如标签 "yue-HK"（粤语，香港）。 或者，它可以与 'zh' 一起使用扩展语言子标签，如标签 "zh-yue-Hant"（中文，粤语，繁体文字）。 如上所述，应用可以选择使用宏语言子标签来形成标签，而不是 使用更具体的被涵盖语言子标签。例如，某个已有大量数据使用 'zh'（中文）子标签的应用，可能会继续对新数据使用这个更一般 的子标签，即使这些内容可以用 'cmn'（普通话）、'yue'（粤语）、 'wuu'（吴语）等更精确地标记。类似地，已经使用以 'ar' （阿拉伯语）子标签开头的标签的应用，可能会继续对新数据使用 这个更一般的子标签，尽管这些数据可以用 'arb'（标准阿拉伯语） 更精确地标记。 在某些情况下，被涵盖语言在 RFC 3066 时代已为其注册了 标签。那些尚未被弃用或变为冗余的祖父标签，在本文档采纳时 已在注册表中被弃用。作为祖父值，它们仍可有效使用，某些内容 或应用可能会使用它们。与其他祖父标签一样，由于实现可能无法 将祖父标签与本文档推荐的被涵盖语言子标签等价项关联起来， 因此鼓励实现为比较目的对标签进行规范化。这方面的一些示例 包括标签 "zh-hakka"（客家话）和 "zh-guoyu"（普通话或标准中文）。 手语共享的是一种通信模式，而不是语言谱系。有许多手语是独立 发展出来的，子标签 'sgn' 仅表示存在某种手语。若干手语也在 RFC 3066 时代注册过祖父标签。例如，祖父标签 "sgn-US" 被注册 用于专门表示“美国手语”，而不是指美国。这仍然有效，但已被 弃用：美国手语文档可以标记为 "ase" 或 "sgn-ase"（'ase' 子标签表示名为“American Sign Language”的语言）。 Phillips & Davis 最佳当前实践 [第 60 页]
RFC 5646 语言标签 2009 年 9 月 4.2. 语言标签的含义 语言标签的含义与其包含的子标签的含义相关。每个子标签又 暗示了人们可能对相关内容持有的一定范围的期望，尽管这不是 保证。例如，使用诸如 'Arab'（阿拉伯文字）这样的 script 子标签，并不意味着内容只包含阿拉伯字符。它确实意味着所涉 语言主要使用阿拉伯文字。因此，语言标签及其子标签可以涵盖 非常广泛的变体范围，并且仍然适用于每个特定实例。 标签的有效性并不是决定其有用性的唯一因素。虽然每个有效 标签都有含义，但它可能并不表示任何真实世界中的语言用法。 在一个允许自由组合子标签的系统中，这是不可避免的。例如， "ar-Cyrl-CO"（阿拉伯语，西里尔文字，在哥伦比亚使用）或 "tlh- Kore-AQ-fonipa"（克林贡语，韩文，在南极洲使用，IPA 音标 转写）这样的标签都是有效的，但不太可能表示一种有用的语言 属性组合。 给定标签的含义不取决于其出现的上下文。不过，标签含义与 应用该标签的信息对象之间的关系可能会有所不同。 o 对于单个信息对象，关联的语言标签可解释为完整理解整个对象 所必需的语言集合。示例：纯文本文档。 o 对于信息对象的聚合，关联的语言标签可被视为该聚合的组成 部分中所使用的语言集合。示例：文档存储库和图书馆。 o 对于目的在于提供替代项的信息对象，关联的语言标签可被视为 一种提示，表示内容以多种语言提供，并且必须检查每个替代项 才能找到其语言或语言集合。在这种情况下，存在多个标签并不 一定意味着需要掌握多种语言才能完整理解文档。示例：MIME multipart/ alternative [RFC2046]。 o 对于标记语言，例如 HTML 和 XML，可以向由标记结构标识的 文档各个部分（包括整个文档本身）添加语言信息。例如， 可以在德语文档中写入 <span lang="fr">C'est la vie.</span>； 德语用户随后可以访问法德词典，以了解被标记部分的含义。 如果用户通过语音合成接口收听该文档， Phillips & Davis 最佳当前实践 [第 61 页]
RFC 5646 语言标签 2009 年 9 月 这种形成方式可用于向合成器发出信号，使其对该段文本适当地 应用法语文本转语音发音规则，而不是应用不适当的德语规则。 o 对于允许标识受众的标记语言和文档格式，语言标签可以指示 适合该文档的受众。例如，前一条中描述的同一个 HTML 文档 可能具有 HTTP 头字段 "Content-Language: de"，表示该文件 的目标受众是德语使用者（尽管其中出现并标识了三个法语词）。 o 对于系统和 API，语言标签构成大多数区域设置标识符实现的 基础。例如，参见 Unicode 的 CLDR（Common Locale Data Repository）（见 UTS #35 [UTS35]）项目。 当语言标签包含相似的子标签序列时，它们彼此相关。例如， 如果语言标签 B 包含语言标签 A 作为前缀，则 B 通常比 A “更窄”或“更具体”。因此，"zh-Hant-TW" 比 "zh-Hant" 更具体。 这种关系并非在所有情况下都能保证：特别是，以相同子标签序列 开头的语言并不保证可以相互理解，尽管它们可能可以。例如， 标签 "az" 与 "az-Latn"（用拉丁文字书写的阿塞拜疆语）和 "az-Cyrl"（用西里尔文字书写的阿塞拜疆语）共享前缀。精通 一种文字的人可能无法阅读另一种文字，即使语言内容（例如， 如果两篇文本被朗读出来时所听到的内容）可能相同。标记为 "az" 的内容很可能只用一种文字书写，因此可能无法被熟悉另一 种文字的读者理解。 类似地，并非所有子标签都指定实际的语言区别。例如，标签 "en-US" 和 "en-CA" 大致表示具有通常认为分别体现美国和加拿大 特征的英语。它们并不意味着美国任意选定地点与加拿大任意选定 地点之间存在显著方言边界。特定区域子标签也不意味着该区域内 不存在语言差异。 Phillips & Davis 最佳当前实践 [第 62 页]
RFC 5646 语言标签 2009 年 9 月 4.3. 语言列表 在某些应用中，单个内容项最好与多个语言标签相关联。此类用法 的示例包括： o 包含多种不同变体的内容项。通常，这用于在存在多个适当选择时 指示给定内容项的适当受众。其示例可能包括： * 关于电影标题适当受众的元数据。例如，DVD 可能将其各个 音轨标记为 'de'（德语）、'fr'（法语）和 'es'（西班牙语）， 但整体标题会将 "de, fr, es" 列为其整体受众。 * 一本法英、英法词典同时标记为 "en" 和 "fr"，以表明它 同等适用于法语和英语。 * 文档的并列或逐行翻译，这在拉丁语或希腊语古典作品中很常见。 o 包含单一语言但需要多个具体性层级的内容项。例如，图书馆可能 希望将某部作品同时分类为挪威语（'no'）和尼诺斯克语（'nn'）， 以服务能够理解这种区别或需要更精确选择内容的受众。 4.4. 长度考虑事项 语言标签的大小没有定义的上限。虽然历史上大多数语言标签由 语言和区域子标签组成，总长度最多为六个字符，但更大的标签 一直都是可能的，并且实际也已出现于使用中。 语言标签语法和本文档中的其他要求，都没有对语言标签中的子标签 数量（以及标签大小的上限）施加固定上限。语言标签语法表明， 根据具体语言，某些应用有时需要更多子标签（因而更长的标签） 才能完整标识语言；因此，可以设想长的或复杂的子标签序列。 Phillips & Davis 最佳当前实践 [第 63 页]
RFC 5646 语言标签 2009 年 9 月 4.4.1. 使用有限缓冲区大小 某些应用和协议被迫分配固定缓冲区大小，或以其他方式限制语言 标签的长度。符合要求的实现或规范 MAY 拒绝支持存储超过指定 长度的语言标签。任何此类限制 SHOULD 被清楚记录，并且此类 文档 SHOULD 包含对更长标签会发生什么的说明（例如，是生成 错误值还是截断语言标签）。允许在任意限制处截断标签、却不 指明该限制是什么的协议，可能会通过实质性改变标签含义而造成 损害。 实践中，大多数语言标签不需要超过少数几个子标签，也不会接近 合理大小的缓冲区限制；见第 4.1 节。 某些规范或协议对标签长度有限制，但没有固定长度限制。例如， [RFC2231] 没有显式长度限制：语言标签可用长度受其他头组件 （如 charset 名称）长度以及 [RFC2047] 中 76 字符限制的共同 约束。因此，该“限制”可能是 50 个或更多字符，但也可能相当小。 分配缓冲区限制时的考虑事项是： 除非有意改变标签含义，或标签无法放入协议为存储或传输指定的 有限缓冲区大小，否则实现 SHOULD NOT 截断语言标签。 实现 SHOULD 在标签被截断时警告用户，因为截断会改变标签的 语义含义。 对空间受限但没有固定限制的协议或规范，实现 SHOULD 优先使用 尽可能长的标签，而不是截断。 为语言标签指定有限缓冲区大小的协议或规范 MUST 允许至少 35 个字符的语言标签。注意，[RFC4646] 曾建议最小字段大小 为 42 个字符，因为它包含 'extlang' 产生式的全部三个元素。 其中两个现在已永久保留，因此最大长度为 8 个字符的已注册 主语言子标签现在长于最长的 language-extlang 组合。常用 Phillips & Davis 最佳当前实践 [第 64 页]
RFC 5646 语言标签 2009 年 9 月 扩展或私用子标签的协议或规范，可能希望保留或建议更长的 “最小缓冲区”大小。 以下说明展示了 35 字符建议是如何推导出来的： language = 8 ; longest allowed registered value ; longer than primary+extlang ; which requires 7 characters script = 5 ; if not suppressed: see Section 4.1 region = 4 ; UN M.49 numeric region code ; ISO 3166-1 codes require 3 variant1 = 9 ; needs 'language' as a prefix variant2 = 9 ; very rare, as it needs ; 'language-variant1' as a prefix total = 35 characters 图 7：标签长度限制的推导 4.4.2. 语言标签的截断 截断语言标签会改变标签含义，因此 SHOULD 避免。然而，由于 缓冲区大小有限，有时必须截断语言标签。此类截断 MUST NOT 允许从中间截断子标签，也 MUST NOT 形成无效标签（例如，以 "-" 字符结尾的标签）。 这意味着，截断标签的应用或协议 MUST 从语言标签右侧开始， 逐步移除子标签及其前面的 "-"，直到标签足够短以适应该缓冲区。 如果所得标签以单字符子标签结尾，则该子标签及其前面的 "-" MUST 也被移除。例如： 待截断标签：zh-Latn-CN-variant1-a-extend1-x-wadegile-private1 1. zh-Latn-CN-variant1-a-extend1-x-wadegile 2. zh-Latn-CN-variant1-a-extend1 3. zh-Latn-CN-variant1 4. zh-Latn-CN 5. zh-Latn 6. zh 图 8：标签截断示例 Phillips & Davis 最佳当前实践 [第 65 页]
RFC 5646 语言标签 2009 年 9 月 4.5. 语言标签的规范化 由于一个特定语言标签可能被许多过程使用，语言标签 SHOULD 始终以规范形式创建或生成。 当一个语言标签按照第 2.1 节和第 2.2 节中的规则格式良好， 并且使用 IANA 注册表中的数据（见第 3.1 节）按顺序应用以下 每个步骤进行规范化时，该语言标签处于“规范形式”： 1. 扩展序列按 singleton 子标签的不区分大小写 ASCII 顺序排序。 * 例如，子标签序列 '-a-babble' 位于 '-b-warble' 之前。 2. 冗余标签或祖父标签如果有 'Preferred- Value'，则替换为该值。 * 祖父标签和冗余标签的 'Preferred-Value' field-body 是 一个“扩展语言范围” [RFC4647]，可能由多个子标签组成。 * 注册表中的 'Preferred-Value' 字段提供从已弃用标签到 现代等价项的映射。许多映射是在本文档采纳之前创建的 （例如将 "no-nyn" 映射到 "nn"，或将 "i-klingon" 映射到 "tlh"）。其他映射是本文档允许或要求的后续注册或添加到 注册表的结果（例如，本文档采纳时，"zh-hakka" 被弃用， 改用 ISO 639-3 代码 'hak'）。 3. 子标签如果有 'Preferred-Value'，则替换为该值。对于 extlang，如果 'Preferred-Value' 中存在主语言子标签， 则原始主语言子标签也会被替换。 * extlang 的 'Preferred-Value' field-body 是一个“扩展语言 范围”，通常映射到一个主语言子标签。例如，子标签序列 "zh-hak"（中文，客家话）被替换为子标签 'hak'（客家话）。 * 大多数非 extlang 子标签要么是国家名称或称谓已发生改变的 Region 子标签，要么是对 ISO 639-1 的文书性更正。 Phillips & Davis 最佳当前实践 [第 66 页]
RFC 5646 语言标签 2009 年 9 月 规范形式不包含 'extlang' 子标签。存在一种替代的 'extlang form'， 它会保留或恢复 extlang 子标签。此形式可用于那些认为存在 'Prefix' 子标签有利于匹配或选择的环境（见第 4.1.2 节）。 当一个语言标签按照第 2.1 节和第 2.2 节中的规则格式良好， 并且使用 IANA 注册表中的数据按顺序应用以下两个步骤进行处理时， 该语言标签处于 'extlang form'： 1. 语言标签首先按上文所述转换为规范形式。 2. 如果语言标签以一个同时也是 extlang 子标签的主语言子标签 开头，则在该语言标签前加上该 extlang 的 'Prefix'。 * 例如，"hak-CN"（客家话，中国）具有主语言子标签 'hak'， 而 'hak' 又具有一个带有 'Prefix' 'zh'（中文）的 'extlang' 记录。extlang form 为 "zh-hak-CN" （中文，客家话，中国）。 * 注意，第 2 步（前置前缀）可以恢复第 1 步（规范化）中 移除的子标签。 示例：语言标签 "en-a-aaa-b-ccc-bbb-x-xyz" 处于规范形式，而 "en-b-ccc-bbb-a-aaa-X-xyz" 格式良好且可能有效（截至本文档 发布时，扩展 'a' 和 'b' 尚未定义），但不处于规范形式 （扩展未按字母顺序排列）。 示例：尽管标签 "en-BU"（在缅甸使用的英语）保持有效，语言 标签 "en-BU" 并不处于规范形式，因为 'BU' 子标签具有到 'MM'（Myanmar）的规范映射。 语言标签的规范化并不意味着在处理或比较子标签时对大小写字母 的使用有任何要求（并且如第 2.1 节所述）。所有比较 MUST 以不区分大小写的方式执行。 执行语言标签规范化时，处理器 MAY 规范化子标签的大小写 （也就是说，此过程是 OPTIONAL），遵循注册表中使用的大小写 （见第 2.1.1 节）。 Phillips & Davis 最佳当前实践 [第 67 页]
RFC 5646 语言标签 2009 年 9 月 如果一个标签中出现多个变体，处理器 MAY 重新排序这些变体， 以获得更好的匹配行为或更一致的呈现。变体的重新排序 SHOULD 遵循第 4.1 节中关于变体顺序的建议。 如果字段 'Deprecated' 出现在注册表记录中，但没有伴随的 'Preferred-Value' 字段，则该标签或子标签被弃用且没有替代项。 当这些值出现在语言标签中时，它们是规范的。然而，包含这些值 的标签 SHOULD NOT 被用户选择或由实现生成。 扩展 MUST 定义扩展中各个子标签之间存在的任何关系，因此 MAY 为扩展子标签定义替代规范化方案。扩展 MAY 定义如何解释扩展 子标签的顺序。例如，某个扩展可以定义，当其子标签按 ASCII 顺序放置时即为规范顺序：也就是 "en-a- aaa-bbb-ccc"，而不是 "en-a-ccc-bbb-aaa"。另一个扩展可能定义 子标签顺序会影响其语义含义（因此 "en-b-ccc-bbb-aaa" 与 "en-b- aaa-bbb-ccc" 具有不同值）。不过，扩展规范 SHOULD 被设计为 能够容忍第 3.7 节中描述的典型过程。 4.6. 私用子标签考虑事项 私用子标签与所有其他子标签一样，MUST 符合 ABNF 中的格式和 内容约束。私用子标签在打算使用或交换采用这些子标签的语言标签 的各方之间的私下协议之外没有含义。同一子标签 MAY 在另一个 单独私下协议下以不同含义使用。存在替代项时 SHOULD NOT 使用 它们，在面向一般使用的内容或协议中也 SHOULD NOT 使用它们。 没有事先安排时，私用子标签对于信息交换根本无用。私用标签 以及此类语言标签中所用子标签的值和语义含义不由本文档定义。 由 'x' singleton 引入的私用序列，对私用协议之外的用户或实现 完全不透明。因此，除了由 singleton 子标签 'x' 引入的私用子标签 序列外，语言子标签注册表还提供由底层标准分配的私用代码派生的 私用语言、文字和区域子标签。这些子标签可有效用于形成语言标签； 与 'x' singleton 私用子标签序列相比，RECOMMENDED 使用它们， Phillips & Davis 最佳当前实践 [第 68 页]
RFC 5646 语言标签 2009 年 9 月 因为它们通过与语言标签固有结构的关联传达更多信息。 例如，区域子标签 'AA'、'ZZ'，以及范围 'QM'-'QZ' 和 'XA'-'XZ' 中的子标签（派生自 ISO 3166-1 私用代码）可用于 形成语言标签。诸如 "zh-Hans-XQ" 的标签传达了大量关于语言 材料的公开、可互换信息（它是简体中文文字的中文，并适用于 某个地理区域 'XQ'）。虽然该精确地理区域在私下协议之外未知， 但该标签传达的信息远多于诸如 "x-somelang" 这样的不透明标签， 甚至也多于 "zh-Hans-x-xq"（其中 'xq' 子标签的含义完全不透明）。 然而，在某些情况下，与使用不透明、私下定义子标签的标签相比， 标记有私用子标签的内容可能以不同且可能不适合的方式与其他系统 交互，因此最佳方法的选择有时取决于所涉具体领域。 5. IANA 考虑事项 本节处理 IANA 按本文档定义并根据 [RFC5226] 要求维护子标签 和扩展注册表所必需的过程和要求。 本文档定义的两个注册表对 IANA 维护人员的影响，将是新条目或 更新频率的小幅增加。IANA 还需要创建一个新的邮件列表（下文 第 5.1 节中描述），用于宣布注册表变更和更新。 5.1. 语言子标签注册表 IANA 使用配套文档 [RFC5645] 中提供的说明和内容更新了注册表。 选择更新记录集的标准和过程在该文档中描述。更新后的记录集对 IANA 没有影响，因为创建它的工作将在外部完成。 语言子标签注册表未来的工作包括以下活动： o 插入或替换完整记录。这些记录由语言子标签审查员预先为 IANA 格式化，如第 3.3 节所述。 o 归档注册表单并公开提供。 Phillips & Davis 最佳当前实践 [第 69 页]
RFC 5646 语言标签 2009 年 9 月 o 在 "ietf-languages-announcements@iana.org" 邮件列表上宣布 注册表的每个更新版本。 发送给 IANA 的每个注册表单都包含一条要纳入注册表的单一记录。 该表单将由语言子标签审查员发送至 <iana@iana.org>。其主题行 将指示所附表单表示插入新记录（主题行中以 "INSERT" 一词表示） 还是替换现有记录（主题行中以 "MODIFY" 一词表示）。任何时候 都不能从注册表中删除记录。 IANA 将从表单中提取记录，并将插入或修改后的记录放入语言子标签 注册表的适当部分，按其 'Type' 字段对记录分组。插入的记录可 放置在适当部分内的任何位置；除始终按 'Type' 分组外，不保证 注册表记录会按任何特定顺序放置。修改后的记录会覆盖其所替代的 记录。 每当注册表中创建或修改一个条目时，注册表开头的 'File- Date' 记录都会更新，以反映最近修改日期。日期格式 SHALL 是 [RFC3339] 的 "full-date" 格式。日期 SHALL 是 IANA 首次发布 该版本注册表的日期。每天 SHALL 最多发布一个版本的注册表。 向 IANA 发出的每个插入或修改记录请求中也包含一个 'File- Date' 记录，指示请求中记录的接受日期。 更新后的注册表文件 MUST 使用 UTF-8 字符编码，并且 IANA MUST 检查注册表文件是否正确编码。可通过将注册表单作为电子邮件附件 发送给 IANA，或在邮件正文中使用各种编码（建议使用 UTF-8）来 发送非 ASCII 字符。IANA 将在发布更新后的注册表之前，与语言 子标签审查员核实任何不明确或损坏的字符。 IANA 还将从 http://www.iana.org 归档并公开提供每个注册表单。 注意，多个注册可能涉及注册表中的同一记录。 依赖语言子标签注册表的开发者有时希望获知注册表中的变更，以便 更新其实现。当语言子标签注册表发生任何变更时，IANA 将向 <ietf-languages-announcements@iana.org> 发送公告消息（这是一个 自助订阅列表，只有 IANA 可以向其发布）。 Phillips & Davis 最佳当前实践 [第 70 页]
RFC 5646 语言标签 2009 年 9 月 5.2. 扩展注册表 Language Tag Extensions Registry 最多可包含 35 条记录，因此预计 该注册表的变更会非常少见。 IANA 对 Language Tag Extensions Registry 的未来工作限于两种 情况。首先，IESG MAY 不时请求向该注册表插入新记录。这些请求 MUST 包含要插入的记录，且采用第 3.7 节中描述的精确格式。 此外，特定扩展的维护机构 MAY 偶尔请求更新记录中的联系信息或 URL。这些请求 MUST 包含完整的更新记录。IANA 不负责验证所提供 的信息，只负责验证其格式正确。IANA SHOULD 采取合理步骤，确认 请求来自注册表中现有记录所命名的维护机构。 6. 安全考虑事项 在内容协商中使用的语言标签，与 Internet 上交换的任何其他信息 一样，可能引发担忧，因为它们可能被用于推断发送者的国籍， 从而识别潜在监控目标。 这是一个一般问题的特殊情形：发送的任何内容对接收方可见， 也可能对第三方可见。意识到此类担忧在某些情况下可能存在是有用的。 对威胁确切规模以及任何可能对策的评估，留给各应用协议处理 （关于安全威胁和防御的最佳当前实践指南，见 BCP 72 [RFC3552]）。 与特定信息项相关联的语言标签，对于判断该内容是否可能包含 同形异义字符没有任何影响。文本被标记为某种语言或使用某个 特定 script 子标签这一事实，完全不能保证它不包含来自该语言 标签相关或指定文字之外其他文字的字符。 由于变体、私用和扩展子标签的数量没有限制，因而标签可能长度也 没有限制，实现需要防范缓冲区溢出攻击。关于语言标签截断的详情 见第 4.4 节，截断可能作为防御缓冲区溢出的结果而发生。 Phillips & Davis 最佳当前实践 [第 71 页]
RFC 5646 语言标签 2009 年 9 月 为防止拒绝服务攻击，应用 SHOULD NOT 依赖语言子标签注册表或 Language Tag Extensions Registry 始终可访问。此外，尽管扩展的 有效子标签规范（见第 3.7 节）MUST 可通过 Internet 获得， 实现 SHOULD NOT 机械地依赖这些来源始终可访问。 本文档指定的注册表不适合频繁或实时访问或检索完整注册表内容。 大多数应用根本不需要注册表数据。对于其他应用，能够按特定注册表 日期验证或规范化语言标签就已足够，因为注册表内容仅偶尔变化。 变更会通知至 <ietf-languages-announcements@iana.org>。该邮件列表 面向感兴趣的组织和个人，而不是面向触发自动软件更新的批量订阅。 注册表大小使其不适合自动软件更新。强烈建议考虑将语言子标签注册表 集成到自动更新方案中的实现者，仅分发适当编码的差异，并且只通过 其自身基础设施分发——不要直接从 IANA 分发。 通过查看注册表开头的 'File-Date' 记录，或使用下载所用协议的 特性，也可以轻松检测变更或没有变更，而不必下载完整注册表。 在本文档发布时，IANA 通过 HTTP 1.1 提供 Language Tag Registry。 使用 HTTP 1.1 更新语言子标签注册表本地副本的正确方式是使用 条件 GET [RFC2616]。 7. 字符集考虑事项 本文档中的语法要求语言标签仅使用字符 A-Z、a-z、0-9 和 HYPHEN-MINUS，这些字符存在于大多数字符集中，因此语言标签的 组成不应有任何字符集问题。 此处不处理基于语言标签的文本呈现。历史上，某些过程依赖使用 字符集/编码信息（或其他外部信息）来推断特定字符串应如何呈现。 特别是，这适用于日语、中文和韩语中使用的汉字在语言和文化方面的 特定变体，其中，例如，使用日语字符编码（如 EUC-JP）意味着文本 本身是日语。当语言标签应用于文本片段时，呈现引擎可能能够使用 该信息来更好地选择字体或作出其他呈现 Phillips & Davis 最佳当前实践 [第 72 页]
RFC 5646 语言标签 2009 年 9 月 选择，特别是在具有不同书写传统的语言使用相同字符时。 8. 相对 RFC 4646 的变更 本次修订 RFC 4646 的主要目标，是将 ISO 639 的两个新部分 （ISO 639-3 和 ISO 639-5）及其附带的语言代码集合纳入 IANA 语言子标签注册表。这允许标识比以前支持的更多语言和语言集合。 为实现这些目标，本文档中的具体变更是： o 定义了纳入 ISO 639-3 和 ISO 639-5 代码以用作主语言和扩展 语言子标签。它还永久保留并禁止使用附加的 'extlang' 子标签。 为实现这一点所需的变更包括： * 修改了 ABNF 注释。 * 更新了多个注册和稳定性要求章节，以在 ISO 639-1 和 ISO 639-2 之外引用 ISO 639-3 和 ISO 639-5。 * 编辑文本，以消除不再使用扩展语言子标签之处对它们的引用。 * 在关于扩展语言子标签的章节中解释了这一变更。 o 更改了与祖父标签相关的 ABNF。现在列出了 irregular 标签。 格式良好的祖父标签现在由 'langtag' 产生式描述，因此移除了 'grandfathered' 产生式。还向第 2.2.8 节添加了对两类祖父 标签的描述。 o 向第 4.1 节添加了关于“collections”的段落。 o 更改了第 3.1 节中 'Tag' 字段的大小写规则。 o 将第 3.1 节拆分为多个小节。 o 修改第 3.5 节，以允许通过注册过程添加、修改或移除 'Suppress-Script' 字段。这是 RFC 4646 的一项勘误。 o 修改了使用区域代码 'CS'（原塞尔维亚和黑山）的示例，改用 'RS'（塞尔维亚）。 Phillips & Davis 最佳当前实践 [第 73 页]
RFC 5646 语言标签 2009 年 9 月 o 修改了创建和维护记录 'Description' 字段的规则，以防止重复， 包括倒置重复。 o 从本节移除了关于为何创建 RFC 4646 的冗长说明，这也导致 移除了对 XML Schema 的引用。 o 修改了第 2.1 节中的文本，以更强调语言标签不区分大小写 这一事实。 o 在第 2.1 节中用 "sr-Latn-RS" 和 "az-Arab-IR" 替换了示例 "fr-Latn-CA"，因为 "fr-Latn-CA" 没有尊重 'fr' 上的 'Suppress-Script' 'Latn'。 o 更改了格式良好性要求，使 singleton 重复检查成为可选（在 有效性检查中仍为必需），见第 2.2.9 节。 o 更改了第 2.2.9 节中关于祖父项检查的文本，以说明该列表现在 包含在 ABNF 中。 o 修改并添加了第 3.2 节的文本。职位描述被放在最前面。 添加了一条说明，明确语言子标签审查员可以委派各种非关键职责， 包括列表主持。最后，添加了额外文本，以明确任命过程，并澄清 审查员的决定和履职可以申诉。 o 向第 3.5 节添加文本，澄清 ietf-languages@iana.org 列表 由 IESG 指定的人运营。 o 向第 3.1.5 节添加文本，澄清 'language' 记录中的第一个 Description 与 ISO 639-3 中该语言的对应 Reference Name 匹配。 o 修改第 2.2.9 节，以定义与特定标签相关的符合性类别 （以前 'well-formed' 和 'valid' 指实现）。添加了关于移除 RFC 4646 中给出的 ABNF 中 'extlang'、允许使用此旧定义实现 格式良好性的说明。还添加了对 RFC 3066 格式良好性的引用。 o 向第 3.1.2 节末尾添加文本，说明本文档未来版本可能向注册表 格式添加新的字段类型，并建议实现忽略任何无法识别的字段。 Phillips & Davis 最佳当前实践 [第 74 页]
RFC 5646 语言标签 2009 年 9 月 o 向第 3.1.9 节添加关于记录中缺少 'Suppress-Script' 字段 意味着什么的文本。 o 向第 3.1.5 节添加允许更正拼写错误和排印错误的文本。 o 向第 3.1.8 节添加文本，禁止 'Prefix' 字段冲突（如循环前缀 引用）。 o 修改第 3.5 节中的文本，要求子标签审查员在两周期限之后宣布 其决定（或延期）。还澄清任何决定或未作出决定都可以申诉。 o 修改第 4.1 节中的文本，以纳入（迄今为止只是传闻式的） 标签选择指导原则，并澄清在非书写应用中不使用 script 子标签。 o 禁止在一个标签中多次使用同一变体（即 "de- 1901-1901"）。此前，这只是一个建议（"SHOULD"）。 o 从第 4.4.1 节的说明中移除了不适当的 [RFC2119] 语言。 o 在第 4.5 节中，用 "zh- hakka"->"hak" 替换了弃用 "zh-guoyu" 的示例，并指出是本文档 导致了该变更。 o 替换了第 4.1 节中处理 "mul"/"und" 的部分，以包含子标签 'zxx' 和 'mis'，以及标签 "i-default"。添加了对 RFC 2277 的规范性引用。 o 向第 3.5 节添加文本，澄清注册请求的任何修改在提交给 IANA 之前必须发送至 <ietf-languages@iana.org> 列表。 o 将 record-jar 格式的 ABNF 从使用 LWSP 产生式更改为使用类似 [RFC5234] 中 obs- FWS 的折行空白产生式。这有效防止了字段内部出现无意空行。 o 澄清并修订了第 3.3、3.5 和 5.1 节中的文本，以澄清语言 子标签审查员会将完整注册表单发送给 IANA，IANA 从表单中提取 记录，并且表单也必须独立于注册表单独归档。 Phillips & Davis 最佳当前实践 [第 75 页]
RFC 5646 语言标签 2009 年 9 月 o 向第 5 节添加文本，要求 IANA 在注册表更新时向 ietf-languages-announcements 列表发送公告。 o 修改注册表以使用 UTF-8 作为其字符编码。这也需要在注册过程中 向 IANA 和语言子标签审查员提供附加说明。 o 修改第 2.2.4 节中的规则，使除 'UK' 以外的 “exceptionally reserved” ISO 3166-1 代码纳入注册表。特别是， 这允许代码 'EU'（European Union）用于形成语言标签，或 （更常见地）供使用注册表作为区域代码来源的应用引用此子标签。 o 修改 IANA 考虑事项章节（第 5 节），以移除不必要的规范性 [RFC2119] 语言。 9. 参考文献 9.1. 规范性参考文献 [ISO15924] International Organization for Standardization, "ISO 15924:2004. Information and documentation -- Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166-1:2006. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", November 2006. [ISO639-1] International Organization for Standardization, "ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code", July 2002. [ISO639-2] International Organization for Standardization, "ISO 639-2:1998. Codes for the representation of names of languages -- Part 2: Alpha-3 code", October 1998. [ISO639-3] International Organization for Standardization, "ISO 639-3:2007. Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages", February 2007. Phillips & Davis 最佳当前实践 [第 76 页]
RFC 5646 语言标签 2009 年 9 月 [ISO639-5] International Organization for Standardization, "ISO 639-5:2008. Codes for the representation of names of languages -- Part 5: Alpha-3 code for language families and groups", May 2008. [ISO646] International Organization for Standardization, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [SpecialCasing] The Unicode Consoritum, "Unicode Character Database, Special Casing Properties", March 2008, <http:// unicode.org/Public/UNIDATA/SpecialCasing.txt>. [UAX14] Freitag, A., "Unicode Standard Annex #14: Line Breaking Properties", August 2006, <http://www.unicode.org/reports/tr14/>. [UN_M.49] Statistics Division, United Nations, "Standard Country or Area Codes for Statistical Use", Revision 4 (United Nations publication, Sales No. 98.XVII.9, June 1999. Phillips & Davis 最佳当前实践 [第 77 页]
RFC 5646 语言标签 2009 年 9 月 [Unicode] Unicode Consortium, "The Unicode Consortium. The Unicode Standard, Version 5.0, (Boston, MA, Addison- Wesley, 2003. ISBN 0-321-49081-0)", January 2007. 9.2. 资料性参考文献 [CLDR] "The Common Locale Data Repository Project", <http://cldr.unicode.org>. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Phillips & Davis 最佳当前实践 [第 78 页]
RFC 5646 语言标签 2009 年 9 月 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4645] Ewell, D., "Initial Language Subtag Registry", RFC 4645, September 2006. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [RFC5645] Ewell, D., Ed., "Update to the Language Subtag Registry", September 2009. [UTS35] Davis, M., "Unicode Technical Standard #35: Locale Data Markup Language (LDML)", December 2007, <http://www.unicode.org/reports/tr35/>. [iso639.prin] ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory Committee: Working principles for ISO 639 maintenance", March 2000, <http://www.loc.gov/ standards/iso639-2/iso639jac_n3r.html>. [record-jar] Raymond, E., "The Art of Unix Programming", 2003, <urn:isbn:0-13-142901-9>. Phillips & Davis 最佳当前实践 [第 79 页]
RFC 5646 语言标签 2009 年 9 月 附录 A. 语言标签示例（资料性） 简单语言子标签： de（德语） fr（法语） ja（日语） i-enochian（祖父标签示例） 语言子标签加 Script 子标签： zh-Hant（用繁体中文文字书写的中文） zh-Hans（用简体中文文字书写的中文） sr-Cyrl（用西里尔文字书写的塞尔维亚语） sr-Latn（用拉丁文字书写的塞尔维亚语） 扩展语言子标签及其对应的主语言子标签： zh-cmn-Hans-CN（中文，普通话，简体文字，在中国使用） cmn-Hans-CN（普通话，简体文字，在中国使用） zh-yue-HK（中文，粤语，在香港特别行政区使用） yue-HK（粤语，在香港特别行政区使用） Language-Script-Region： zh-Hans-CN（用简体文字书写、在中国大陆使用的中文） sr-Latn-RS（用拉丁文字书写、在塞尔维亚使用的塞尔维亚语） Phillips & Davis 最佳当前实践 [第 80 页]
RFC 5646 语言标签 2009 年 9 月 Language-Variant： sl-rozaj（斯洛文尼亚语的 Resian 方言） sl-rozaj-biske（斯洛文尼亚语 Resian 方言中的 San Giorgio 方言） sl-nedis（斯洛文尼亚语的 Nadiza 方言） Language-Region-Variant： de-CH-1901（在瑞士使用并采用 1901 变体[正字法]的德语） sl-IT-nedis（在意大利使用的斯洛文尼亚语，Nadiza 方言） Language-Script-Region-Variant： hy-Latn-IT-arevela（用拉丁文字书写、在意大利使用的东亚美尼亚语） Language-Region： de-DE（德国德语） en-US（在美国使用的英语） es-419（适合拉丁美洲和加勒比地区、使用 UN 区域代码的西班牙语） 私用子标签： de-CH-x-phonebk az-Arab-x-AZE-derbend 私用注册表值： x-whatever（使用 singleton 'x' 的私用） qaa-Qaaa-QM-x-southern（全私用标签） de-Qaaa（德语，带私用文字） sr-Latn-QM（塞尔维亚语，拉丁文字，私用区域） sr-Qaaa-RS（塞尔维亚语，私用文字，用于塞尔维亚） Phillips & Davis 最佳当前实践 [第 81 页]
RFC 5646 语言标签 2009 年 9 月 使用扩展的标签（仅为示例——扩展 MUST 通过本文档的修订或更新， 或通过 RFC 定义）： en-US-u-islamcal zh-CN-a-myext-x-private en-a-myext-b-another 一些无效标签： de-419-DE（两个区域标签） a-DE（在主位置使用单字符子标签；注意，有少数以 "i-" 开头的 祖父标签是有效的） ar-a-aaa-b-bbb-a-ccc（两个扩展具有相同单字母前缀） 附录 B. 注册表单示例 LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: Han Steenwijk 2. E-mail address of requester: han.steenwijk @ unipd.it 3. Record Requested: Type: variant Subtag: biske Description: The San Giorgio dialect of Resian Description: The Bila dialect of Resian Prefix: sl-rozaj Comments: The dialect of San Giorgio/Bila is one of the four major local dialects of Resian 4. Intended meaning of the subtag: The local variety of Resian as spoken in San Giorgio/Bila 5. Reference to published description of the language (book or article): -- Jan I.N. Baudouin de Courtenay - Opyt fonetiki rez'janskich govorov, Varsava - Peterburg: Vende - Kozancikov, 1875. Phillips & Davis 最佳当前实践 [第 82 页]
RFC 5646 语言标签 2009 年 9 月 LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: Jaska Zedlik 2. E-mail address of requester: jz53 @ zedlik.com 3. Record Requested: Type: variant Subtag: tarask Description: Belarusian in Taraskievica orthography Prefix: be Comments: The subtag represents Branislau Taraskievic's Belarusian orthography as published in "Bielaruski klasycny pravapis" by Juras Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka (Vilnia-Miensk 2005). 4. Intended meaning of the subtag: The subtag is intended to represent the Belarusian orthography as published in "Bielaruski klasycny pravapis" by Juras Buslakou, Vincuk Viacorka, Zmicier Sanko, and Zmicier Sauka (Vilnia-Miensk 2005). 5. Reference to published description of the language (book or article): Taraskievic, Branislau. Bielaruskaja gramatyka dla skol. Vilnia: Vyd. "Bielaruskaha kamitetu", 1929, 5th edition. Buslakou, Juras; Viacorka, Vincuk; Sanko, Zmicier; Sauka, Zmicier. Bielaruski klasycny pravapis. Vilnia-Miensk, 2005. 6. Any other relevant information: Belarusian in Taraskievica orthography became widely used, especially in Belarusian-speaking Internet segment, but besides this some books and newspapers are also printed using this orthography of Belarusian. 附录 C. 致谢 任何贡献者列表都必然不完整；请将以下内容视为参与促成本文档 今日面貌的人群中的一个选集。 RFC 4646、RFC 4647、RFC 3066 和 RFC 1766 的贡献者，也就是 本文档的前身，对本文档直接或间接作出了巨大贡献，并且总体上 是语言标签成功的功臣。 Phillips & Davis 最佳当前实践 [第 83 页]
RFC 5646 语言标签 2009 年 9 月 以下人员为本文档作出了贡献： Stephane Bortzmeyer, Karen Broome, Peter Constable, John Cowan, Martin Duerst, Frank Ellerman, Doug Ewell, Deborah Garside, Marion Gunn, Alfred Hoenes, Kent Karlsson, Chris Newman, Randy Presuhn, Stephen Silver, Shawn Steele, and many, many others. 非常特别感谢 Harald Tveit Alvestrand，他发起了 RFC 1766 和 RFC 3066，没有他，本文档不可能成为现实。 特别感谢 Michael Everson，他在几乎整个 RFC 1766/RFC 3066 期间担任 Language Tag Reviewer，并且自 RFC 4646 采纳以来 一直担任 Language Subtag Reviewer。 还要特别感谢 Doug Ewell，感谢他制作了第一个完整的子标签注册表， 以及他为支持和维护新注册所做的工作，并感谢他对 RFC 4645 和 [RFC5645] 细致的编辑工作。 作者地址 Addison Phillips（编辑） Lab126 EMail: addison@inter-locale.com URI: http://www.inter-locale.com Mark Davis（编辑） Google EMail: markdavis@google.com Phillips & Davis 最佳当前实践 [第 84 页]