网络工作组 A. Phillips, Ed. 征求意见稿：5646 Lab126 BCP：47 M. Davis, Ed. 废止：4646 Google 类别：最佳当前实践 2009 年 9 月 用于标识语言的标签 摘要 本文档描述了语言标签的结构、内容、构造和 语义，这些标签用于需要指明信息对象中所用 语言的情况。本文档还描述了如何注册用于语言标签的值，以及 如何创建用于私下交换的用户定义扩展。 本备忘录的状态 本文档规定了面向互联网社区的一项互联网最佳当前实践，并请求 对其进行讨论以及提出改进建议。本备忘录的分发不受限制。 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 浏览器中的用户语言偏好可用于适当地选择网页。语言 信息也可用于从各种工具（例如 词典）中进行选择，以辅助处理或理解 不同语言的内容。了解某些信息内容所使用的特定语言， 对某些类型的处理可能很有用，甚至是必需的， 例如拼写检查、计算机 合成语音、盲文转录或高质量打印 渲染。 指明所用语言的一种方式，是给 信息内容标记一个标识符或“标签”。这些标签还可以 用于在选择信息内容时指定用户的偏好， 或者用于标记内容及相关资源的其他属性。 有时，语言标签用于指示内容的其他语言 属性。例如，指明文档 或资源中使用的具体方言、书写系统或正字法信息，可以让用户 获得其能够理解形式的信息，或者这种信息对于将给定内容 处理或渲染为适当形式或样式可能很重要。 本文档规定了一种特定的标识符机制（ 语言标签）以及用于构成标签的值的注册功能。它还定义了 私用值和未来扩展的机制。 Phillips & Davis 最佳当前实践 [第 3 页]
RFC 5646 语言标签 2009 年 9 月 本文档取代 [RFC4646]（其废止了 [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 ; 普通语言标签 / privateuse ; 私用标签 / grandfathered ; 祖父条款标签 Phillips & Davis 最佳当前实践 [第 4 页]
RFC 5646 语言标签 2009 年 9 月 langtag = language ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse] language = 2*3ALPHA ; 最短的 ISO 639 代码 ["-" extlang] ; 有时后接 ; 扩展语言子标签 / 4ALPHA ; 或保留供未来使用 / 5*8ALPHA ; 或已注册的语言子标签 extlang = 3ALPHA ; 选定的 ISO 639 代码 *2("-" 3ALPHA) ; 永久保留 script = 4ALPHA ; ISO 15924 代码 region = 2ALPHA ; ISO 3166-1 代码 / 3DIGIT ; UN M.49 代码 variant = 5*8alphanum ; 已注册的变体 / (DIGIT 3alphanum) extension = singleton 1*("-" (2*8alphanum)) ; 单个字母数字字符 ; "x" 保留用于私用 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 ; 在 RFC 3066 时期注册的 / regular ; 非冗余标签 irregular = "en-GB-oed" ; 不规则标签不匹配 / "i-ami" ; 'langtag' 产生式，并且 / "i-bnn" ; 否则不会被 / "i-default" ; 视为“格式良好” / "i-enochian" ; 这些标签全部有效， / "i-hak" ; 但大多数已弃用， / "i-klingon" ; 以支持更现代的 / "i-lux" ; 子标签或子标签 / "i-mingo" ; 组合 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" ; 这些标签匹配 'langtag' / "cel-gaulish" ; 产生式，但其子标签 / "no-bok" ; 不是扩展语言 / "no-nyn" ; 或变体子标签：其含义 / "zh-guoyu" ; 由其注册定义， / "zh-hakka" ; 并且所有这些都已弃用， / "zh-min" ; 以支持更现代的 / "zh-min-nan" ; 子标签或子标签序列 / "zh-xiang" alphanum = (ALPHA / DIGIT) ; 字母和数字 图 1：语言标签 ABNF 有关语言标签的示例，请参见附录 A。 所有子标签的最大长度均为八个字符。语言标签中 不允许出现空白。ABNF 产生式 'variant' 中存在一个细微之处：以数字开头的变体最小 长度为四个字符，而以字母开头的变体 最小长度为五个字符。 尽管 [RFC5234] 使用八位组进行描述，但本文档中 描述的语言标签是由 US-ASCII [ISO646] 字符库中的字符组成的序列。只要其他编码包含 US-ASCII 字符库中的相关部分，语言标签可以用于 使用其他编码的文档和应用程序中。例如，使用 [Unicode] 的 UTF-16LE [RFC2781] 编码的 XML 文档。 2.1.1. 语言标签的格式 在任何时候，语言标签及其子标签（包括私用 和扩展）都应被视为不区分大小写：某些子标签存在 大小写约定，但绝不能认为这些约定 承载任何含义。 因此，标签 "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' 蒙古）。 实现可以在不访问 注册表的情况下按如下方式重现这种格式。所有子标签，包括扩展和私用 子标签，都使用小写字母，但存在两个例外：既不位于标签开头 也不出现在单字符子标签之后的两个字母 和四个字母的子标签。此类两个字母的子标签全部采用 大写（如标签 "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）。实现者应该指定与区域设置无关的 大小写操作，以确保子标签的大小写折叠不会 产生该值，因为该值在语言标签中是非法的。例如， 如果使用土耳其语区域设置规则将地区子标签 'in' 转换为大写， 则会产生序列 U+0130 U+004E，而不是 预期的 'IN'。 Phillips & Davis 最佳当前实践 [第 7 页]
RFC 5646 语言标签 2009 年 9 月 2.2. 语言子标签的来源和解释 语言标签及其子标签的命名空间由 互联网号码分配机构（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 注册表中的某些子标签并非来自 底层标准。这些子标签只能出现在标签中的特定位置： 它们只能作为主语言子标签或变体 子标签出现。 私用和扩展子标签序列必须出现在 子标签序列的末尾，并且不得与本文档其他地方 定义的子标签交错出现。这些序列由 单字符子标签引入，这些子标签保留如下： 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 为私用保留的代码。这些代码可以用于 未注册的主语言子标签（而不是使用 'x-' 后的私用子标签）。有关私用子标签的更多信息， 请参阅第 4.6 节。 4. 四字符语言子标签保留用于未来可能的 标准化。 5. IANA 注册表中任何长度为五到八个字符的语言子标签 均通过第 3.5 节中的注册流程定义，并且可以 用于形成主语言子标签。 此类注册可能包含的一个示例是祖父条款 IANA 注册 "i-enochian"。子标签 'enochian' 可以作为主语言子标签注册到 IANA 注册表中 （假设 ISO 639 没有先注册该 语言），从而使诸如 "enochian-AQ" 和 "enochian- Latn" 这样的标签有效。 在创建本文档时，还没有 此类子标签的示例。不鼓励将来注册此类子标签： 任何新提出的主语言都必须尝试向 ISO 639 注册机构注册。 被 ISO 639 注册机构拒绝的提案 不太可能满足主语言子标签的标准，因此 也不太可能被注册。 6. 除非通过修订或更新本文档， 否则不得将其他值分配给主子标签。 当语言同时拥有 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，则不得注册该两字符代码。请参见 第 3.4 节。 例如，如果某些内容使用 'haw'（夏威夷语）标记，而 当前它没有两字符代码，那么即使 ISO 639-1 日后为夏威夷语分配了两字符代码， 也无需更改该标签。 为避免这些与版本控制和子标签选择有关的问题（如 从 RFC 1766 过渡到 RFC 3066 期间所经历的那样），同时 确保本文档所定义子标签的规范性质， ISO 639 注册机构联合咨询委员会 （ISO 639/RA-JAC）在 [iso639.prin] 中包含了以下声明： “在冻结 ISO 639-1 时已经存在于 ISO 639-2 中的语言代码，此后不得添加到 ISO 639-1。 这是为了确保使用上的长期 一致性，因为在互联网应用中，如果某种语言没有可用的 alpha-2 代码，会指示用户使用 alpha-3 代码。” 2.2.2. 扩展语言子标签 扩展语言子标签用于标识某些经过特别 选择的语言，这些语言由于各种历史和兼容性 原因，与现有主语言子标签紧密关联，或使用该 主语言子标签进行标记。扩展语言子标签在用于 构成语言标签时，始终与其所包含的主语言子标签一起使用 （由注册表中的 'Prefix' 字段指示）。 注册表中所有具有扩展语言子标签的语言 也都有一条完全相同的主语言子标签记录。 建议使用该主语言子标签来构成 语言标签。以下规则适用于扩展语言 子标签： 1. 扩展语言子标签仅由三个字母组成。 注册表中定义的所有扩展语言子标签记录 都是根据 [ISO639-3] 中的分配定义的。 语言集合和语言分组，例如 [ISO639-5] 中定义的那些，被明确排除在扩展 语言子标签之外。 Phillips & Davis 最佳当前实践 [第 11 页]
RFC 5646 语言标签 2009 年 9 月 2. 扩展语言子标签记录必须恰好包含一个 'Prefix' 字段，用于指明适用于该扩展语言子标签的 子标签或子标签序列。 3. 扩展语言子标签记录必须包含一个 'Preferred- Value'。'Preferred-Value' 和 'Subtag' 字段必须 完全相同。 4. 尽管 ABNF 产生式 'extlang' 允许语言标签中最多出现三个 扩展语言标签，但扩展语言 子标签的 'Prefix' 中不得包含另一个扩展语言子标签。 也就是说，语言标签中的第二和第三个扩展语言 子标签位置是永久保留的， 在这些位置包含子标签的标签现在无效，并且 将始终保持无效。 例如，宏语言汉语（'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. 文字子标签必须位于任何主语言和扩展语言 子标签之后，并且必须位于任何其他类型的子标签之前。 2. 文字子标签由四个字母组成，其定义依据 [ISO15924]（“信息与 文献 -- 文字名称表示代码”）中的分配， 或 ISO 15924 注册机构或主管标准化机构 随后进行的分配。只有 ISO 15924 分配的代码才会被考虑注册。 Phillips & Davis 最佳当前实践 [第 12 页]
RFC 5646 语言标签 2009 年 9 月 3. 文字子标签 'Qaaa' 到 'Qabx' 保留用于语言标签中的 私用。这些子标签对应于 ISO 15924 为私用保留的代码。这些代码可以用于未 注册的文字值。有关私用子标签的更多 信息，请参阅第 4.6 节。 4. 一个语言标签中最多只能有一个文字子标签，并且 当该文字子标签不会为标签增加任何 区分价值，或者子标签注册表中的主语言或扩展语言 子标签记录包含列出适用文字子标签的 'Suppress-Script' 字段时，应该省略该文字子标签。 例如："sr-Latn" 表示使用拉丁 文字书写的塞尔维亚语。 2.2.4. 地区子标签 地区子标签用于指示与特定国家、 领土或地区相关或适用于该地区的语言变体。 通常，地区子标签用于指示诸如 地区方言或用法、或者特定地区的拼写约定之类的变体。 它也可以用来表示内容是以 适合整个地区使用的方式表达的，例如 针对整个拉丁美洲地区使用而调整的西班牙语内容。 以下规则适用于地区子标签： 1. 地区子标签必须位于任何主语言、扩展 语言或文字子标签之后，并且必须位于任何其他类型的 子标签之前。 2. 两字母地区子标签是根据 [ISO3166-1]（“国家及其下属地区 名称表示代码 -- 第 1 部分：国家 代码”）中的分配，使用 alpha-2 国家代码列表， 或使用 ISO 3166-1 维护 机构或主管标准化机构随后进行的分配定义的。此外， ISO 3166-1 中“例外保留”（而非 “已分配”）的代码也在注册表中定义， 但 'UK' 除外，因为它与已分配的 代码 'GB' 完全同义。 3. 地区子标签 'AA'、'QM'-'QZ'、'XA'-'XZ' 和 'ZZ' 保留用于语言标签中的私用。这些子标签 对应于 ISO 3166 为私用保留的代码。这些 代码可以用作私用地区子标签（而不是 使用私用子标签序列）。有关私用子标签的更多信息， 请参阅第 4.6 节。 Phillips & Davis 最佳当前实践 [第 13 页]
RFC 5646 语言标签 2009 年 9 月 4. 三字符地区子标签仅由数字 字符组成，其定义依据联合国《用于统计用途的国家或地区标准代码》 [UN_M.49] 中的分配，或主管 标准机构随后进行的分配。并非所有 UN M.49 代码都在 IANA 注册表中定义。以下规则规定了哪些代码 作为有效子标签录入注册表： A. 分配给“宏观地理 （大陆）”或次区域的联合国数字代码必须注册到 注册表中。这些代码不与已分配的 ISO 3166-1 alpha-2 代码关联，并表示跨国区域， 通常涵盖多个国家、州、省或 领土。 B. 用于“经济分组”或“其他 分组”的联合国数字代码不得注册到 IANA 注册表中， 也不得用于构成语言标签。 C. 当 ISO 3166-1 将原先用于某个 国家或地区的代码重新分配给另一个国家或地区，并且该代码 已存在于注册表中时，该国家或地区的联合国数字代码 必须按照第 3.4 节所述注册到注册表中，并且必须 用于构成表示其所定义国家或地区的语言 标签（而不是使用被重新利用的 ISO 3166-1 代码）。 D. 对于在注册表中已有相关 ISO 3166-1 alpha-2 代码的国家或地区，其联合国数字代码不得 录入注册表，也不得用于构成 语言标签。请注意，注册表中基于 ISO 3166 的子标签 实际上必须与相关的 UN M.49 代码 关联。 E. 出于历史原因，联合国数字代码 830（海峡 群岛）在本文档通过时尚未注册，并且当时 没有对应的 ISO 3166-1 代码，可以通过 第 3.5 节所述流程录入 IANA 注册表， 前提是此前没有注册过含义完全相同的 ISO 3166-1 代码。 F. 对于没有相关 ISO 3166-1 alpha-2 代码的国家或地区， 所有其他联合国数字代码不得 录入注册表，也不得用于构成 语言标签。有关这些代码的更多信息，请参见 第 3.4 节。 Phillips & Davis 最佳当前实践 [第 14 页]
RFC 5646 语言标签 2009 年 9 月 5. 联合国文档附录 X中的字母数字代码不得 录入注册表，也不得用于构成 语言标签。（在创建本文档时，这些 值与 ISO 3166-1 alpha-2 代码相匹配。） 6. 一个语言标签中最多只能有一个地区子标签， 并且当地区子标签不会为标签增加任何区分价值时， 可以省略它。 例如： "de-AT" 表示在奥地利（'AT'）使用的德语（'de'）。 "sr-Latn-RS" 表示在塞尔维亚（'RS'）使用的、 以拉丁文字（'Latn'）书写的塞尔维亚语（'sr'）。 "es-419" 表示适用于联合国定义的 拉丁美洲和加勒比地区（'419'）的西班牙语（'es'）。 2.2.5. 变体子标签 变体子标签用于指示定义一种语言或其方言的、 其他可广泛识别但未被其他可用子标签 涵盖的变体。以下规则适用于 变体子标签： 1. 变体子标签必须位于任何主语言、扩展 语言、文字或地区子标签之后，并且必须位于任何 扩展或私用子标签序列之前。 2. 作为一个集合，变体子标签并不与任何 特定的外部标准相关联。注册表中变体子标签的含义 在第 3.5 节所定义的注册过程中确定。 请注意，某个特定变体子标签可能与某个外部标准 相关联。但是， 注册并不要求必须与某个标准关联。 3. 可以使用多个变体来构成语言标签。 4. 变体子标签在用于构成 语言标签之前，必须按照本文档第 3.5 节中的规则 向 IANA 注册。为了将变体与其他类型 的子标签区分开来，注册必须满足以下长度和 内容限制： 1. 以字母（a-z、A-Z）开头的变体子标签必须 至少为五个字符。 Phillips & Davis 最佳当前实践 [第 15 页]
RFC 5646 语言标签 2009 年 9 月 2. 以数字（0-9）开头的变体子标签必须至少 为四个字符。 5. 同一个变体子标签不得在一个 语言标签中使用多次。 * 例如，标签 "de-DE-1901-1901" 无效。 语言子标签注册表中的变体子标签记录可以包含 一个或多个 'Prefix'（第 3.1.8 节）字段。每个 'Prefix' 都指示 使用该变体时，适合用于构成语言标签的 子标签序列（必要时可与其他子标签 组合）。 大多数共享同一前缀的变体彼此互斥。例如， 德语正字法变体 '1996' 和 '1901' 不应该 用在同一个标签中，因为它们表示不同 拼写改革的年份。如果某个变体能够有意义地 与另一个变体组合使用，则其注册记录中应该包含 一个列出另一个变体的 'Prefix' 字段。例如，如果 创建了另一个德语变体 'example'，并且它适合与 '1996' 一起使用，那么 'example' 应包含两个 'Prefix' 字段："de" 和 "de-1996"。 例如： "sl-nedis" 表示斯洛文尼亚语的 Natisone 或 Nadiza 方言。 "de-CH-1996" 表示在瑞士使用、并按照 公元 1996 年开始的拼写改革书写的德语。 2.2.6. 扩展子标签 扩展提供了一种机制，可扩展语言标签以用于 各种应用。它们旨在标识通常与 语言或语言标签结合使用、但不属于语言标识 本身的信息。请参见第 3.7 节。以下规则适用于扩展： 1. 扩展之前必须至少有一个主语言子标签。 也就是说，语言标签不能以扩展开头。 扩展用于扩展语言标签，而不是覆盖或替换 它们。例如，"a-value" 不是格式良好的语言标签， 而 "de-a-value" 是。请注意，扩展不能用于 完全由私用内容构成的标签（即以 "x-" 开头的标签）。 Phillips & Davis 最佳当前实践 [第 16 页]
RFC 5646 语言标签 2009 年 9 月 2. 扩展子标签通过一个单字符子标签（称为 “singleton”）与本文档定义的其他子标签分隔。 该 singleton 必须是通过第 3.7 节所述机制 分配给某个注册机构的值， 并且不得是字母 'x'，因为 'x' 保留用于私用 子标签序列。 3. 每个 singleton 子标签在每个标签中最多只能出现一次 （作为私用子标签出现的情况除外）。也就是说，singleton 子标签 不得重复。例如，标签 "en-a-bbb-a-ccc" 无效，因为子标签 'a' 出现了两次。请注意，标签 "en-a-bbb-x-a-ccc" 是有效的，因为 singleton 'a' 的第二次 出现位于私用序列中。 4. 扩展子标签必须满足定义其 singleton 前缀的 文档所规定的任何要求，以及维护机构 提供的任何要求。请注意， 这些子标签可能不存在注册表， 并且验证处理器无需验证扩展。 5. 每个扩展子标签的长度必须为二到八个字符， 并且只能由字母或数字组成，各子标签之间 由单个 '-' 分隔。扩展中的大小写差异会被忽略 （与任何语言子标签一样），并且此类规范化 子标签应采用小写形式。 6. 每个 singleton 后必须至少跟一个扩展子标签。 例如，标签 "tlh-a-b-foo" 无效，因为第一个 singleton 'a' 后面紧接着另一个 singleton 'b'。 7. 扩展子标签必须位于标签中的所有主语言、扩展 语言、文字、地区和变体子标签之后，并且必须 位于任何私用子标签序列之前。 8. singleton 之后且另一个 singleton 之前的所有子标签 都属于该扩展。例如：在标签 "fr-a-Latn" 中， 子标签 'Latn' 并不表示 IANA 语言子标签注册表中 定义的文字子标签 'Latn'。其含义由 扩展 'a' 定义。 9. 如果一个标签中出现多个扩展， 应按照第 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. 私用子标签必须符合 ABNF 中为所有子标签定义的 格式和内容约束；也就是说，它们 只能由字母和数字组成，并且长度不得超过八个 字符。 3. 私用子标签必须位于标签中的所有主语言、扩展 语言、文字、地区、变体和扩展子标签之后。 换句话说，singleton 'x' 之后的所有子标签 都必须被视为私用。例如：标签 "en-x-US" 中的子标签 'US' 是私用子标签。 4. 一个标签可以完全由私用子标签组成。 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 代码之一，用于表示一个 原本未定义的地区。用户不得分配使用 注册表中不存在的子标签的语言标签，私用 序列中的子标签除外（例如标签 "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 终止。每个字段中的文本必须 采用 Unicode 规范化形式 C（NFC）。 Phillips & Davis 最佳当前实践 [第 21 页]
RFC 5646 语言标签 2009 年 9 月 一组字段构成一条“记录”。记录之间由 仅包含序列 "%%"（U+0025 U+0025）的行分隔。 尽管字段在逻辑上是单行文本，但文件格式中的每一行 文本长度限制为 72 字节。为了 适应这一限制，field-body 可以拆分成多行 表示；这称为“折叠”。折叠按照 常用的换行约定进行。通常在 空白边界处换行，但当值不包含空格时，也可以在其他 字符之间换行，例如某种语言的词与词之间 不使用空白的情况。无论如何，都不得在 多字节 UTF-8 序列内部或组合 字符序列中间断行。有关更多信息，请参见 [UAX14]。 尽管文件格式使用 Unicode 字符集，并且文件 本身使用 UTF-8 编码，但除非 特定字段的说明中另有指明， 否则字段仅限于 US-ASCII [ISO646] 字符库中的可打印字符 （第 3.1.2 节）。 注册表的格式由以下 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 码位 图 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 在每条记录中不得出现一次以上。 每条记录必须至少包含以下 各字段中的一个： o 'Type' * Type 的 field-body 必须由以下字符串之一组成： "language"、"extlang"、"script"、"region"、"variant"、 "grandfathered" 和 "redundant"；它表示标签或 子标签的类型。 o 'Subtag' 或 'Tag' * Subtag 的 field-body 包含正在定义的子标签。此 字段必须出现在 'Type' 具有以下 值之一的所有记录中："language"、"extlang"、"script"、"region" 或 "variant"。 * Tag 的 field-body 包含一个完整的语言标签。此字段 必须出现在 '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] 规则注册的日期。 每条记录还可以包含以下字段： 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 包含一个有效语言标签， 建议将其作为此记录子标签的一种可能前缀。 此字段可以出现在 'Type' field-body 为 'extlang' 或 'variant' 的记录中（不得出现在任何其他 记录类型中）。 o 'Suppress-Script' * Suppress-Script 的 field-body 包含一个文字子标签， 不应该使用该子标签与相关的 主语言或扩展语言子标签构成语言标签。此字段只能 出现在 'Type' field-body 为 'language' 或 'extlang' 的记录中。参见第 4.1 节。 o 'Macrolanguage' * Macrolanguage 的 field-body 包含一个由 ISO 639 定义为涵盖此语言子标签的“宏语言”的主语言子标签。 此字段只能出现在 '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 包含有关该 子标签的附加信息，这些信息被认为有助于理解注册表， 以及使用该子标签或标签实现语言标签。 本文档的未来版本可能会向 注册表添加额外字段；实现应该忽略注册表中 本文档未定义的字段。 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 必须遵循 第 2.1.1 节所述的大小写约定。所有子标签在 field- body 中都使用小写字母，但有两个例外： 'Type' 字段为 'script' 的子标签（换言之， 由 ISO 15924 定义的子标签）必须使用首字母大写形式。 'Type' 字段为 'region' 的子标签（换言之，由 ISO 3166-1 定义的非数字地区子标签）必须全部 使用大写。 'Tag' field-body 必须按照 第 2.1.1 节所述规则进行格式化。 3.1.5. Description 字段 字段 'Description' 包含对记录中标签或子标签的描述。 'Description' 字段可以在每条记录中出现多次。 'Description' 字段可以包含完整范围的 Unicode 字符。至少一个 'Description' 字段必须 使用拉丁文字书写或转写；其他 'Description' 字段可以使用任何文字或语言。 'Description' 字段用于标识目的。 描述应该包含区分一个子标签与其他可能与其 混淆的子标签所必需的全部且仅限这些信息。 它们并非旨在提供一般背景 信息，也并非旨在提供所有可能的替代名称或 称谓。'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' 字段。源标准的 描述可以在插入之前或通过注册流程 进行编辑或修改，并且可以省略或删除额外或 无关的描述。每个 'Description' 字段 在其所在记录中必须唯一，并且在该特定 记录中不应该出现同一描述的格式 变体。例如，虽然 ISO 639-1 代码 'fy' 在该标准中同时有 描述 "Western Frisian" 和描述 "Frisian, Western"， 但注册表中只出现其中一个描述。 为帮助确保用户不会对应该使用哪个子标签感到困惑， 分配给任何特定类型 （'language'、'extlang'、'script' 等）记录的 'Description' 字段 必须在给定记录类型中唯一，但以下情况除外：如果某个 特定 'Description' 字段出现在给定类型的多个记录中， 则最多只能有一条记录省略 'Deprecated' 字段。共享同一 'Description' 的所有已弃用记录必须具有 相同的 'Preferred-Value'，而所有未弃用记录必须是 该 '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 与注册表之间的交叉引用。 当由于某个源标准的操作而创建或更新记录时， 语言子标签审查员可以在将拟议记录提交到 ietf-languages@iana.org 列表供审议之前，对描述进行编辑， 以纠正格式不规则之处（例如拼写错误、 不恰当的撇号或其他标点符号，或者过多或 缺失的空格）。 3.1.6. Deprecated 字段 字段 'Deprecated' 包含记录被弃用的日期， 并且可以通过第 3.3 节所述的维护流程 或第 3.5 节所述的注册流程，在任何记录中 添加、更改或删除。通常，添加 'Deprecated' 字段是由于某个标准 机构（例如 ISO 3166）撤销了某个代码。尽管在 语言标签中仍然有效，但带有 'Deprecated' 字段的子标签和标签 已被弃用，验证处理器不应该生成这些 子标签。请注意，包含 'Deprecated' 字段但 没有相应 'Preferred-Value' 字段的记录不存在替代映射。 在某些历史情况下，可能无法 重建原始弃用日期。在这些情况下， 注册表中会出现一个近似日期。一些子标签以及一些 祖父条款标签或冗余标签在注册表最初 创建之前就已弃用。有关这方面的确切规则，请参见 [RFC4645] 的第 2 节。请注意，这些记录中的 'Deprecated' 字段 日期早于相应的 'Added' 字段！ 3.1.7. Preferred-Value 字段 字段 'Preferred-Value' 包含其所在记录与 另一个标签或子标签之间的映射（取决于记录的 'Type'）。该字段中的值用于规范化（参见 第 4.5 节）。如果子标签或标签还具有 'Deprecated' 字段，则在选择语言标签时，建议将 'Preferred-Value' 作为表示该记录值的 最佳选择。 包含 'Preferred-Value' 的记录属于以下四 组之一： Phillips & Davis 最佳当前实践 [第 28 页]
RFC 5646 语言标签 2009 年 9 月 1. 后来被撤销并改用 其他代码的 ISO 639 语言代码。这些值大多只具有历史意义。 上面的 'he'/'iw' 配对就是一个例子。 2. 取自后来被撤销并改用新代码的 代码或值的子标签（类型不是 language 或 extlang）。 这尤其适用于取自 ISO 3166-1 的地区子标签，因为有时一个国家会更改名称或 行政体制，从而需要新的地区代码。 在某些情况下，国家恢复了较早的名称，而该名称可能 已经被编码。例如，子标签 'ZR'（Zaire）在 该国名称更改后被子标签 'CD'（Democratic Republic of the Congo） 取代。 3. 因其所表示的值后来被编码而变得过时的 标签或子标签。例如，许多祖父条款标签或 冗余标签后来被 ISO 639 编码， 因而属于这一类。例如，"i-klingon" 在 添加子标签 'tlh' 时被弃用。"i-klingon" 的记录具有 'tlh' 这一 'Preferred-Value'。 4. 扩展语言子标签始终映射到其 相同的主语言子标签。例如，扩展 语言子标签 'yue'（粤语）可以用于构成标签 "zh-yue"。它具有到主 语言子标签 'yue' 的 'Preferred-Value' 映射，这意味着诸如 "zh-yue-Hant-HK" 的标签可以规范化为 "yue-Hant-HK"。 除类型为 'extlang' 的记录外，包含 'Preferred- Value' 字段的记录还必须具有 'Deprecated' 字段。该字段 包含标签或子标签因采用 首选值而被弃用的日期。 对于类型为 'extlang' 的记录，'Preferred-Value' 字段 在没有相应 'Deprecated' 字段的情况下出现。实现可以 忽略这些首选值映射，不过如果忽略该 映射，则应该始终如一地忽略。它还应该将 'Preferred-Value' 视为与映射项等价。例如， 标签 "zh-yue-Hant-HK" 和 "yue-Hant-HK" 在语义上等价， 应当被视为相同的标签。 有时，在某些上下文中已弃用的代码反而是首选。 例如，"iw" 和 "he" 都可以在 Java 编程 语言中使用，但输入时 "he" 会被转换为 "iw"，因此后者 是 Java 中的规范形式。 Phillips & Davis 最佳当前实践 [第 29 页]
RFC 5646 语言标签 2009 年 9 月 类型为 'region' 的记录中的 'Preferred-Value' 映射有时 并不表示与原始值完全相同的含义。国家代码发生更改 有很多原因，而这对语言标签构成产生的影响 将取决于相关更改的性质。例如，地区子标签 'YD' （Democratic Yemen）在 1990 年两国统一时 被弃用并改用子标签 'YE'（Yemen）。 可以根据第 3.3 节中的规则向记录添加、更改或删除 'Preferred-Value'。记录中 'Preferred-Value' 字段的 添加、修改或删除并不意味着 使用受影响子标签的内容需要重新标记。 类型为 "grandfathered" 和 "redundant" 的记录中的 'Preferred-Value' 字段各自包含一个 “扩展语言范围”[RFC4647]，强烈建议使用该范围 代替记录的值。在许多情况下，这些映射是在 [RFC4646] 采用之前，通过弃用标签而创建的。例如，标签 "no-nyn" 被弃用，改用 ISO 639-1 定义的语言 代码 'nn'。 类型为 "extlang" 的子标签记录中的 'Preferred-Value' 字段也 包含一个“扩展语言范围”。这允许该子标签 被弃用并改用单个主语言子标签或 新的 language-extlang 序列。 通常，为子标签添加、删除或更改 'Preferred-Value' 字段是为了反映某个源 标准的变化。例如，如果某个 ISO 3166-1 地区代码被弃用 并改用另一个代码，则应该因此添加 'Preferred-Value' 字段。 一个子标签的更改也可能影响其他子标签：在 提议更改注册表时，语言子标签审查员必须 检查注册表是否存在这种影响，并使用第 3.5 节中的流程 提出必要的更改，不过任何人都可以请求 此类更改。例如： 假设子标签 'XX' 的 'Preferred-Value' 为 'YY'。如果 'YY' 后来更改为具有 'ZZ' 这一 'Preferred-Value'，则 'XX' 的 'Preferred-Value' 也必须更改为 'ZZ'。 假设已注册的语言子标签 'dialect' 表示一种 尚未在 ISO 639 的任何部分提供的语言。后来 在 ISO 639 中添加相应的语言代码时，应该为 'dialect' 添加一个 'Preferred-Value'。 Phillips & Davis 最佳当前实践 [第 30 页]
RFC 5646 语言标签 2009 年 9 月 3.1.8. Prefix 字段 字段 'Prefix' 包含一个有效语言标签，建议将其 作为此记录子标签的一种可能前缀，也可能还包含其他 子标签。也就是说，当语言标签中包含至少具有一个 'Prefix' 的扩展语言子标签或变体 子标签时，所得标签应该使用“扩展过滤”算法 （参见 [RFC4647]）匹配该子标签至少一个 'Prefix' 字段，并且该 'Prefix' 中的每个子标签都应该出现在 子标签本身之前。 'Prefix' 字段必须在类型为 'extlang' 的记录中恰好出现一次。'Prefix' 字段可以在 类型为 'variant' 的记录中出现多次（或完全不出现）。 可以通过注册流程向 'variant' 记录添加此类型的额外 字段，前提是该 'variant' 记录已经至少有一个 'Prefix' 字段。 每个 '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'）中的每一个一起使用，还表明它应该 出现在标签中这些变体之后。因此，语言标签 应采用 "sl-rozaj-biske-1994" 的形式，而不是 "sl-1994- rozaj-biske" 或 "sl-rozaj-1994-biske"。 如果一条记录不包含 'Prefix' 字段，则以后不得 向该记录添加 'Prefix' 字段。否则，可以 注册对 'Prefix' 字段集合的更改（添加、 删除或修改），只要它们严格扩大推荐的语言标签 范围。例如，值为 "be- Latn"（白俄罗斯语、拉丁文字）的 'Prefix' 可以替换为值 "be" （白俄罗斯语），但不能替换为值 "ru-Latn"（俄语、拉丁文字） Phillips & Davis 最佳当前实践 [第 31 页]
RFC 5646 语言标签 2009 年 9 月 或值 "be-Latn-BY"（白俄罗斯语、拉丁文字、白俄罗斯），因为 后两者会改变或缩小建议标签的范围。 'Prefix' 字段的 field-body 不得与 给定记录中已经注册的任何 'Prefix' 冲突。如果无法构造 一个能够包含该前缀的有效标签，则会发生这种冲突， 例如两个子标签各自都有一个包含 另一个子标签的 'Prefix'。例如，假设子标签 'avariant' 的前缀为 "es-bvariant"。那么不能为子标签 'bvariant' 分配前缀 'avariant'，因为这将要求存在 "es-avariant-bvariant-avariant" 形式的标签，而该标签 无效。 3.1.9. Suppress-Script 字段 字段 'Suppress-Script' 包含一个文字子标签（其记录 出现在注册表中）。字段 'Suppress-Script' 只能出现在 'Type' field-body 为 'language' 或 'extlang' 的记录中。此字段在一条 记录中不得出现一次以上。 此字段指示一种用于书写给定语言绝大多数 文档的文字。因此，这种文字的子标签 不会为语言标签增加任何区分信息， 因而对于该语言的大多数文档不应该使用。 省略此字段所指示的文字子标签，有助于确保 根据本文档规则生成的语言标签与 基于 RFC 3066 的语言标签以及标签处理器或 消费者之间具有更好的兼容性。例如，几乎所有冰岛语 文档都使用拉丁文字书写，因此子标签 'Latn' 在标签 "is-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' 字段。宏语言信息仅供参考， 如果 ISO 639-3 更改这些值，可以删除或更改它们。 有关此字段的使用以及如何在 宏语言和涵盖语言子标签之间进行选择的更多信息，请参见 第 4.1.1 节。 例如，语言子标签 'nb'（Norwegian Bokmal）和 'nn' （Norwegian Nynorsk）各有一个值为 'no'（Norwegian）的 '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' 字段可以出现在类型为 'language' 或 'extlang' 的记录中。请注意，许多扩展语言 子标签的前缀将具有 'macrolanguage' 这一 'Scope'（尽管有些 不会），而许多具有 'macrolanguage' 这一 'Scope' 的语言 将具有与之关联的扩展语言子标签。 可以通过注册流程添加、修改或删除 'Scope' 字段，前提是该更改反映 ISO 639 对该分配分类所做的更改。预计这种更改 很少发生。 例如，主语言子标签 'zh'（Chinese）的 'Scope' 为 'macrolanguage'，而其涵盖语言 'nan'（Min Nan Chinese）的 'Scope' 为 'individual'。特殊值 'und' （Undetermined）的 'Scope' 为 'special'。ISO 639-5 集合 'gem'（Germanic languages）的 'Scope' 为 'collection'。 3.1.12. Comments 字段 字段 'Comments' 包含有关记录的附加信息， 并且可以在每条记录中出现多次。field-body 可以包含 完整范围的 Unicode 字符，并且不受任何 特定文字限制。此字段可以通过 注册流程插入或更改，并且不提供稳定性保证。 此字段的内容不受限制，除了需要 注册相关信息、请求必须适当，以及受到 合理实际大小限制之外。'Comments' 字段的主要用途是 子标签标识——帮助将该子标签与其他可能 与其混淆的子标签区分开来，以辅助 使用。通常不鼓励包含大量有关子标签用途、历史或 一般背景的信息，因为这些内容通常 应放在注册请求中，而不是注册表中。 Phillips & Davis 最佳当前实践 [第 34 页]
RFC 5646 语言标签 2009 年 9 月 3.2. 语言子标签审查员 语言子标签审查员负责管理 ietf-languages@iana.org 邮件列表，响应注册请求，并执行第 3.3 节所述的 其他注册表维护职责。只有 语言子标签审查员获准请求 IANA 对语言子标签注册表中的 记录进行更改、更新或添加。语言 子标签审查员可以根据需要委派列表管理和其他文书 工作。 语言子标签审查员由 IESG 任命， 任期不定，IESG 可自行决定将其免职或替换。 IESG 将征集该职位的候选人（在 本文档获得采用时或职位空缺时），随后征集 对候选人资格的反馈。合格的候选人 应熟悉 BCP 47 及其要求；愿意 公平、及时且审慎地管理注册 流程；并充分了解语言 标识方面的问题，从而使审查员能够评估相关主张，并 借助语言专家和子标签请求者的意见。 语言子标签审查员之后的履职情况或决定 可以按照其他 IETF 决定适用的相同规则 向 IESG 提出申诉（参见 [RFC2026]）。IESG 可以撤销或推翻 语言子标签审查员的决定、提供指导或采取 其他适当措施。 3.3. 注册表的维护 注册表的维护要求，当 ISO 639、ISO 15924、ISO 3166 和 UN M.49 分配或撤销代码时，语言 子标签审查员必须评估每项更改，并按照本文档中的规则 确定适当的处理方式。 此类更新遵循第 3.5 节所述的注册流程。通常， 语言子标签审查员会通过填写注册 表单并提交它来启动新增或更新记录的 流程。如果其中一个标准发生更改，而语言子标签审查员 未及时执行此操作，则任何相关方都可以提交该表单。 此后， 注册流程照常继续。 请注意，某些注册会影响其他子标签——可能不止 一个——例如当一个地区子标签被弃用并改用新的 值时。语言子标签审查员负责确保 所有此类更改都得到正确注册，并且每项更改都需要 单独的注册表单。 Phillips & Davis 最佳当前实践 [第 35 页]
RFC 5646 语言标签 2009 年 9 月 语言子标签审查员必须确保新子标签满足 本文档其他地方（尤其是 第 3.4 节）的要求，或者按照该节所述，为替代子标签 提交适当的注册表单。受更改影响的每个 单独子标签都必须使用其自己的注册表单 发送到 ietf-languages@iana.org 列表，并且每个 单独发送一封消息。 3.4. IANA 注册表条目的稳定性 注册表中条目及其含义的稳定性 对语言标签的长期稳定性至关重要。本节中的规则 保证特定语言标签的含义 随时间保持稳定且不会改变。 这些规则专门规定如何将由 ISO 639、ISO 15924、ISO 3166 和 UN M.49 维护的代码变化（包括 代码的撤销和弃用）反映到 IANA 语言 子标签注册表中。向 IANA 语言子标签注册表进行的分配 必须遵循以下稳定性规则： 1. 'Type'、'Subtag'、'Tag' 和 'Added' 字段中的值 不得更改，并保证随时间保持稳定。 2. 'Preferred-Value' 和 'Deprecated' 字段中的值可以 通过注册流程添加、更改或删除。这些 更改应该仅限于为反映某个底层标准 （ISO 639、ISO 15924、ISO 3166-1 或 UN M.49）的更改所必需的情况， 并且通常 'Preferred-Value' 的更改或删除 专门限于地区代码。 3. 'Description' 字段中的值不得以 会使任何现有标签失效的方式更改。描述可以在范围上 略微扩展、进行更改以添加信息，或者 调整为最常见的现代用法。例如，国家 偶尔会更改名称；一个历史示例是 "Upper Volta" 改名为 "Burkina Faso"。 4. 可以通过注册流程向类型为 'variant' 的现有记录添加 'Prefix' 字段，前提是该 'variant' 已经至少有一个 'Prefix'。任何没有现有 'Prefix' 字段的 'variant' 都不得注册 'Prefix' 字段。 如果向变体记录添加前缀， 可以使用 'Comment' 字段解释不同前缀的 各种用法。 Phillips & Davis 最佳当前实践 [第 36 页]
RFC 5646 语言标签 2009 年 9 月 5. 类型为 'variant' 的记录中 'Prefix' 字段的值也可以 修改，只要这些修改扩大前缀 集合。也就是说，一个前缀可以替换为它自己的 前缀之一。例如，前缀 "en-US" 可以替换为 "en"，但不能替换为前缀 "en-Latn"、"fr" 或 "en-US- boont"。如果需要其中某个前缀值，则必须 单独注册。 6. 类型为 'extlang' 的记录中 'Prefix' 字段的值 不得添加、修改或删除。 7. 'Prefix' 字段不得从任何已包含该字段的记录中 删除。此字段应该包含在任何类型为 'variant' 的记录的 初始注册中，并且必须 包含在任何类型为 'extlang' 的记录中。 8. 可以通过注册流程或本节所述的任何流程或 考虑事项来添加、更改、修改或删除 'Comments' 字段。 9. 可以通过注册流程添加或删除 'Suppress-Script' 字段。 10. 可以通过注册流程添加或删除 'Macrolanguage' 字段，但只能作为对 ISO 639 所作更改的响应。只要某种语言在 ISO 639 中有相应的宏语言，就会出现 'Macrolanguage' 字段。也就是说，注册表中的 'Macrolanguage' 字段与 ISO 639 中的完全匹配。 不会考虑注册任何其他宏语言映射。 11. 初始注册后，可以向主语言或 扩展语言子标签添加或删除 'Scope' 字段，也可以 对其进行修改以匹配 ISO 639 所作的任何更改。 对 'Scope' 字段的更改必须反映 ISO 639 所作的更改。请注意，记录中不包含 'Scope' 字段的主语言或扩展语言子标签（即其中的大多数） 是第 3.1.11 节所述的单独语言。 12. 主语言和扩展语言子标签（不包括使用注册流程 创建的独立注册值） 根据 ISO 639 各部分的分配创建， 如下所示： A. ISO 639-1 分配的代码，如果不与 现有两字母主语言子标签冲突，并且在 注册表中没有对应的三字母主语言定义， 则作为新记录录入 IANA 注册表 Phillips & Davis 最佳当前实践 [第 37 页]
RFC 5646 语言标签 2009 年 9 月 类型为 'language' 的记录。请注意，被分配了 ISO 639-1 代码的语言不能再被分配扩展语言子标签，即使 它被某个宏语言涵盖也是如此。 B. ISO 639-3 或 ISO 639-5 分配的代码，如果不与 现有三字母主语言子标签冲突， 并且没有被分配（或预计将被分配） ISO 639-1 代码，则作为类型为 'language' 的新 记录录入 IANA 注册表。请注意，这两个标准 目前包含 ISO 639-2 代码的超集。在 注册时具有已定义 'macrolanguage' 映射的代码 必须包含一个 'Macrolanguage' 字段。 C. ISO 639-3 分配的代码也可以考虑用于 注册扩展语言子标签。请注意，即使提出了 'extlang' 记录，也必须为其分配一个类型为 'language' 的主语言子标签记录。在 考虑分配扩展语言子标签时，适用以下 标准： 1. 如果一种语言具有宏语言映射，并且该 宏语言还包含其他已被 分配扩展语言子标签的涵盖语言，那么该新 语言也应该被分配一个 'extlang' 记录。 例如，宏语言为 'zh' 或 'ar' 的任何语言 都会被分配一个 'extlang' 记录。 2. 如果宏语言涵盖的其他语言 也不包含 'extlang' 记录，则不应该为这些语言 创建 'Extlang' 记录。例如，如果注册了一种新的 塞尔维亚-克罗地亚语（'sh'）语言，它将 不会获得 extlang 记录，因为其他被涵盖的语言， 例如塞尔维亚语（'sr'），在注册表中也没有此类 记录。 3. 手语应该具有一个以 'sgn' 为 'Prefix' 的 'extlang' 记录。 4. 不得为已经存在于 注册表中的项目创建 'Extlang' 记录。扩展语言子标签只会在 初始注册时予以考虑。 5. 扩展语言子标签记录必须包含 '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 分配后又被各自 维护机构或注册机构撤销的代码，在语言标签中 仍然有效。必须向记录中添加一个包含 撤销日期的 'Deprecated' 字段。如果添加了 同类型且表示替代值的新记录，那么也可以 添加一个 'Preferred-Value' 字段。可以使用注册流程 添加有关相应标准撤销该代码的注释。 例如：地区代码 'TL' 被分配给国家 'Timor-Leste'，取代代码 'TP'（该代码在 'East Timor' 由葡萄牙管理时被分配）。 子标签 'TP' 在语言标签中仍然有效，但其 记录包含值为 'TL' 的 'Preferred-Value'，并且其 'Deprecated' 字段包含新代码被分配的日期 （'2004-07-06'）。 15. ISO 639、ISO 15924 或 ISO 3166-1 分配的代码，如果 与相关类型的现有子标签冲突，包括 已弃用的子标签，则不得录入 注册表。对于重新分配的 子标签值，还适用以下附加考虑事项： A. 对于 ISO 639 代码，如果新分配代码的含义 尚未由 IANA 注册表中的某个子标签表示， 则语言子标签审查员应按照第 3.5 节所述， 尽快准备一份提案， 将一个已注册语言子标签作为该新代码的 替代值录入 IANA 注册表。 已注册语言子标签的形式由 语言子标签审查员自行决定，并且必须符合本文档中 对语言子标签的其他限制。 B. 对于含义源自外部 标准的所有子标签（即 ISO 639、ISO 15924、ISO 3166-1 或 UN M.49），如果为现有代码分配了新的含义，并且 新含义扩大了该代码的含义，那么 相关子标签的含义可以相应更改。 Phillips & Davis 最佳当前实践 [第 39 页]
RFC 5646 语言标签 2009 年 9 月 但是，子标签的含义不得缩小， 因为这可能导致现有 子标签用法中未知比例的用法变得无效。注意：ISO 639 注册机构（RA）已采用类似的稳定性 策略。 C. 对于 ISO 15924 代码，如果新分配代码的含义 尚未由 IANA 注册表中的子标签表示， 则语言子标签审查员应按照第 3.5 节所述， 尽快准备一份提案， 将一个已注册变体子标签作为 新代码的替代值录入 IANA 注册表。 已注册变体子标签的形式由 语言子标签审查员自行决定，并且必须符合本文档中 对变体子标签的其他限制。 D. 对于 ISO 3166-1 代码，如果新分配代码的含义 与另一个 'region' 子标签关联的是同一个 UN M.49 代码， 则现有地区子标签仍然作为该地区的 首选值，并且不会创建新条目。 可以向现有地区子标签添加注释， 指明其与新 ISO 3166-1 代码之间的关系。 E. 对于 ISO 3166-1 代码，如果新分配代码的含义 与尚未由现有地区子标签表示的 UN M.49 代码关联， 则语言子标签 审查员应按照第 3.5 节所述准备一份 提案，将适当的 UN M.49 国家代码 作为条目录入 IANA 注册表。 F. 对于 ISO 3166-1 代码，如果不存在相关的联合国数字 代码，则语言子标签审查员必须请求 联合国创建一个。如果在发送请求后 90 天内 未收到联合国的回复，语言 子标签审查员必须尽快准备一份提案， 将一个已注册变体 子标签作为新代码的替代值录入 IANA 注册表。已注册变体子标签的形式 由语言子标签审查员自行决定， 并且必须符合本文档中对变体子标签的其他 限制。这种 情况极不可能发生。 16. UN M.49 同时具有“国家和地区”代码（例如德国的 '276'） 和“地理区域和次区域”代码（例如 欧洲的 '150'）。对于没有 对应 ISO 3166-1 代码的 UN M.49 国家或地区代码，不得 注册，除非其作为某个由于现有子标签 而无法注册的 ISO 3166-1 代码的替代值。 Phillips & Davis 最佳当前实践 [第 40 页]
RFC 5646 语言标签 2009 年 9 月 如果这种代码变得必要，则必须首先请求 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]，祖父条款标签曾经可以 变为冗余标签。但是，所有 可能发生这种情况的标签在本文档 编写之前就已经变为冗余。因此，冗余标签和 祖父条款标签的集合现在是永久且不可变的：不得添加 任何一种类型的新条目，也不得 删除现有条目。有关哪些标签最初被设为 祖父条款标签、哪些被设为冗余标签的决策流程， 见 [RFC4645]。 许多祖父条款标签已被弃用——事实上，它们 甚至在 [RFC4646] 之前就已被弃用。例如，标签 "art-lojban" 被弃用，改用主语言 子标签 'jbo'。本可以通过 将其某些子标签注册为 'variants' 而使这些标签变为 'redundant'。 祖父条款注册中的这些类似 'variant' 的子标签以后不得注册，即使其含义 相似或完全相同。 3.5. 子标签注册程序 任何希望使用当前尚未存在于 IANA 语言子标签注册表中的 子标签，或者希望按照本文档允许的方式 添加、修改、更新或删除现有记录中信息的人， 都必须使用此处给出的程序。 只有类型为 '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 节中的要求，记录才会被批准。 语言子标签注册表单 1. 请求者姓名： 2. 请求者电子邮件地址： 3. 请求的记录： Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Macrolanguage: Comments: 4. 子标签的预期含义： 5. 已发表的语言描述 （书籍或文章）的参考资料： 6. 任何其他相关信息： 图 5：语言子标签注册表单 已完成注册表单的示例可见于附录 B。 已批准注册表单的完整列表可通过 http://www.iana.org 在线获取；读者应注意，语言标签 注册表现已废止，应改为查阅语言 子标签注册表。 Phillips & Davis 最佳当前实践 [第 42 页]
RFC 5646 语言标签 2009 年 9 月 子标签注册表单必须发送至 <ietf-languages@iana.org>。注册请求在获准并提交给 IANA 纳入注册表之前，会经历两周的 审查期。如果在注册流程期间对请求进行了修改 （例如为了满足第 3.1 节中的要求而作出更正，或使 'Description' 字段在给定记录类型中唯一），修改后的表单也必须 至少在提交给 IANA 一周前 发送至 <ietf-languages@iana.org>。 ietf-languages 列表是开放列表，可以通过向 <ietf-languages-request@iana.org> 发送请求来加入。根据 IESG 的要求， 该列表可以由 IANA 或任何第三方托管。 在将任何注册请求转发给 IANA 之前，语言子标签 审查员必须确保满足本文档中的所有要求。 这包括确保 'Subtag' 字段中的值按照 第 3.1.4 节中的说明正确使用大小写，并确保 'Description' 字段按照第 3.1.5 节所述在给定记录类型中唯一。 审查员还必须确保请求中包含适当的 File-Date 记录，以帮助 IANA 更新注册表（参见第 5.1 节）。 注册表单和注册表 记录本身的某些字段允许使用非 ASCII 字符。为了保持一致性和清晰性， 注册请求应该使用 UTF-8 编码。 但是，由于某些邮件客户端不支持这种编码， 注册请求也可以使用其他 编码。语言子标签审查员负责确保 存档的请求表单和注册表记录中都出现正确的 Unicode 字符。如果 IANA 出现转写或编码错误， 语言子标签审查员将请求修复 注册表，并提供帮助 IANA 所需的任何信息。 按照定义，扩展语言子标签（类型 'extlang'）始终 被另一种语言涵盖。因此，所有类型为 'extlang' 的记录在 注册时都必须包含一个 'Prefix' 字段。 此 'Prefix' 字段永远不能更改或删除，任何 此类请求都必须被拒绝。 变体子标签通常被注册用于特定 范围的语言标签，并鼓励变体子标签采用 其所适用语言中的术语。例如， 子标签 'rozaj'（Resian）旨在与 以主语言子标签 "sl"（斯洛文尼亚语）开头的语言标签一起使用，因为 Resian 是斯洛文尼亚语的一种方言。因此，子标签 'rozaj' 适用于 "sl-Latn-rozaj" 或 "sl-IT-rozaj" 等标签。这些 信息存储在注册表的 'Prefix' 字段中。变体 Phillips & Davis 最佳当前实践 [第 43 页]
RFC 5646 语言标签 2009 年 9 月 注册请求应该在注册表单中包含至少一个 'Prefix' 字段。 对已有子标签值分配给定类型的附加记录的 请求必须被拒绝。例如，变体 子标签 'rozaj' 已经存在于注册表中，因此禁止 添加第二条类型为 'variant'、子标签为 'rozaj' 的记录。 给定已注册变体子标签的 'Prefix' 字段存在于 IANA 注册表中，用于指导使用。可以通过提交附加 注册表单来添加额外的 'Prefix' 字段。在该 表单中，"Any other relevant information:" 字段必须表明 这是添加前缀。 如果向变体子标签添加 'Prefix' 字段的请求意味着 不同的语义含义，则应该被拒绝。例如， 请求向子标签 '1994' 添加前缀 "de"，以便标签 "de-1994" 表示某种德语方言或正字法形式， 应该被拒绝。'1994' 子标签表示一种特定的斯洛文尼亚语 正字法，而额外注册会改变或模糊 分配给该子标签的语义含义。应该改为 提出一个单独的子标签。 向当前没有 'Prefix' 字段的变体子标签添加 'Prefix' 的请求必须被拒绝。没有 前缀的变体是因为它们可能适用于许多甚至所有 语言。添加一个或多个 'Prefix' 字段可能 损害该变体的使用，因为它会显著缩小 子标签的范围（稳定性规则 （第 3.4 节）不允许这样做），而通常添加 'Prefix' 是为了 扩大子标签的范围。这种 “无前缀”变体的一个示例是子标签 'fonipa'，它表示 国际音标，这是一种可用于 转写多种语言的方案。 请求中提供的 'Description' 字段必须至少包含 一个以拉丁文字书写或转写的描述； 请求还可以包含使用任何 文字或语言的其他 'Description' 字段。'Description' 字段用于 标识目的，并不一定表示语言或变体实际的 本地名称。它也不必 使用任何特定语言，但应该既适当又 足以标识记录中的项目。语言子标签 审查员将检查并编辑任何拟议的 'Description' 字段，以 确保其唯一性，并防止与同类型其他记录中的 'Description' 字段发生冲突。如果这种情况发生在独立 注册请求中，语言子标签审查员必须重新提交 记录至 <ietf-languages@iana.org>，并将其视为对 Phillips & Davis 最佳当前实践 [第 44 页]
RFC 5646 语言标签 2009 年 9 月 讨论所导致请求的修改，如第 3.5 节所述，除非 该请求的唯一目的是引入重复的 'Description' 字段，在这种情况下必须拒绝该请求。 'Description' 字段不保证稳定。 对意图的更正或澄清都是可能的更改示例。 尝试提供注册表中条目的翻译或转写 （按照定义，这不会提供任何新信息） 不太可能获得批准。 两周审查期结束后不久，语言子标签 审查员必须采取以下操作之一： o 明确接受请求，并按照 第 3.3 节所述程序，将包含待插入或修改记录的 表单转发至 <iana@iana.org>。 o 因列表中提出了重大反对意见，或由于违反 本文档中的约束（必须明确引用相关约束）， 明确拒绝请求。 o 将审查期再延长两周， 以便进行进一步讨论。在每次两周 延长期之后，语言子标签审查员必须在列表中说明 注册已被接受、拒绝还是继续延期。 请注意，语言子标签审查员如果愿意，也可以在 列表中提出反对意见。重要的是， 反对意见必须公开提出。 有时，由于审查期内的讨论或 本文档中的要求，需要修改请求。 申请人、语言子标签审查员或其他人可以提交 已填写注册表单的修改版本，经申请人明确批准后， 该版本将取代原始请求接受审议。 此类更改不会重新开始两周的 讨论期，但包含提交给 IANA 的最终 记录的申请必须至少在语言子标签审查员将记录 转发给 IANA 一周前出现在列表中。 申请人可以使用更适当或附加的信息 修改被拒绝的申请并重新提交；这会开始新的两 周评论期。 根据第 3.3 节或 第 3.4 节规定发起的注册不得被完全拒绝（因为它们 最终必须出现在注册表中），并且应该尽快 完成。审查流程允许列表成员对 表单中的具体信息及其包含的记录发表评论，并 Phillips & Davis 最佳当前实践 [第 45 页]
RFC 5646 语言标签 2009 年 9 月 从而帮助确保其正确且一致。语言 子标签审查员可以拒绝表单的某个具体版本，但必须 提出合适的替代版本，并按上述方式延长 审查期，直到表单的格式达到 审查员可以批准的程度，并获得列表的大致共识。 语言子标签审查员作出的决定可以根据与其他 IETF 决定 相同的规则 [RFC2026] 向 IESG [RFC2028] 提出申诉。这包括延长审查期的决定， 或未能清晰及时地公布决定。 已批准的记录将出现在语言子标签注册表中。 已批准的注册表单可以从 http://www.iana.org 在线获取。 对现有记录的更新或更改遵循与 新注册相同的程序。语言子标签审查员在两周 审查期之后决定是否已形成更新注册的共识； 通常，原始注册者提出的反对意见在形成这种共识时 会具有更大的分量。 注册是永久且稳定的。一旦注册，子标签 不会从注册表中删除，并将继续作为 指定某种特定语言或变体的有效方式。 注意：注册表单中 "Reference to published description" 部分 的目的是帮助验证某种语言是否已 注册，或者某个特定子标签所指的是哪种语言或语言变体。 在大多数情况下，引用该语言的权威语法书 或词典会很有帮助；如果不存在这样的 著作，则其他描述该语言或以 该语言撰写的知名著作也可以适用。语言子标签审查员 决定什么构成“足够好”的参考资料。此 要求并非旨在由于说话者人口规模或缺乏 标准化正字法而排除特定语言或 方言。少数语言将根据其自身情况 得到同等考虑。 3.6. 注册的可能情况 子标签或有关子标签信息的注册 可能情况包括： o ISO 639 中未列出、且不是任何已列出或已注册语言 的变体的语言，可以注册其主语言子标签。 在创建本文档时，还没有 这种形式的子标签示例。在尝试注册 语言子标签之前，必须先尝试向 ISO 639 注册该语言 Phillips & Davis 最佳当前实践 [第 46 页]
RFC 5646 语言标签 2009 年 9 月 。对于由 ISO 639-1、ISO 639-2 或 ISO 639-3 中已有代码 定义的语言；正在由 ISO 639 注册 机构审议的语言；或者从未尝试向 这些机构注册的语言，不得注册子标签。如果 ISO 639 以前已拒绝注册某种 语言，那么可以合理地认为，在将其作为主语言子标签 注册到 IANA 注册表之前，必须提供额外且非常有说服力的 需求证据（以至于几乎不可能 注册任何此类子标签）。 o 一种语言内部的方言或其他划分或变体、其 正字法、书写系统、地区或历史用法、 转写或其他转换方式，或者其他具有区分意义的 变体，可以注册为变体子标签。例如 'rozaj' 子标签（斯洛文尼亚语的 Resian 方言）。 o 允许按照第 3.1 节所述，在标签或子标签记录中 添加或维护字段（通常具有 资料性质）。此类更改受 第 3.4 节中的稳定性规定约束。这包括为 过时或已撤销代码添加 'Description'、 'Comments'、'Deprecated' 和 'Preferred-Value' 字段， 或向主语言子标签添加 'Suppress-Script' 或 'Macrolanguage' 字段，以及 本文档允许的其他更改，例如向 变体子标签添加适当的 'Prefix' 字段。 o 允许按照第 3.4 节所述，添加反映 ISO 639、ISO 15924、ISO 3166-1 和 UN M.49 所作分配所必需的记录和相关 字段值更改。 对于拟注册的子标签，如果会使祖父条款标签的全部或部分 变为冗余，但其含义与 祖父条款标签的含义冲突或改变后者的含义，则必须拒绝。 本文档将哪些子标签或对子标签的哪些更改 适当（或不适当）的决定，留给 第 3.5 节所述的注册流程。 注意：四字符主语言子标签被保留，以允许 ISO 639 标准系列未来某个新增部分中可能出现 alpha4 代码。 ISO 639 为 ISO 639 语言列表的新增和更改 定义了一个注册机构。该机构为： Phillips & Davis 最佳当前实践 [第 47 页]
RFC 5646 语言标签 2009 年 9 月 国际术语信息中心（Infoterm） Aichholzgasse 6/12, AT-1120 Wien, Austria 电话：+43 1 26 75 35 Ext. 312 传真：+43 1 216 32 72 ISO 639-2 为 ISO 639-2 语言列表的新增和 更改定义了一个注册机构。该机构为： 美国国会图书馆 网络开发和 MARC 标准办公室 Washington, DC 20540, USA 电话：+1 202 707 6237 传真：+1 202 707 0115 URL：http://www.loc.gov/standards/iso639-2 ISO 639-3 为 ISO 639-3 语言列表的新增和 更改定义了一个注册机构。该机构为： SIL International ISO 639-3 注册员 7500 W. Camp Wisdom Rd. Dallas, TX 75236, USA 电话：+1 972 708 7400, ext. 2293 传真：+1 972 708 7546 电子邮件：iso639-3@sil.org URL：http://www.sil.org/iso639-3 ISO 639-5 为 ISO 639-5 语言列表的新增和 更改定义了一个注册机构。该机构与 ISO 639-2 的相同，即： 美国国会图书馆 网络开发和 MARC 标准办公室 Washington, DC 20540, USA 电话：+1 202 707 6237 传真：+1 202 707 0115 URL：http://www.loc.gov/standards/iso639-5 ISO 3166-1（国家代码）的维护机构为： ISO 3166 维护机构 c/o International Organization for Standardization Case postale 56 CH-1211 Geneva 20, Switzerland 电话：+41 22 749 72 33 传真：+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 联盟 Box 391476 Mountain View, CA 94039-1476, USA URL：http://www.unicode.org/iso15924 联合国秘书处统计司维护 《用于统计用途的国家或地区标准代码》，联系方式如下： 统计服务处 统计司 United Nations, Room DC2-1620 New York, NY 10017, USA 传真：+1-212-963-0623 电子邮件：statistics@un.org URL：http://unstats.un.org/unsd/methods/m49/m49alpha.htm 3.7. 扩展和扩展注册表 扩展子标签是由除 'x' 之外的单字符子标签 （“singletons”）引入的子标签。它们被保留用于生成 包含语言组成部分、并与理解语言标签的 应用程序兼容的标识符。 扩展的结构和形式由本文档定义， 以便可以创建与未来可能使用 singletons 的应用程序 向前兼容的实现。 此外，定义维护 singletons 的机制将 通过减少未来修订或更新的可能需求， 提高本文档的稳定性。 单字符子标签由 IANA 使用 [RFC5226] 定义的 "IETF Review" 策略进行分配。该策略要求制定一份 RFC，其中必须定义维护这些子标签的名称、目的、流程和 程序。维护或 注册机构，包括名称、联系电子邮件、讨论列表 电子邮件以及注册表的 URL 位置，都必须在 RFC 中明确指出。RFC 必须规定或包含以下各项： o 规范必须引用管理其创建的本文档的具体版本或修订版， 并且必须引用本文档的 本节。 o 规范以及由规范定义的所有子标签 必须遵循本文档中定义的标签和 子标签构成所适用的 ABNF 和其他规则。特别是，它必须 Phillips & Davis 最佳当前实践 [第 49 页]
RFC 5646 语言标签 2009 年 9 月 规定大小写不具有意义，并且子标签长度不得 超过八个字符。 o 规范必须规定规范表示形式。 o 有效子标签的规范必须可通过 互联网免费获取。 o 规范必须属于公共领域，或通过 IETF 可接受并在 RFC 中明确说明的免版税许可证提供。 o 规范必须具有版本，并且规范的每个版本 都必须编号、注明日期且保持稳定。 o 规范必须保持稳定。也就是说，扩展子标签 一旦由规范定义，就不得撤销或以任何实质性方式 改变含义。 o 规范必须在单独的章节中包含 本节（下方）所重现的注册表单，以便在 扩展作为 RFC 发布时用于注册。 o 规范的联系信息和 URL 发生变化时，必须通知 IANA。 IANA 将维护已分配单字符 （singleton）子标签的注册表。该注册表必须使用 第 3.1.1 节中 ABNF 所述的 record-jar 格式。扩展 作为 RFC 发布后，RFC 中定义的维护机构 必须将此注册表单转发至 <iesg@ietf.org>，后者必须 将请求转发至 <iana@iana.org>。扩展的维护机构 必须在内容发生变化时，通过向 <iana@iana.org> 发送更新后的完整记录副本来保持记录的准确性，邮件主题 行为 "LANGUAGE TAG EXTENSION UPDATE"。在这些更新中，只能 修改 'Comments'、'Contact_Email'、'Mailing_List' 和 'URL' 字段。 未能维护此记录、维护相应注册表， 或满足本文档本节规定的其他条件，可以 根据与其他 IETF 决定相同的规则（参见 [RFC2026]）向 IESG [RFC2028] 提出申诉，并可能导致 IESG 撤销或重新分配维护 扩展的权限。 Phillips & Davis 最佳当前实践 [第 50 页]
RFC 5646 语言标签 2009 年 9 月 %% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %% 图 6：语言标签扩展注册表中的记录格式 'Identifier' 包含分配给扩展的单字符子标签 （singleton）。提交用于定义扩展的 Internet-Draft 应该 指定使用哪个字母或数字，不过 IESG 在批准 RFC 时可以更改该分配。 'Description' 包含扩展的名称和描述。 'Comments' 是一个可选字段，可以包含对 扩展更广泛的描述。 '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 月 或含义。扩展作者应该避免使用会干扰 匹配或干扰使用该扩展的常见协议中有时存在的 长度限制的子标签关系或规范化 机制。特别是，应用程序在进行 匹配或适应有限长度时可以截断子标签，因此建议 将最重要的信息放在最重要的 （最左侧）子标签中，并且规范应能够妥善处理 被截断的子标签。 当语言标签要用于某个特定的已知协议时， 建议语言标签不要包含该协议 不支持的扩展。此外，请注意某些协议 可以对用于存储或 传输语言标签的字符串长度施加上限。 3.8. 语言子标签注册表的更新 本文档通过后，需要更新 IANA 语言子标签 注册表，以便其中包含语言标签中 有效的完整子标签集合。[RFC5645] 描述了 创建此更新所使用的流程。 在本文档通过时，按照 [RFC4646] 所定义规则正在处理的注册，必须按照 本文档所包含的规则完成。 3.9. 子标签注册表的适用性 语言子标签注册表是按照本文档所述规则 构建语言标签时所用数据元素的来源。 语言标签用于指示各种内容的语言 属性，不仅包括文本，还包括大多数 媒体格式，例如视频或音频。它们也构成各种协议和 API 中 语言和区域设置协商的基础。 因此，该注册表适用于许多需要某种形式 语言标识的应用程序，但存在以下限制： o 它并非被设计为创建 语言选择用户界面时唯一的数据源。例如，注册表 不包含子标签描述或由这些子标签组成的标签的 翻译。基于注册表的本地化数据源通常 可以获得，尤其是 [CLDR]。注册表也不 指明哪些子标签组合特别 有用或相关。 Phillips & Davis 最佳当前实践 [第 52 页]
RFC 5646 语言标签 2009 年 9 月 o 它不提供表示不同语言之间 关系的信息，例如可用于用户界面中按 层级、地区或其他某种 组织模型选择语言标签的信息。 o 它不提供有关不同语言标签之间潜在重叠的 信息，因为“什么构成一种 语言”这一概念并不精确：对于同一给定内容， 几种不同的语言标签都可能是合理的选择。 o 它不包含在执行语言协商时关于适当回退选择的 信息。一个良好的回退语言 可能与指定语言在语言学上没有关系。 一种语言经常被用作另一种语言的回退语言， 通常是由地理、 历史或文化等外部因素导致的——这些因素并不一定适用于所有情况。 例如，大多数使用布列塔尼语（法国西北部使用的一种凯尔特语言） 的人，如果布列塔尼语不可用，可能更愿意获得法语 （一种罗曼语族语言）的内容。 4. 语言标签的形成和处理 本节说明如何将注册表中的信息 与标签语法结合使用，以选择、形成和处理语言标签。 4.1. 语言标签的选择 构成语言标签的指导原则是“明智地标记内容”。 有时同一内容可以选择几个可能的标签。 使用哪个标签取决于 具体的内容和应用程序，在选择标签时 可能需要进行一定判断。 当始终如一地使用同一语言标签表示同一语言时， 最有利于互操作性。如果某个应用程序具有 使此处规则无法适用的要求，那么该 应用程序就有损害互操作性的风险。强烈 建议用户不要自行定义语言标签 选择规则。 规范性引用本文档但采用与本节所给规则不同规则的 标准、协议和应用程序，必须说明其 语言标签选择如何不同于 此处给出的指导原则。 为确保一致的向后兼容性，本文档包含 若干规定，以应对用于定义构成语言标签的 子标签的标准可能存在的不稳定性。 Phillips & Davis 最佳当前实践 [第 53 页]
RFC 5646 语言标签 2009 年 9 月 这些规定意味着，任何有效语言标签都不会变得无效， 语言标签的范围将来也不会变窄（但可能 变宽）。对于给定应用程序或内容项，最适当的语言标签 可能会随时间演变，但一旦应用， 标签本身不会变得无效，其含义也不会彻底 改变。 只有当子标签能为标签增加有用的区分 信息时，才应该使用它。多余的子标签会干扰 语言标签的含义、理解和处理。 特别是，用户和实现应该遵循注册表中的 'Prefix' 和 'Suppress-Script' 字段（定义于第 3.1 节）： 这些字段为在语言标签中何时应该使用或避免 特定附加子标签提供指导。 用于构成语言标签的子标签选择应该遵循以下 指导原则： 1. 使用尽可能精确的标签，但不要比实际依据 支持的程度更加具体。避免使用对于 区分应用程序中的内容并不重要的子标签。 * 例如，'de' 可能足以标记一封用德语撰写的 电子邮件，而 "de-CH-1996" 对于这种任务而言可能 过于精确。 * 请注意，某些子标签序列可能并不表示 普通用户所预期的语言。例如，瑞士 德语（Schweizerdeutsch）由 "gsw-CH" 表示，而不是 "de-CH"。后一个标签表示在瑞士（'CH'） 使用的德语（'de'），也称为瑞士标准德语 （Schweizer Hochdeutsch）。两者都是真实的语言， 对某个应用程序而言，区分它们可能非常重要。 2. 除非文字能为标签增加一些区分信息， 否则不应该使用文字子标签构成语言标签。 文字子标签首次在 [RFC4646] 中正式定义。对于 [RFC1766] 或 [RFC3066]（它们已被 本文档废止）的实现，使用文字子标签可能会影响 匹配和子标签标识，因为这些子标签位于 主语言子标签和地区子标签之间。某些应用程序可以 从语言标签中使用文字子标签获益，只要在 给定上下文中使用保持一致。文字子标签永远 不适用于非书面内容（例如音频录音）。 注册表中主语言或扩展语言记录里的 'Suppress-Script' 字段指示对于大多数应用程序不会增加 区分信息的文字子标签；该字段 Phillips & Davis 最佳当前实践 [第 54 页]
RFC 5646 语言标签 2009 年 9 月 定义了用户何时不应该在特定主语言子标签中 包含文字子标签。 例如，如果某个实现使用基本 过滤 [RFC4647]（最初见于[RFC2616] 的第 14.4 节） 选择内容，而用户请求的语言范围为 "en-US"， 那么标记为 "en-Latn-US" 的内容不会匹配该请求，因此 不会被选中。因此，了解文字 子标签通常何时会被使用以及何时不应使用非常重要。 例如： * 子标签 'Latn' 不应该与主语言 'en' 一起使用，因为几乎所有英语文档都使用 拉丁文字书写，因此它不会增加任何区分信息。 但是，如果某个文档使用英语书写，同时混合拉丁 文字与另一种文字，例如盲文（'Brai'），那么 为帮助进行内容选择（例如应用某个样式 表），选择同时指示这两种文字可能是适当的。 * 在标记非书面内容（例如人类 语音录音）时，不应该使用文字子标签，即使 该语言通常使用多种文字书写。 因此，电影字幕可以使用标签 "uz-Arab" （乌兹别克语、阿拉伯文字），但同一 语言的音轨只需标记为 "uz"。（当内容非书面时， 也可以使用标签 "uz-Zxxx"，因为子标签 'Zxxx' 表示“非书面文档代码”。） 3. 如果某个标签或子标签在其注册表 条目中具有 'Preferred-Value' 字段，那么在构成 语言标签时，应该优先使用该字段的值，而不是 出现该首选值的标签或子标签。 * 例如，对于逻辑语，优先使用 'jbo'， 而不是祖父条款标签 "art-lojban"。 4. 优先使用表示单独语言的子标签或子标签序列， 而不是表示语言集合的子标签。“语言 集合”是一组源自共同祖先、在同一地理区域使用、 或以其他方式相关联的语言。 某些语言集合由 [ISO639-5] 分配 代码（其中一些 [ISO639-5] 代码在 [ISO639-2] 中也被 定义为集合）。这些代码作为主语言子标签包含 在注册表中。注册表中表示 语言集合的子标签具有值为 'collection' 的 'Scope' 字段。语言集合的子标签 Phillips & Davis 最佳当前实践 [第 55 页]
RFC 5646 语言标签 2009 年 9 月 始终优先于 'mul' 和 'und'（见下文）等更不具体的替代值，并且在没有 更具体的语言信息时，可以使用表示语言 集合的子标签。但是，大多数用户和实现 并不知道该集合与其各个 语言之间存在关系。此外，集合中各个 语言之间的关系定义并不明确； 特别是，这些语言通常无法相互理解。 由于子标签不同，对集合的请求 通常只会产生使用该集合子标签标记的项目，而不会产生 使用集合中各个语言 子标签标记的项目。 * 例如，集合采用包含式解释，因此 子标签 'gem'（日耳曼语族）可以用于、但不应该 用于那些更适合标记为 "en" （英语）、"de"（德语）或 "gsw"（瑞士德语、阿勒曼尼语）的内容。 虽然 'gem' 包含所有这些（以及其他）语言，但大多数 实现不会将 'gem' 与各个 语言匹配；因此，使用该子标签不会产生期望的 结果。 5. [ISO639-2] 定义了若干包含在子标签 注册表中的代码，在选择语言 标签时需要额外注意。在这些情况中的大多数情况下，如果允许 省略语言标签，那么省略它比使用这些代码更可取。 除非附加信息能为 应用程序提供某种价值，否则语言标签不应该将这些子标签作为前缀。 * 'mul'（Multiple）主语言子标签用于标识 包含多种语言的内容。当可以使用语言列表 或为每个内容元素使用单独标签时， 不应该使用此子标签。例如，'Content- Language' 标头 [RFC3282] 允许使用 语言列表，而不仅仅是单个语言标签。 * 'und'（Undetermined）主语言子标签用于标识 语言尚未确定的语言内容。除非 必须提供语言标签，而语言信息不可用或无法 确定，否则不应该使用此 子标签。在允许的情况下，优先省略语言标签。 'und' 子标签对于 要求必须提供语言标签的协议，或者要求主 语言子标签的情况（例如 "und-Latn"）可能有用。 在某些情况下进行语言标签匹配时， 'und' 子标签也可能有用。 Phillips & Davis 最佳当前实践 [第 56 页]
RFC 5646 语言标签 2009 年 9 月 * 'zxx'（Non-Linguistic, Not Applicable）主语言 子标签用于标识不适合或不适用 语言分类的内容。一些示例可能 包括器乐或电子音乐；由非语言声音组成的 录音；没有旁白、对话、印刷标题或字幕的 视听材料；由机器语言或 字符代码组成的机器可读数据文件；或者程序 源代码。 * 'mis'（Uncoded）主语言子标签用于标识 已知其语言、但当前没有 对应子标签的内容。不应该使用此子标签。 因为未来添加其他代码可能使 它的应用变得无效，所以它本质上不稳定，因此 与 BCP 47 的稳定性目标不兼容。始终 优先使用其他子标签：'und' 或（经事先 约定）私用子标签。 6. 谨慎使用变体子标签，并按正确顺序排列。大多数 变体子标签在注册表中具有一个或多个 'Prefix' 字段， 用于表示它们适用的子标签列表。 变体应该只与出现在其中一个 'Prefix' 字段中的子标签一起使用。如果某个变体在 其一个 'Prefix' 字段中列出了第二个变体，则在任何同时 出现这两个变体的语言标签中，第一个变体应该直接 出现在第二个变体之后。通用变体（完全没有 'Prefix' 字段的变体）应该出现在任何其他变体子标签之后。 对其余变体排序时，应将最重要的子标签放在最前面。 如果没有哪个子标签更重要，或者无法确定其关系， 则按字母顺序排列子标签。由于变体 高度专业化，同时使用许多变体通常会使 标签范围过于狭窄，从而抵消增加的精确度。 以其他顺序排列子标签会妨碍 互操作性以及标签的整体 解释。 例如： * 标签 "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"（Default Language）最初 根据 [RFC1766] 注册，以满足 [RFC2277] 的需要。它并不用于指示特定语言，而是 用于标识无法确定用户 语言偏好时所使用的条件或内容。除非是用于 标记要求默认语言内容必须使用该特定标签 标记的应用程序或协议中的默认 内容，否则不应该使用它。 应用程序或协议也可以使用它来标识何时 返回的是默认语言内容。 4.1.1. 标记涵盖语言 注册表中的某些主语言记录具有 'Macrolanguage' 字段（第 3.1.10 节），其中包含从每种“涵盖 语言”到其宏语言的映射。'Macrolanguage' 映射并不 定义涵盖语言与其宏语言之间是什么 关系，也不定义由同一 宏语言涵盖的语言彼此之间如何关联。由同一宏语言涵盖的 两种不同语言之间的差异，可能比 法语和西班牙语之间的差异还大。 少数特定宏语言，例如汉语（'zh'）和阿拉伯语 （'ar'），采用不同的处理方式。参见第 4.1.2 节。 应该使用更具体的涵盖语言子标签来构成 语言标签，不过既可以使用宏语言的主 语言子标签，也可以使用涵盖语言的子标签。 这意味着，例如，应使用 'crk' 而不是 'cr'（Cree）来标记 Plains Cree，依此类推。 按照定义，每个宏语言子标签的范围都包含其所有 涵盖语言。由于涵盖语言之间的关系各不相同， 用户不能假定宏语言子标签意味着 某个特定涵盖语言，也不能假定任何给定的两个 涵盖语言能够相互理解或以其他方式 互换。 应用程序可以使用宏语言信息来改善匹配或 语言协商。例如，'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 每个涵盖语言的子标签都应该用作主 语言子标签。例如，官话文档 应优先标记为 "cmn"（官话子标签），而不是 "zh"（汉语）。 o 如果希望或需要兼容性，则可以将涵盖语言子标签 用作扩展语言子标签。例如，官话 文档可以标记为 "zh-cmn"，而不是 "cmn" 或 "zh"。 o 仍然可以使用宏语言或作为前缀的子标签来构成 标签，而不是使用更具体的涵盖语言子标签。 也就是说，"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' 子标签表示 名为“美国手语”的语言）。 Phillips & Davis 最佳当前实践 [第 60 页]
RFC 5646 语言标签 2009 年 9 月 4.2. 语言标签的含义 语言标签的含义与其所包含 子标签的含义相关。反过来，每个子标签都隐含了人们对 相关内容可能具有的一定范围的预期，不过这 并不是保证。例如，使用诸如 'Arab'（阿拉伯文字）这样的文字子标签，并不意味着内容仅包含 阿拉伯字符。它确实意味着所涉及的语言 主要使用阿拉伯文字。因此，一个语言标签及其 子标签可以涵盖非常广泛的变体，同时仍然 适用于每个特定实例。 标签的有效性并不是决定其有用性的唯一因素。 尽管每个有效标签都有含义，但它可能并不代表任何真实 世界中的语言用法。在一个允许 子标签自由组合的系统中，这是无法避免的。例如，诸如 "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（通用区域设置数据存储库）（参见 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. 使用有限的缓冲区大小 某些应用程序和协议被迫分配固定的缓冲区 大小，或者以其他方式限制语言标签的长度。符合要求的 实现或规范可以拒绝支持存储 超过指定长度的语言标签。任何此类限制 都应该明确记录，并且此类文档应该包括 对较长标签的处理方式（例如，是生成错误值 还是截断语言标签）。如果协议允许 在任意限制处截断标签，却不提供关于 该限制是什么的任何说明，则可能通过 显著改变标签含义而造成损害。 实际上，大多数语言标签不需要超过少量 子标签，也不会接近合理大小的缓冲区限制； 参见第 4.1 节。 某些规范或协议限制标签长度，但没有 固定长度限制。例如，[RFC2231] 没有 明确的长度限制：语言标签可用的长度 受到其他标头组成部分长度（例如 字符集名称）以及 [RFC2047] 中 76 字符限制的共同约束。 因此，“限制”可能为 50 个或更多字符，但也 可能非常小。 分配缓冲区限制时的考虑事项如下： 除非是有意改变标签的 含义，或者标签无法放入协议为 存储或传输指定的有限缓冲区大小，否则实现不应该截断语言标签。 当标签被截断时，实现应该警告用户，因为 截断会改变标签的语义含义。 对空间有限但没有固定限制的协议或规范， 实现应该优先使用尽可能长的标签， 而不是截断。 为语言标签规定有限缓冲区大小的 协议或规范必须允许至少 35 个字符的语言标签。请注意，[RFC4646] 建议最小字段大小 为 42 个字符，因为它包含 'extlang' 产生式的所有三个 元素。其中两个现在被永久保留， 因此最大长度为 8 个 字符的已注册主语言子标签现在比最长的 language-extlang 组合更长。通常使用 Phillips & Davis 最佳当前实践 [第 64 页]
RFC 5646 语言标签 2009 年 9 月 扩展或私用子标签的协议或规范可能希望保留或 建议更长的“最小缓冲区”大小。 下图显示了 35 字符建议值是如何 得出的： language = 8 ; 允许的最长已注册值 ; 比 primary+extlang 更长 ; 后者需要 7 个字符 script = 5 ; 如果未被抑制：参见第 4.1 节 region = 4 ; UN M.49 数字地区代码 ; ISO 3166-1 代码需要 3 个字符 variant1 = 9 ; 需要 'language' 作为前缀 variant2 = 9 ; 非常少见，因为它需要 ; 'language-variant1' 作为前缀 total = 35 个字符 图 7：标签长度限制的推导 4.4.2. 语言标签的截断 截断语言标签会改变标签的含义，因此 应该避免。然而，由于缓冲区大小有限，有时 必须截断语言标签。此类截断不得 允许从中间截断子标签，也不得形成 无效标签（例如以 "-" 字符结尾的标签）。 这意味着截断标签的应用程序或协议必须通过 从语言标签右侧逐步删除子标签及其前面的 "-" 来进行截断，直到标签足够短，可以放入 给定缓冲区。如果所得标签以单 字符子标签结尾，则该子标签及其前面的 "-" 也必须 删除。例如： 要截断的标签：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. 语言标签的规范化 由于一个特定语言标签可能被许多进程使用， 语言标签应该始终以规范 形式创建或生成。 当标签按照第 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 子标签要么是国家名称或称谓 已发生更改的地区子标签，要么是 对 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' 又具有一条 'extlang' 记录，其 'Prefix' 为 'zh'（汉语）。extlang 形式为 "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' （缅甸）的规范映射。 语言标签的规范化并不意味着在处理或比较 子标签时应使用大写或小写字母 （如第 2.1 节所述）。所有比较都必须 以不区分大小写的方式执行。 在对语言标签执行规范化时，处理器可以 统一子标签的大小写（即，此过程是 可选的），遵循注册表中使用的大小写形式（参见 第 2.1.1 节）。 Phillips & Davis 最佳当前实践 [第 67 页]
RFC 5646 语言标签 2009 年 9 月 如果一个标签中出现多个变体，处理器可以重新排列 这些变体，以获得更好的匹配行为或更一致的 呈现。变体的重新排序应该遵循 第 4.1 节中关于变体顺序的建议。 如果注册表记录中出现 'Deprecated' 字段，但没有 随附的 'Preferred-Value' 字段，则该标签或子标签是 没有替代值的已弃用项。这些值在 出现在语言标签中时是规范的。但是，包含这些 值的标签不应该由用户选择，也不应该由 实现生成。 扩展必须定义该扩展中各个 子标签之间存在的任何关系，因此可以为扩展子标签 定义替代的规范化方案。扩展可以 定义如何解释扩展子标签的顺序。例如， 某个扩展可以定义，当其子标签按 ASCII 顺序排列时 处于规范顺序：即使用 "en-a- aaa-bbb-ccc" 而不是 "en-a-ccc-bbb-aaa"。另一个扩展可能 定义子标签的顺序会影响其语义 含义（因此 "en-b-ccc-bbb-aaa" 与 "en-b- aaa-bbb-ccc" 具有不同的值）。但是，扩展规范应该设计为 能够容忍 第 3.7 节所述的典型处理过程。 4.6. 私用子标签方面的考虑 私用子标签与所有其他子标签一样，必须符合 ABNF 中的格式和内容约束。私用子标签在 打算使用或交换采用这些子标签的语言标签的各方之间的 私下约定之外没有任何含义。同样的 子标签可以在另一项单独的私下 约定下具有不同含义。当存在替代方案时， 不应该使用它们，也不应该在面向一般用途的内容或协议中使用它们。 如果没有事先约定，私用子标签对于信息交换而言 根本没有用处。私用标签以及此类语言标签中使用的 子标签的值和语义含义 不由本文档定义。 由 'x' singleton 引入的私用序列对于 私用协议之外的用户或实现而言完全 不透明。因此，除了由 singleton 子标签 'x' 引入的 私用子标签序列之外，语言子标签注册表还提供 源自底层标准所分配私用代码的私用语言、文字和地区子标签。 这些子标签可有效用于构成语言标签；与 'x' singleton 私用子标签序列相比，更建议使用这些子标签 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 插入或替换完整记录。这些记录由 语言子标签审查员按照 第 3.3 节所述预先为 IANA 格式化。 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' 记录都会更新，以反映最近一次 修改日期。日期格式必须采用 [RFC3339] 的 "full- date" 格式。日期必须是该版本注册表 首次由 IANA 发布的日期。每天最多只能 发布一个注册表版本。每个向 IANA 发出的插入或 修改记录请求中也包含 'File- Date' 记录，用于指示请求中记录的接受日期。 更新后的注册表文件必须使用 UTF-8 字符编码，并且 IANA 必须检查注册表文件的编码是否正确。非 ASCII 字符可以通过将注册表单作为附件发送给 IANA， 或在邮件正文中使用各种编码 （建议使用 UTF-8）来发送。IANA 会在发布 更新后的注册表之前，与语言子标签审查员核实任何不清楚或 损坏的字符。 IANA 还会存档每份注册表单，并通过 http://www.iana.org 公开提供。请注意，多次 注册可能涉及注册表中的同一条记录。 依赖语言子标签注册表的开发者 有时希望获知注册表中的更改，以便 更新其实现。当语言子标签注册表发生任何更改时， IANA 会向 <ietf-languages-announcements@iana.org>（一个可自行 订阅、但只有 IANA 能发布消息的列表）发送公告 消息。 Phillips & Davis 最佳当前实践 [第 70 页]
RFC 5646 语言标签 2009 年 9 月 5.2. 扩展注册表 语言标签扩展注册表最多可以包含 35 条记录， 因此预计该注册表的更改会非常少见。 IANA 今后对语言标签扩展注册表的工作 仅限两种情况。第一，IESG 可以不时请求 向该注册表插入新记录。这些请求 必须包含要插入的记录，其格式必须与 第 3.7 节所述完全一致。此外，特定扩展的 维护机构也可能偶尔请求更新记录中的联系 信息或 URL。这些请求必须包含 完整的更新记录。IANA 不负责验证所提供的 信息，只负责验证其格式是否正确。IANA 应该采取合理步骤确认请求确实来自 注册表中现有记录所指明的维护机构。 6. 安全注意事项 在内容协商中使用的语言标签，与互联网上交换的任何其他信息 一样，可能引起担忧，因为它们 可能用于推断发送者的国籍，从而 识别潜在的监控目标。 这是“任何被发送的信息 对接收方可见，并且可能也对第三方可见”这一一般问题的特殊情况。 了解在某些情况下可能存在此类担忧 是有益的。 对威胁确切程度以及任何可能 对策的评估，留给各个应用协议处理（有关安全威胁和 防御的最佳当前实践指南，参见 BCP 72 [RFC3552]）。 与特定信息项关联的语言标签对于判断该内容是否 可能包含同形异义字符完全没有任何影响。文本被标记为某种 语言或使用某个特定文字子标签这一事实， 完全不能保证其中不包含与该语言标签 关联或指定的文字之外的其他文字中的字符。 由于变体、私用和 扩展子标签的数量没有限制，因此标签的可能长度也没有限制， 实现需要防范缓冲区溢出 攻击。有关语言标签截断的详细信息，请参见第 4.4 节， 截断可能是防御缓冲区溢出的结果。 Phillips & Davis 最佳当前实践 [第 71 页]
RFC 5646 语言标签 2009 年 9 月 为防止拒绝服务攻击，应用程序不应该依赖 语言子标签注册表或语言标签扩展 注册表始终可以访问。此外，尽管 扩展有效子标签的规范（参见第 3.7 节） 必须可以通过互联网获取，实现不应该 机械地依赖这些来源始终可访问。 本文档规定的注册表不适合 频繁或实时访问或检索完整注册表 内容。大多数应用程序根本不需要注册表数据。对于 其他应用程序，能够根据某个特定注册表日期 验证或规范化语言标签就足够了，因为注册表内容 只偶尔发生更改。更改会通过 <ietf-languages-announcements@iana.org> 公布。此邮件列表 面向感兴趣的组织和个人，而不是用于批量 订阅以触发软件自动更新。注册表的大小 使其不适合软件自动更新。 考虑将语言子标签注册表集成进 自动更新方案的实现者，被强烈建议只分发 经过适当编码的差异，并且仅通过自己的基础设施 分发——不要直接从 IANA 获取。 是否发生更改也可以通过 查看注册表开头的 'File-Date' 记录， 或使用下载所用协议的功能轻松检测， 而无需下载完整注册表。在本文档 发布时，IANA 通过 HTTP 1.1 提供语言标签注册表。 使用 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。现在列出了不规则 标签。格式良好的祖父条款标签现在由 'langtag' 产生式描述，因此删除了 'grandfathered' 产生式。此外：在第 2.2.8 节中增加了 对两种祖父条款标签的说明。 o 向第 4.1 节添加了关于“集合”的段落。 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 节中的示例 "fr-Latn-CA" 替换为 "sr-Latn-RS" 和 "az-Arab-IR"，因为 "fr-Latn-CA" 没有遵守 'fr' 对 'Latn' 的 'Suppress-Script'。 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 节中的文本，加入此前仅为经验性说法的 标签选择指导原则，并澄清在非书面 应用中不使用文字子标签。 o 禁止在一个标签中多次使用同一个变体（即 "de- 1901-1901"）。此前，这只是一项建议 （"SHOULD"）。 o 删除了第 4.4.1 节图示中不恰当的 [RFC2119] 规范性用语。 o 将第 4.5 节中弃用 "zh-guoyu" 的示例替换为 "zh- hakka"->"hak"，并说明这一更改是由本文档 引起的。 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' 之外的“例外 保留”ISO 3166-1 代码都包含在 注册表中。特别是，这允许使用代码 'EU'（欧洲 联盟）构成语言标签，或者更常见地用于 使用该注册表作为地区代码来源的应用程序引用 此子标签。 o 修改了 IANA 注意事项章节（第 5 节），删除 不必要的规范性 [RFC2119] 用语。 9. 参考文献 9.1. 规范性参考文献 [ISO15924] 国际标准化组织，"ISO 15924:2004。信息与文献 -- 文字名称 表示代码"， 2004 年 1 月。 [ISO3166-1] 国际标准化组织，"ISO 3166-1:2006。国家及其下属地区名称 表示代码 -- 第 1 部分： 国家代码"，2006 年 11 月。 [ISO639-1] 国际标准化组织，"ISO 639-1:2002。语言名称表示 代码 -- 第 1 部分：Alpha-2 代码"，2002 年 7 月。 [ISO639-2] 国际标准化组织，"ISO 639-2:1998。语言名称表示 代码 -- 第 2 部分：Alpha-3 代码"，1998 年 10 月。 [ISO639-3] 国际标准化组织，"ISO 639-3:2007。语言名称表示代码 - 第 3 部分：全面覆盖语言的 Alpha-3 代码"，2007 年 2 月。 Phillips & Davis 最佳当前实践 [第 76 页]
RFC 5646 语言标签 2009 年 9 月 [ISO639-5] 国际标准化组织，"ISO 639-5:2008。语言名称表示代码 -- 第 5 部分：语系和语言组的 Alpha-3 代码"，2008 年 5 月。 [ISO646] 国际标准化组织， "ISO/IEC 646:1991，信息技术 -- ISO 7 位编码字符集，用于信息 交换。"，1991 年。 [RFC2026] Bradner, S.，"互联网标准流程 -- 修订版 3"，BCP 9，RFC 2026，1996 年 10 月。 [RFC2119] Bradner, S.，"用于 RFC 中表示 要求级别的关键词"，BCP 14，RFC 2119，1997 年 3 月。 [RFC2277] Alvestrand, H.，"IETF 字符集和 语言策略"，BCP 18，RFC 2277，1998 年 1 月。 [RFC3339] Klyne, G., Ed. 和 C. Newman，"互联网上的日期和时间： 时间戳"，RFC 3339，2002 年 7 月。 [RFC4647] Phillips, A. 和 M. Davis，"语言 标签匹配"，BCP 47，RFC 4647，2006 年 9 月。 [RFC5226] Narten, T. 和 H. Alvestrand，"RFC 中 IANA 注意事项章节的编写指南"， BCP 26，RFC 5226，2008 年 5 月。 [RFC5234] Crocker, D. 和 P. Overell，"用于 语法规范的扩充 BNF：ABNF"，STD 68，RFC 5234， 2008 年 1 月。 [SpecialCasing] Unicode 联盟，"Unicode 字符数据库， 特殊大小写属性"，2008 年 3 月，<http:// unicode.org/Public/UNIDATA/SpecialCasing.txt>。 [UAX14] Freitag, A.，"Unicode 标准附录 #14：换行 属性"，2006 年 8 月， <http://www.unicode.org/reports/tr14/>。 [UN_M.49] 联合国统计司，"用于统计用途的 国家或地区标准代码"，修订版 4（联合国出版物，销售编号 98.XVII.9， 1999 年 6 月）。 Phillips & Davis 最佳当前实践 [第 77 页]
RFC 5646 语言标签 2009 年 9 月 [Unicode] Unicode 联盟，"Unicode 联盟。《Unicode 标准》，第 5.0 版，（Boston, MA, Addison- Wesley, 2003. ISBN 0-321-49081-0）"，2007 年 1 月。 9.2. 资料性参考文献 [CLDR] "通用区域设置数据存储库项目"， <http://cldr.unicode.org>。 [RFC1766] Alvestrand, H.，"用于标识 语言的标签"，RFC 1766，1995 年 3 月。 [RFC2028] Hovey, R. 和 S. Bradner，"参与 IETF 标准流程的组织"，BCP 11， RFC 2028，1996 年 10 月。 [RFC2046] Freed, N. 和 N. Borenstein，"多用途互联网 邮件扩展（MIME）第二部分：媒体类型"， RFC 2046，1996 年 11 月。 [RFC2047] Moore, K.，"MIME（多用途互联网邮件 扩展）第三部分：非 ASCII 文本的消息标头扩展"， RFC 2047，1996 年 11 月。 [RFC2231] Freed, N. 和 K. Moore，"MIME 参数值和 编码词扩展： 字符集、语言和连续行"， RFC 2231，1997 年 11 月。 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., 和 T. Berners-Lee， "超文本传输协议 -- HTTP/1.1"，RFC 2616， 1999 年 6 月。 [RFC2781] Hoffman, P. 和 F. Yergeau，"UTF-16，一种 ISO 10646 编码"，RFC 2781，2000 年 2 月。 [RFC3066] Alvestrand, H.，"用于标识 语言的标签"，RFC 3066，2001 年 1 月。 [RFC3282] Alvestrand, H.，"内容语言标头"， RFC 3282，2002 年 5 月。 [RFC3552] Rescorla, E. 和 B. Korver，"RFC 安全注意事项 文本编写指南"，BCP 72， RFC 3552，2003 年 7 月。 Phillips & Davis 最佳当前实践 [第 78 页]
RFC 5646 语言标签 2009 年 9 月 [RFC3629] Yergeau, F.，"UTF-8，ISO 10646 的一种转换格式"，STD 63，RFC 3629，2003 年 11 月。 [RFC4645] Ewell, D.，"初始语言子标签注册表"， RFC 4645，2006 年 9 月。 [RFC4646] Phillips, A. 和 M. Davis，"用于标识 语言的标签"，BCP 47，RFC 4646，2006 年 9 月。 [RFC5645] Ewell, D., Ed.，"语言子标签 注册表更新"，2009 年 9 月。 [UTS35] Davis, M.，"Unicode 技术标准 #35：区域设置 数据标记语言（LDML）"，2007 年 12 月， <http://www.unicode.org/reports/tr35/>。 [iso639.prin] ISO 639 联合咨询委员会，"ISO 639 联合 咨询委员会：ISO 639 维护工作原则"，2000 年 3 月，<http://www.loc.gov/ standards/iso639-2/iso639jac_n3r.html>。 [record-jar] Raymond, E.，"Unix 编程艺术"，2003 年， <urn:isbn:0-13-142901-9>。 Phillips & Davis 最佳当前实践 [第 79 页]
RFC 5646 语言标签 2009 年 9 月 附录 A. 语言标签示例（资料性） 简单语言子标签： de（德语） fr（法语） ja（日语） i-enochian（祖父条款标签示例） 语言子标签加文字子标签： zh-Hant（使用繁体中文文字书写的汉语） zh-Hans（使用简体中文文字书写的汉语） sr-Cyrl（使用西里尔文字书写的塞尔维亚语） sr-Latn（使用拉丁文字书写的塞尔维亚语） 扩展语言子标签及其对应的主语言子标签： zh-cmn-Hans-CN（汉语、官话、简体文字、在 中国使用） cmn-Hans-CN（官话、简体文字、在 中国使用） zh-yue-HK（汉语、粤语、在香港特别行政区使用） yue-HK（粤语、在香港特别行政区使用） 语言-文字-地区： zh-Hans-CN（使用简体文字书写、在 中国大陆使用的汉语） sr-Latn-RS（使用拉丁文字书写、在 塞尔维亚使用的塞尔维亚语） Phillips & Davis 最佳当前实践 [第 80 页]
RFC 5646 语言标签 2009 年 9 月 语言-变体： sl-rozaj（斯洛文尼亚语的 Resian 方言） sl-rozaj-biske（Resian 方言的 San Giorgio 方言， 属于斯洛文尼亚语） sl-nedis（斯洛文尼亚语的 Nadiza 方言） 语言-地区-变体： de-CH-1901（在瑞士使用、采用 1901 变体 [正字法] 的德语） sl-IT-nedis（在意大利使用的斯洛文尼亚语，Nadiza 方言） 语言-文字-地区-变体： hy-Latn-IT-arevela（使用拉丁文字书写、在 意大利使用的东亚美尼亚语） 语言-地区： de-DE（德国使用的德语） en-US（美国使用的英语） es-419（适用于拉丁美洲和加勒比 地区、使用联合国地区代码的西班牙语） 私用子标签： 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 月 使用扩展的标签（仅为示例 -- 扩展必须由 本文档的修订或更新，或者由 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. 注册表单示例 语言子标签注册表单 1. 请求者姓名：Han Steenwijk 2. 请求者电子邮件地址：han.steenwijk @ unipd.it 3. 请求的记录： Type: variant Subtag: biske Description: Resian 的 San Giorgio 方言 Description: Resian 的 Bila 方言 Prefix: sl-rozaj Comments: San Giorgio/Bila 方言是 Resian 四种主要地方方言之一 4. 子标签的预期含义： 在 San Giorgio/Bila 使用的 Resian 地方变体 5. 已发表的语言描述（书籍或 文章）的参考资料： -- Jan I.N. Baudouin de Courtenay - Opyt fonetiki rez'janskich govorov, Varsava - Peterburg: Vende - Kozancikov, 1875. Phillips & Davis 最佳当前实践 [第 82 页]
RFC 5646 语言标签 2009 年 9 月 语言子标签注册表单 1. 请求者姓名：Jaska Zedlik 2. 请求者电子邮件地址：jz53 @ zedlik.com 3. 请求的记录： Type: variant Subtag: tarask Description: 使用 Taraskievica 正字法的白俄罗斯语 Prefix: be Comments: 此子标签表示 Branislau Taraskievic 的白俄罗斯语 正字法，该正字法发表于 Juras Buslakou、Vincuk Viacorka、 Zmicier Sanko 和 Zmicier Sauka 所著 "Bielaruski klasycny pravapis"（Vilnia-Miensk 2005）。 4. 子标签的预期含义： 此子标签旨在表示 Juras Buslakou、Vincuk Viacorka、Zmicier Sanko 和 Zmicier Sauka 所著 "Bielaruski klasycny pravapis"（Vilnia-Miensk 2005）中公布的白俄罗斯语正字法。 5. 已发表的语言描述（书籍或 文章）的参考资料： 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. 任何其他相关信息： 使用 Taraskievica 正字法的白俄罗斯语已得到广泛使用，尤其是在 白俄罗斯语互联网领域，但除此之外，一些书籍 和报纸也使用这种白俄罗斯语正字法印刷。 附录 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, 以及其他许多人。 必须特别感谢 Harald Tveit Alvestrand，他 发起了 RFC 1766 和 3066；如果没有他，本文档 就不可能完成。 特别感谢 Michael Everson，他在几乎整个 RFC 1766/RFC 3066 时期担任语言标签 审查员，并且自 RFC 4646 采用以来一直担任语言子标签审查员。 还特别感谢 Doug Ewell，他制作了第一份 完整的子标签注册表，为支持和维护新的 注册所做的工作，以及对 RFC 4645 和 [RFC5645] 所做的细致编辑工作。 作者地址 Addison Phillips（编辑） Lab126 电子邮件：addison@inter-locale.com URI： http://www.inter-locale.com Mark Davis（编辑） Google 电子邮件：markdavis@google.com Phillips & Davis 最佳当前实践 [第 84 页]