万维网的语言标签和地区标识符

1. 介绍

语言标签和区域设置是 Web 国际化 （i18n）的一些基本构建块。在本文档中，你将找到 与国际化这一方面相关的大部分基本术语的定义。

本文档还提供规范作者在文档格式或协议中标识自然语言值时所需的术语和最佳实践， 这些内容由国际化（I18N）工作组推荐。这些（以及许多其他）最佳 实践及其支持材料的链接，也可以在规范开发者的国际化 最佳实践 [INTERNATIONAL-SPECS] 中找到。除了 此处列出的最佳实践外，与 Web 上语言元数据相关的其他最佳实践 可以在 [STRING-META] 中找到。

2. 语言与语言标签

用于标识内容的自然语言或用户的国际化偏好的标签，是 Web 的 基本构建块之一。Web 和 Internet 格式 及协议中使用的语言标签 由 [BCP47] 定义。一致地使用语言标签，使 应用程序能够执行特定于语言的格式化或处理。例如，用户代理 可以使用语言来选择适当的字体以显示文本，或者 Web 页面设计者可以针对 不同语言以不同方式设置文本样式。

Web 的许多核心标准都包括对语言标签的支持；其中包括 [XML10] 中的 xml:lang 属性、[HTML] 中的 lang 和 hreflang 属性、[XSL10] 中的 language 属性，以及 CSS [CSS3-SELECTORS] 中的 :lang 伪类，还有包括 SVG、TTML、SSML 等在内的许多其他标准。

自然语言（或者在本文档中简称为语言）。人类使用的 口头、书面或手语交流。

可以通过许多方式来标识语言，而软件可能出于许多原因需要标识 Web 上内容的语言。Web 上的文档格式和协议通常使用 Internet 大多数其他部分使用的标识符，即由 [BCP47] 定义的语言标签。“BCP” 命名法是指构成“当前最佳实践”的 当前 IETF RFC 集合。

语言 标签。用作语言标识符的字符串。在本文档中，术语语言 标签始终明确指 [BCP47] 语言标签。这些 语言标签由一个或多个子标签组成。

​需要进行语言标识的 Web 规范必须引用 [BCP47]。

​规范不应引用 [BCP47] 的特定组成 RFC。

[BCP47] 是一个多部分文档，在本文档发布时，由两个独立的 RFC 组成。第一部分称为用于标识 语言的标签 [RFC5646]，定义了语言标签的语法、形式和 术语。第二部分称为语言标签的匹配 [RFC4647]，描述了使用语言标签进行匹配、 比较和选择内容的若干方案，并包含与将语言偏好同带标签的内容进行比较 相关的实用术语。

​诸如 “RFC 5646 或其后继版本”之类的表述可以使用，但仅限于 必须指定特定文档版本的情况。

虽然这种引用方式曾经很流行，但使用 BCP 引用更加准确。由于语言标签的语法 自 [RFC4646] 起已经固定，因此引用 BCP 不会给大多数实现 带来额外的合规风险。

​规范不得引用 [BCP47] 的过时版本，例如 [RFC1766] 或 [RFC3066]。

​需要保持与 [BCP47] 过时版本兼容性的规范必须引用 [BCP47] 中的产生式 obs-language-tag。

从 [RFC4646] 开始，[BCP47] 为语言标签定义了一种更复杂、机器可读的语法。该语法是稳定的，并且预计 在可预见的未来不会发生变化。一些规范可能希望或要求与 BCP47 先前版本中较旧的语言标签语法兼容（特别是 [RFC1766] 和 [RFC3066]）。这种语法更加 宽松，并在 [BCP47] 中描述为 ABNF 产生式 obs-language-tag。[RFC4646] 引入了当前的语言标签语法， 后来被 [RFC5646] 取代，成为当前 [BCP47] 的一部分。

​将语言 信息作为 URI 一部分提供的应用程序（例如在 RDF 领域中）应使用 [BCP47]。

目前，表达语言信息的 URI 经常使用 ISO 639 各部分中的值。这会导致 无法确定正确值的歧义情况，例如对于德语， ISO 639-1 中使用 de，而 ISO 639-2 中使用 ger。通过使用 BCP 47 及其语言子标签 注册表，可以避免此类歧义，例如对于德语，该注册表中只包含 de。

子标签。由 ASCII 字母或数字组成的序列，通过连字符-减号字符与其他子标签分隔，并标识整个语言标签中特定的 语义元素。在 [BCP47] 中，子标签可以由 大写或小写 ASCII 字母（大小写不具有区分意义）或 ASCII 数字组成。子标签的长度限制为 不超过八个字符（但根据子标签的具体用途，还可能适用其他长度限制）。

基于语言标签选择内容或行为，需要使用由 [BCP47]（在 [RFC4647] 中）定义的若干附加概念。 在本文档中，我们采用以下直接取自 [BCP47] 的术语：

IANA 语言子标签注册表。一个可通过 IANA 获取的机器可读文本文件， 其中包含语言标签中所有有效子标签的完整列表。（链接： 注册表）

​规范不应引用 [BCP47] 中 构成IANA 语言子标签注册表的 底层标准，例如 ISO639、ISO15924、ISO3066 或 UN M.49。

一些标准可能会直接使用 [BCP47] 的某个贡献标准， 在这种情况下，引用它完全合适。但是，在大多数情况下，引用的目的是 指定有效代码及其含义的列表。[BCP47] 的子标签注册表已经稳定，并以多种有用的方式解决了 歧义，因此对于此类引用应优先采用该注册表。

[BCP47] 定义了两个不同级别的 一致性。具体信息请参阅 [BCP47] 中的一致性类别。 对于语言标签，一致性级别对应于实现对语言标签值应用的检查类型。

格式良好的语言标签。遵循 [BCP47] 所定义语法的语言标签。也就是说，它在结构上是正确的， 由规定长度的 ASCII 字母和数字子标签组成，并由连字符分隔。

有效的语言标签。一个格式良好并且还 符合 [BCP47] 中附加一致性 要求的语言标签，尤其要求每个子标签都出现在 IANA 语言子标签 注册表中。

​规范 应要求语言标签格式良好。

​规范可以要求语言标签是有效的。

​规范应要求内容作者使用有效的语言 标签。

请注意，这比针对实现所建议的要求更加严格。

​在可行的情况下，内容验证器 应检查内容是否使用了有效的语言标签。

检查标签是否有效需要访问注册表或其副本，以及额外的运行时逻辑。虽然 建议内容作者只选择、生成和交换有效值，但语言标签匹配和 其他常见语言标签操作的设计使其无需进行有效性检查。需要 理解子标签具体语义内容的特性或函数，是规范在协议或文档格式中 规范性要求使用有效标签的主要原因。

语言标签扩展或 扩展。由在 IANA 注册的单个字母或数字子标签引入的一套附加 [BCP47] 子标签体系，允许使用额外类型的语言 标识。

​规范可以根据需要引用 [BCP47] 的已注册扩展。

特别是，[RFC6067] 定义了 BCP 47 扩展 U，也 称为“Unicode 区域设置”。[BCP47] 的这一扩展提供了额外的 子标签序列，用于选择特定的区域设置变体。

​规范 不应限制语言标签的长度，也不应允许或鼓励删除 扩展。

语言范围。一种结构类似于语言标签的字符串，用于 “标识共享特定属性的语言标签集合”。

语言 优先级列表。由一个或多个语言范围组成的集合，用于标识用户在 匹配时使用的语言偏好。顾名思义，这类列表通常会根据用户偏好进行排序或加权。 HTTP [RFC2616] Accept-Language [RFC3282] 标头就是一种语言 优先级列表的示例。

基本语言范围。一种语言范围，由 以连字符分隔的子标签序列组成。也就是说，它在外观上与语言标签完全相同。

扩展语言范围。一种语言范围，由以连字符分隔的 子标签序列组成。在扩展语言范围中，子标签可以是有效子标签，也可以是通配符子标签 *，后者可匹配任意值。

某些语言优先级列表，例如前面提到的 Accept-Language [RFC3282] 标头，会为 列表中出现的值提供“权重”。除了用于对 列表排序外，不应依赖这种加权。

​定义 语言标签匹配或语言协商的规范必须指定所使用的语言范围是基本语言 范围还是扩展语言范围。

​定义语言标签匹配的规范必须指定 匹配操作的结果是包含单个结果（[RFC4647] 中定义的查找），还是一个可能为空（零个或多个）的 结果集合（[RFC4647] 中定义的过滤）。

​定义语言标签匹配的规范必须指定 可用的匹配算法和选择机制。

例如，JavaScript 国际化 [ECMA-402] 和 [CLDR] 提供了一种可以由 实现者定制的“最佳匹配”算法。

3. 地区设置与国际化

本节定义与国际化和本地化相关的基本术语。

使用不同语言或来自不同文化背景的用户通常需要经过适配的软件和 服务，以便使用其母语、书写系统、 度量系统、日历以及其他语言规则和文化惯例正确处理信息。

语言 标签还可用于标识与给定内容或用户相关联的国际化偏好，因为这些偏好与最终用户的自然语言、地区 归属或文化相关。这类偏好会应用于诸如呈现 数字、日期或时间；按语言规则对列表排序；为日历的 显示方式或常用度量单位等项目提供默认值；选择 12 小时制还是 24 小时制 时间显示；以及许多用户可能觉得逐项设置过于繁琐的其他细节。总体而言，这些 偏好的标识符通常称为区域设置。[BCP47] 中 定义 Unicode 区域设置的扩展 [CLDR] 为 Web 上的国际化 API 提供了基础，尤其是 JavaScript 语言 [ECMASCRIPT] 使用Unicode 区域设置作为 [ECMA-402] 中 API 的基础。

国际化偏好。 用户的一组特定 语言和格式化偏好以及相关的文化惯例。软件可以使用这些偏好 正确处理或呈现与该用户交换的信息。

为了使内容或服务能够被世界各地的用户认为可用 并可接受，Web 上可能会提供许多种国际化偏好。 其中一些偏好 可能包括：

• 用于文本处理（例如解析、拼写检查和 语法检查）的自然语言；
• 用户界面语言，其中除了可见文本字符串外，还可能包括图像、 颜色、声音、格式和导航元素等项目；
• 日期、时间、数字、 列表和其他值的呈现（面向人的格式化）；
• 内容的校对、排序和组织（例如在 电话簿或词典中）；
• 其他计时方式和日历，其中可能包括节假日、 工作规则、工作日/周末的区分、月份的数量及 组织方式、年份的编号方式等等；
• 税收或监管制度；
• 货币

国际化。 对产品进行设计和开发，使其能够面向文化、地区 或语言各不相同的目标受众。国际化有时缩写为 i18n，因为其英文单词中的 “I”和“N”之间有十八个字母。

本地化。根据特定目标市场或群体中个人的文化 期望对系统进行适配。本地化包括但不限于 翻译面向用户的文本和消息。本地化有时缩写为 l10n，因为其英文单词中的“L”和“N”之间有十个字母。当与 一组特定国际化偏好相对应的一组特定内容和偏好 在实际运行中可用时，就称该系统已被本地化。

区域设置。一组国际化 偏好的标识符（例如语言标签）。通常，该标识符表示用户偏好的语言，并且可能 包含其他信息，例如地理区域（例如国家）。区域设置会传递给 API 或 设置在运行环境中，以获得系统或进程中受文化影响的行为。

区域设置感知（或已启用）。能够以 特定于文化和语言的行为或内容响应区域设置 变化的系统。一般而言，经过国际化的系统可以 支持广泛的区域设置，以满足多种用户的国际化 偏好。

语言 标签可以使用子标签提供有关语言、文字、地区以及各种特别注册的 变体的信息。但有时某些国际化偏好并不直接 与这些信息中的任何一种相关。例如，许多文化都有不止一种内容项排序方式，因此 并非总能仅根据语言标签推断出适当的排序顺序。因此，使用德语的 用户可能希望在词典使用的排序顺序与电话簿使用的排序顺序之间进行选择。

从历史上看，区域设置与用户所使用的编程语言或运行环境相关联，并且 特定于它们。这些特定于应用程序的标识符通常可以从语言 标签推断出来或转换为语言标签。区域设置模型的一些示例包括 Java 的 java.util.Locale、POSIX（使用诸如 de_CH@utf8 之类的标识符）、Oracle 数据库（AMERICAN_AMERICA.AL32UTF8）或 Microsoft 的 LCID（使用诸如 0x0409 之类的数字代码）。其中若干 模型、ISO639 或 ISO3166 等底层标准以及早期语言标签（例如 [RFC1766]）之间的关系完全是有意设计的。 实现通常会（并且现在仍会）将现有协议中的语言标签（例如 HTTP 的 Accept-Language 标头）映射到专有或特定于平台的区域设置模型。

自采用当前的 [BCP47] 标识符语法以来，许多区域设置 模型已经直接采用 BCP47，或者提供了专有模型与语言标签之间的适配或映射。特别是，被称为 [CLDR] 的 开源区域设置数据存储库的开发和采用，促使语言标签被更广泛地普遍 用作区域设置标识符。

通用区域设置数据存储库（或 [CLDR]）。通用区域设置数据存储库 是 Unicode 联盟的一个项目，用于定义、收集和维护在系统或 运行环境中启用区域设置所需的数据集。CLDR 数据及其区域设置模型得到了广泛采用，尤其是在浏览器中。

Unicode 区域设置标识符或Unicode 区域设置。一种语言标签，它遵循 UTR#35 [LDML] 中定义的关于 子标签选择的附加规则和限制。任何有效的 Unicode 区域设置标识符也都是一个有效的 [BCP47] 语言标签，但少数有效的语言 标签并不是有效的 Unicode 区域设置标识符。

规范 Unicode 区域设置标识符。应用 [LDML] 中的Unicode 区域设置标识符规范化规则后得到的格式良好的语言标签（参见第 3 节）。此过程 会将任何有效的 [BCP47] 语言标签转换为有效的 Unicode 区域设置标识符。例如，已弃用的子标签或 不规则的祖父标签会替换为IANA 语言子标签注册表中的首选值。

[CLDR] 定义并维护两个与Unicode 区域设置标识符相关的语言标签扩展（[RFC6067] 和 [RFC6497]）。这些扩展允许语言标签表达一些超出语言或地区差异的国际化 偏好变化，或者在给定区域设置中存在多个选项或用户偏好时选择格式化 行为或内容。Unicode 区域设置标识符并不要求包含这些 扩展：只有在所标识的区域设置需要其中某个扩展所提供的额外定制时 才会使用它们。[CLDR] 还会在某些子标签用作区域设置标识符时对其作出特定解释。 详情参见 [LDML] 的第 3.2 节。

Unicode 区域设置语言标签扩展 [RFC6067] 使用 -u- 子标签，并提供 用于选择不同的基于区域设置的格式和行为的子标签。详情参见 [LDML] 的第 3.6 节。

转换后的内容语言标签扩展 [RFC6497] 使用 -t- 子标签，提供用于文本转换的子标签，例如在不同文字之间进行转写。 详情参见 [LDML] 的第 3.7 节。

Unicode 区域设置日益成为 Web 国际化的基础， 尤其是作为 JavaScript [ECMASCRIPT] 中 Intl 区域设置框架 [ECMA-402] 的一部分。

​内容作者应选择属于规范 Unicode 区域设置标识符的语言 标签。

[LDML] 第 3 节中的附加内容限制和规范化步骤，相较于直接使用 [BCP47]， 可提供更好的互操作性和一致性。

​实现应仅输出属于规范 Unicode 区域设置标识符的语言 标签，并且应使用生成规范标签的规则对其所使用的 语言标签进行规范化。

如上所述，[LDML] 第 3 节中的附加内容限制和规范化步骤，相较于直接使用 [BCP47]， 可提供更好的互操作性和一致性。此最佳实践不应被解释为实现需要支持、 生成、处理或理解 [CLDR] 的任一扩展。

​除非特定应用程序需要额外定制，否则内容作者不应在语言标签中包含语言标签扩展。

务必记住，每个Unicode 区域设置标识符也是一个格式良好的 [BCP47] 语言标签。Unicode 区域设置标识符并不要求使用 [CLDR] 的任一种语言标签 扩展。

非语言字段。数据结构中不用于 存储或交换自然语言文本数据的任何元素。其中包括非字符串数据类型，例如 布尔值、数字、日期等等。还包括字符串，例如程序或协议内部 标识符。本文档使用术语字段作为这一概念的简称。

文档格式或协议的规范通常定义各种数据值或数据结构的交换、处理或显示。 Web 主要依赖文本文件进行数据的序列化和 交换：即使原始字节通常也会使用诸如 base64 这样的字符串序列化方式传输。因此， Web 上的非语言字段通常也由 字符串组成。这里的重要区别在于，非语言字段通常 由底层应用程序解释或供其使用，而不是供用户使用。

区域设置中立。当一个非语言字段以一种 并非专门适用于任何给定语言、区域设置或文化，并且可以被无歧义地解释 从而以区域设置感知方式呈现的格式进行存储或交换时，就称其为区域设置中立。

许多规范使用序列化方案，例如 [XMLSCHEMA11-2] 或 [JSON-LD] 提供的方案，以便在文档格式或协议中对非语言字段进行区域设置中立编码。

区域设置中立表示本身可能与特定 文化偏好相关联，但应尽量减少这种关联。例如，许多 ISO8601 日期/时间值 序列化与公历相关联，但其格式、字段顺序、分隔符和视觉 外观并不特别适合任何区域设置（它们旨在供机器读取），并且如上面的示例所示， 该值可以转换为任何日历或区域设置中的显示形式。

语言协商。将用户的国际化偏好与可用区域设置、本地化 资源、内容或处理方式进行匹配的过程。

区域设置 回退。按照确定性模式，从更具体的资源向更通用的资源 “回退”，以搜索已翻译内容、区域设置数据或其他资源的过程。

用户的偏好通常表示为一个区域设置或按优先级排列的区域设置列表。在进行语言协商时， 系统会遵循某种算法，从可用 资源中获得最佳匹配的内容或功能。在许多情况下，语言协商算法使用区域设置回退。

​在文档格式中呈现字段的规范应 要求数据按照周围内容的语言进行格式化。

当非语言字段作为 文档或应用程序的一部分呈现给用户时，文档或应用程序构成查看数据的“上下文”。 内容作者或应用程序开发者需要一种方式，让字段看起来是 用户体验的自然组成部分，并且需要一种方式来控制其呈现。这由内容出现上下文的语言标签表示：通常， 已启用的实现会将该标签解释为区域设置以实现这一点。 只有在万不得已的情况下，才应使用用户代理的运行时区域设置或本地化设置作为呈现非语言字段的区域设置。

​在文档格式或应用程序中呈现表单或接收非语言字段输入的规范 应要求以紧邻该值的内容或标记所使用语言的格式，向用户呈现经过本地化的值。

​呈现、交换或允许输入 非语言字段的规范必须使用 区域设置中立格式进行存储和交换。

​实现应使用与周围内容语言一致的格式，在文档格式或应用程序中呈现 非语言字段， 并鼓励为输入或编辑提供已针对相同区域设置进行本地化的控件。

用户希望表单字段和其他数据输入对非语言 字段采用与这些值所在文档或应用程序一致的呈现方式。用户通常 希望其输入与文档上下文相匹配，而不是与用户代理或运行环境相匹配，因此 输入验证、提示或控件也应与内容保持一致。这使内容 作者能够创建完全本地化的用户体验，并且通常符合 用户的期望。

4. 延伸阅读

国际化工作组还有其它最佳实践与参考资料，例如语言标签选择的相关文章。包括：

• Web 上字符串：语言与书写方向元数据 [STRING-META]
• 如何选择语言标签
• HTML 与 XML 语言标签
• 如何对无语言文本加标签
• 本地化与国际化的区别

B. 致谢

国际化工作组对本规范以下贡献者表示感谢：

• Felix Sasaki，负责编辑本文件并发布了 2006 工作草案
• Mark Davis、Y.Umaoka 及其他成员 对 BCP47 扩展的贡献
• WS-I18N 贡献者：本文件编写以满足 [WS-I18N-REQ] 提出的需求 R005。