面向规范开发者的国际化最佳实践
关于本文档的更多详情
Copyright © 2014-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2014-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
本文档提供了在制定规范时与国际化相关的考虑事项清单。大多数清单项都指向其他文档中的详细支持信息。如果此类 信息尚不存在，可以暂时放在本文档中。随着新内容的加入以及根据 经验和讨论对现有内容进行修改，本文档中的信息将定期变化。
本节描述本文档在其发布时的状态。当前 W3C 出版物列表以及本技术报告的最新修订版可在 W3C 标准和草案 索引中找到。
本文档向规范开发者提供关于如何纳入国际化使用需求的建议。目前这里可用的内容预计可以立即发挥作用， 但仍然是早期草案，文档也处于变化之中，并将随着在审查和讨论中应用的知识被凝练为指南而逐步扩展。
本文档由国际化 工作组作为 小组备忘录，使用 备忘录轨道发布。
本小组备忘录得到 国际化工作组认可，但未得到 W3C 本身或其 成员认可。
W3C 专利 政策 不对本文档附带任何许可要求或承诺。
本文档受 2023年11月3日 W3C 流程文档约束。
规范开发者需要获得建议，以确保他们产出的内容能为全球各地的社区所使用。
国际化（i18n）工作组试图通过审查规范并参与 讨论来协助各工作组。然而，这类介入往往出现在流程中较晚的阶段，并不理想，或者意味着 i18n 工作组必须为其接触的每个工作组重复相同的信息。
如果规范开发者能够访问一份最佳实践清单，并在开发者需要时指向 解释、示例和理由，那会更好。开发者随后就能够从最早阶段把这些 知识纳入他们的工作，从而减少 i18n 工作组 审查其规范时所需的返工。
本文档包含清单的初步内容，并指向可找到 针对所提出建议的解释、示例和理由的位置。如果没有这样的其他地方， 这些额外信息将添加到本文档中。它也可用于发展想法并组织 这些想法。
本文档中的指南并不打算作为硬性要求。如果在你不理解这些指南或不同意它们时， 你联系国际化工作组讨论应该如何处理，那么本文档就已经实现了 其目的的重要部分。
在本文档中，术语 自然语言通常 用于指文档或协议中供人类使用的部分。术语 可本地化 文本用于指形式语言、协议语法和 类似内容中的自然语言内容，以区别于语法内容或用户提供的值。有关这些术语和 国际化工作组使用的其他术语的定义，请参见 [I18N-GLOSSARY]。
本页面提供了一项清单功能，用于帮助你审查规范的国际化情况。 审查结果应发布到 GitHub issue。
对你的规范相关的每一节，请遵循以下步骤：
对国际化考虑事项章节的所有添加或更改 MUST 由国际化（i18n）工作组审查。
如果你创建国际化考虑事项章节，它MUST 使用标题 Internationalization Considerations 或 Internationalization (i18n) Considerations。
规范并不要求包含专门章节或附录来描述其规范的国际化 考虑事项。一般而言，国际化工作组更倾向于将 有关语言、地域或文化差异、支持或适配的信息放在规范正文中， 并与相关功能紧密关联。
不过，在少数情况下，你可能会考虑提供这样的章节。请在以下情况下考虑 包含国际化考虑事项章节：
如果你决定创建 Internationalization Considerations 章节，通常会把它作为 附录。不过，相对于你的规范其他部分或其他附录的顺序和位置 由你决定。
如果你决定创建 Internationalization Considerations 章节，需要在向 国际化工作组提出横向审查请求时提及它。审查请求模板包含一个 复选框，可以让你轻松做到这一点。
这是本节中各项要求的列表，可用于自审。对于你的规范相关的所有要求， 选择所在行的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后点击“为 GitHub 创建 markdown”按钮，并将结果复制到 GitHub issue 列表中。请参见更多详情。
语言基础
lang 和 XML xml:lang
语言属性来识别文本处理语言，而不是创建
新属性或机制。更多lang 和
XML xml:lang 语言属性，而应在它们表示
元数据（即指示资源的预期用途，而不是特定文本范围的语言）时使用
不同的属性。更多定义语言值
声明语言
识别字符串的语言
zxx（“No
linguistic content”）与每个字符串值关联起来。更多und
（“Undetermined”）与每个字符串关联起来。规范MAY
还允许在适当情况下使用启发式方法或从其他字段值
推断语言。更多
U+E0000 到
U+E007F）进行语言识别。更多
@context 和内置的 @language 属性作为
文档层级默认值。更多
i18n
Namespace 功能。更多i18n Namespace 不可用或不适合使用的情况下，
规范SHOULD 要求 [JSON-LD]
针对自然语言值使用普通字符串字面量，以提供字符串特定的语言
信息。更多检测和匹配语言
文本会根据其所用语言以不同方式呈现或处理。例如，屏幕阅读器 需要在语言发生变化时收到提示，拼写检查器也应对语言敏感。在 呈现文本时，需要了解语言，以便应用正确的字体、断字、 换行、大小写转换以及其他功能。
例如，雪、刃、直、令、垔 等表意字符在使用日文字体与中文字体时存在细微但重要的差异， 因此重要的是不要将中文字体应用到日文文本上， 反之亦然，当文本呈现给用户时尤其如此。
给定资源的语言信息可以出于两个主要目标使用：用于 文本处理，或作为对资源预期用途的说明。我们将在下文解释 两者之间的区别。
在指定文本处理 语言时，你是在声明特定文本范围实际使用 的语言，以便操作文本的用户代理或应用程序，例如 语音浏览器、拼写检查器、样式处理器、断字器等，可以将适当的规则 应用于相关文本。因此，出于必要性，我们所讨论的是将单个 语言与特定文本范围关联起来。
通常会将文本处理语言表达为默认语言，用于处理整个 资源，但也可能需要指出资源内部语言发生变化的位置。
为识别一段文本的文本处理语言，HTML 提供了lang 属性，而 XML 提供了 xml:lang，它可以用于所有 XML 格式。继续在
相关标记格式中使用这些属性是有用的，因为作者能够识别它们，HTML 和 XML
处理器也能够识别它们。
描述整个资源的语言也可能很有用。这种类型的 语言声明称为资源的预期语言受众。例如，这类元数据可用于搜索、提供正确的 语言版本、分类等。
这种类型的语言声明与文本处理声明不同之处在于：(a) 这类声明的值可以包含多个语言子标签，且 (b) 所声明的语言值 并不指示多语言资源中哪些部分使用哪种语言。
应该能够将元数据类型的语言声明（它 指示资源的预期用途，而不是特定文本范围的语言） 与多个语言值关联起来。
描述资源预期用途的语言不一定包含文档中使用的每一种语言。 例如，Web 上的许多文档包含不同语言的嵌入内容片段， 而页面显然是面向某一特定语言的使用者。例如，面向德国读者的 北京城市指南可能包含有用的中文短语，但它面向的是 德语受众，而不是中文受众。
另一方面，也可以设想这样一种情况：文档包含同一内容或 并行内容的多种语言版本。例如，网页可以在左列用法语内容欢迎 加拿大读者，在右列用英语显示相同内容。此时文档同等面向两种语言的 使用者，因此有两种受众语言。另一个用例是面向多语言社区的博客或新闻页， 页面上的一些文章使用一种语言，另一些使用另一种语言。在这种情况下， 将多个语言标签列为语言声明的值可能是合理的。
表达外部资源语言的属性不应使用
HTML lang 和 XML xml:lang 语言属性，而在它们表示元数据
（即指示资源的预期用途，而不是特定文本范围的语言）时应使用不同的属性。
XML 文档模式中的 xml:lang – 我应该何时使用
xml:lang，何时应定义自己的元素或属性，以便在
XML 文档模式（DTD）中传递语言值？
使用不同属性来指示外部资源的语言，可以让该属性 指定多个语言。如果所指向的资源不是单一语言，它也能更好地工作。
这种区别可在 HTML 中看到，即 lang 与 hreflang 属性的分离。
前者指示 HTML 页面内文本的语言；后者是元数据，指示
所链接页面的预期语言。
关于此问题的更长讨论，请参见 XML 文档
模式中的 xml:lang。该文章专门讨论 xml:lang，但其中概念也适用于其他情况。
BCP 47 是 Internet 和 Web 标准（以及许多其他地方）使用的语言标签系统。它定义了一种使用来自 IANA 注册表的子标签来形成字符串的方法，该字符串描述内容的语言。 注册表中的子标签主要基于（并与之保持严格兼容）用于识别 语言、文字、地区和国家的 ISO 和 UN 标准。BCP47 也构成 Unicode 区域设置的基础。
有关 BCP 47 关键特性的概述，请参见 HTML 和 XML 中的语言标签。
引用 BCP 47，而不是其组成部分，例如 RFC 5646 或 RFC 4647。
BCP 47 的链接和名称是专门创建的，因此对用于识别语言的标签的 定义有一个不变的引用。RFC 1766、3066、4646 是之前的 （已被取代的）版本。当前版本的 BCP 47 由两个 RFC 组成：5646 和 4647。
明确说明你期望语言标签达到什么符合性级别：BCP 47 定义了两个符合性级别：“valid”和“well-formed”。
well-formed BCP 47 语言标签遵循为语言标签定义的语法： 实现会检查每个语言标签是否由以连字符分隔的子标签组成；每个子标签 根据其在标签中的位置具有特定长度和特定内容（字母、数字或特定组合）。 valid BCP 47 语言标签是 well-formed 的，但还会额外 确保只使用列在 IANA Subtag Registry 中的子标签。请注意，IANA Subtag Registry 会频繁更新并加入新的子标签。
规范可以要求实现检查语言标签是否“valid”， 但在大多数情况下应只要求语言标签为“well-formed”。
大多数规范是语言元数据的二阶消费者——它们使用的是已经 在文档格式中提供的数据（HTML lang、XML xml:lang，或文档格式的语言字段/属性）。
通常，大多数规范关心的是选择资源（例如拼写检查器、分词器、 字体等）或匹配（例如选择显示哪个字符串），并不直接关心 语言标签的内容。无效但 well-formed 的标签只是不会匹配任何内容，而 回退方案通常会提供适当的行为。
可能有些情况下，规范确实希望实现层级检查有效性。在 这些情况下，必须指定标签未能 valid 时的结果（应用是否应终止、 警告用户等）。此外，注册表规模较大且会随时间变化，因此每个 实现都依赖注册表版本。随时间发生的变化通常很小，但真实用户会 遇到互操作性问题，如果某个随机的（过期的）规范实现拒绝 后来才变为 valid 的语言标签。
此外，BCP 47 具有一种扩展机制，用于定义附加的子标签序列。例如，一个 扩展 [RFC6067]（Unicode Locales，使用单例 -u）常用于控制 JavaScript 的国际化 功能（也有其他用途）。验证这些附加子标签很可能超出大多数规范的范围。
规范应要求内容和内容作者使用“valid”语言 标签。
关于语言标签的规范性语言，在内容要求和实现 要求之间可能不同。规范作者需要仔细考虑其规范需要什么符合性 要求和测试，以及要求实现做什么。一种解决方案是 规范性地要求内容作者使用“valid”语言标签，但只要求 实现检查“well-formed”语言标签。
规范 SHOULD 引用 IANA Language Subtag Registry，而不是提供从 ISO 639、ISO 3166 或其他标准中提取的代码列表。
过去，一些用于提供语言标签中子标签的标准并非免费或 公开可用，因此一些规范提供列表以帮助确保互操作性。这 已不再必要。作为 BCP 47 的一部分，IANA 维护语言子标签注册表，这是一个 可公开获取、机器可读的有效子标签列表，用于构造语言标签。该 注册表基于底层标准，包括 ISO 639 的各个部分（639-1、639-2、639-3 等）、ISO 15924 文字代码，以及 ISO 3166 和 UN M.49 地区代码。该注册表 被积极维护、稳定化并且全面，其方式是 Internet 上其他列表可能无法具备的。 每种子标签类型都会在这些标准维护者的帮助和参与下与上游标准保持同步， 因此提取或制作自己的代码列表，或引用其他地方找到的列表， 可能会导致维护问题或混淆。
创建自己的完整语言标签列表会不必要地限制可使用的语言列表。 此外，区域设置数据始终在扩展，因此描述当今支持情况的列表 将在未来过时。限制用户可用的标签或子标签 与我们提供普遍访问的目标相冲突。
这里讨论的是包含结构化文本的独立数据单元。示例可以 包括整个 HTML 页面、XML 文档、JSON 文件、WebVTT 脚本、注释等。
规范应指明如何为整个资源定义默认文本处理 语言。
通常在一个位置识别整个资源的语言，或至少识别默认语言，
可以避免麻烦。例如，在 HTML 文件中，这是通过在 html 元素上设置 lang 属性来完成的。
资源内的内容应继承在资源层级声明的文本处理 语言，除非被明确覆盖。
考虑是否有必要使用单独的声明来指示 文本处理语言与关于资源预期用途的元数据。
在许多情况下，资源只包含一种语言的文本；在更多情况下， 声明为文本处理默认语言的语言，与描述整个资源 元数据的语言相同。在这些情况下，使用单个声明是合理的。
不过，当单个声明引用多个语言时，除非有一种方式 确定应将哪一种语言用作文本处理默认语言，否则就会产生问题。
如果资源只有一个语言声明，且该声明具有 多个语言标签作为值，则必须能够识别该资源的默认文本处理 语言。
这里使用词语 block 和/或 chunk 来指资源整体内部的结构性 组件，该组件将内容组合在一起并与相邻内容分开。一个块与另一个块之间的边界 等同于文本中的段落或章节边界，或文件内离散的数据项。
例如，这可以指 XML 或 HTML 中的块或段落、JSON 中的对象声明、 WebVTT 中的 cue、CSV 文件中的一行等。与之相对的是inline 内容， 它描述段落、句子等内部的一个范围。
对规范中定义的哪些结构与这些要求相关的解释，可能 需要稍作考虑，并取决于所涉及数据的格式。
默认情况下，内容块应继承为整个资源设置的任何 文本处理语言。
有关默认文本处理语言 信息的指导，请参见 2.1 语言基础。
应该能够指出内容块中语言发生变化的位置。
在本节中，我们指的是需要为段落或字符串中间的一段字符 提供的信息。
应该能够指出行内文本段中语言发生变化的位置。
当语言切换会影响内容上的操作，例如拼写检查、呈现、 样式、语音生成、翻译、信息检索等时，就需要 指出受影响的文本范围并识别该内容的语言。
本节中的信息正在 数据格式中的语言和方向元数据要求 [STRING-META] 中开发。 该文档仍在编写中，因此这些指南可能随时发生变化。
Web 上的数据交换应尽可能使用区域设置中立的标准化 格式。不过，Web 上的一些数据必然包含供人类显示的自然语言信息。 这种自然语言信息依赖并受益于语言和方向元数据的存在， 以便正确显示。除了支持 Unicode 之外，包含并指定文本段的基方向和自然 语言的机制，是为 Web 开发新格式和技术时的关键国际化考虑事项之一。
国际化工作组在每个规范中寻找的最基本最佳实践是：
字符串格式的语言和方向元数据工作仍在进行中。规范 可能需要包含一条注，说明未来采用元数据的必要性。下面是一个 原型：
字段 {fieldname} 应遵循
Web 上的字符串：语言和方向元数据 [STRING-META]
中的最佳实践。
这包括使用未来可能出现的任何关于报告字符串
语言和方向元数据的标准。
单个数据值的语言或方向可能不同于同一数据文件 或文档中的其他值。提供与每个可本地化文本字段直接关联的元数据值， 允许适当地覆盖元数据，并帮助应用程序在 汇编、提取、转发或以其他方式处理每个数据字段以供使用时实现自动化处理。
规范 MAY 定义一种机制，为 给定资源中的所有字符串提供默认语言和默认字符串方向。但是，规范 MUST NOT 假定资源范围的默认值就足够了。 即使存在资源范围的设置，也必须能够使用字符串特定的元数据来 覆盖该默认值。
许多文档包含单一语言的数据。提供一种指示预期语言 受众的方式，也许在头部中，可以降低整体文档大小和复杂性。不过， 覆盖特定字符串值的能力仍然重要，因为总有可能某些字符串 不使用文档语言，或者基方向与整个文档中其他可本地化文本值的默认 方向不一致。
指定在没有其他信息的情况下，默认方向和 默认语言均未知。
规范 SHOULD NOT 为不能包含自然语言文本的字段 指定或要求使用语言元数据。
Web 上的文档格式由文本组成。在大多数情况下，给定文档格式中的 数据值意在具有代表性和意义，而不仅仅是任意字符串。数据值 由例如英文关键字组成，并不使该数据值成为意在作为文本显示的自然语言字符串 （也就是说，该值不是可本地化文本）。这类数据 值是文档语法内容的一部分： 它们不仅不需要语言和方向元数据，而且也不应与此类元数据 关联。
对于不是可本地化文本的字符串值和
字符串字段，规范SHOULD 指定该字段本质上是非语言性的，
并建议将语言标签 zxx（“No linguistic content”）
与每个字符串值关联起来。
对于已知包含可本地化文本但
底层格式不可能提供语言元数据的字符串值和字符串字段，规范SHOULD 指定内容语言未知，并建议将
语言标签 und（“Undetermined”）与每个
字符串关联起来。规范MAY 还允许在适当情况下使用启发式方法或
从其他字段值推断语言。
一些字符串值依赖或由现有协议或格式定义。这些字符串通常 不关联或不提供语言或方向元数据。例如，许多 HTTP 头将 它们的内容定义为好像不是可本地化文本，即使在 某些情况下它们包含自然语言文本。消费型规范有时需要依赖 这类字符串，或定义一种格式来描述其中一个字符串。在这些 情况下，消费者将没有语言或方向元数据 可与规范数据结构或文档格式中的字符串关联，并且规范的数据 结构或文档格式所提供的任何元数据（当其作为生产者运行时）也不会通过 底层格式序列化。
规范 SHOULD NOT 使用 Unicode“语言标签”
字符（码点 U+E0000 到 U+E007F）进行语言识别。
Unicode“语言标签”字符已不建议用作语言标签，并且有许多原因 表明它们并不是解决文档格式和线缆协议中语言元数据问题的好方案。 请规范作者注意，不要重新利用这些字符，也不要尝试基于它们构建 传输语言信息的新机制。
生产者有时 需要为给定内容项或数据记录提供本地化值。有时这是通过 语言 协商在生产者和消费者之间完成的。本地化随后 在生产者 中进行，使用协商得到的语言来选择返回的内容。
有时，内容项的本地化是通过让生产者返回该项的多种语言 表示，并让消费者选择要显示的值来完成的。 后一种过程称为语言索引。有关语言索引的更多信息，请参见 [STRING-META] 中的 本地化 考虑事项。
[JSON-LD] 提供了几种机制，用于满足本节中的一些 最佳实践：
除了定义语言标签（在 RFC 5646 中）之外，BCP 47 还包含一个关于将 语言标签与语言范围匹配这一主题的 RFC。 正如引用稳定标识符 BCP 47 来定义语言标签最为合适一样，在引用 其中的匹配方案时，最好也引用 BCP 47。
这是本节中各项要求的列表，可用于自审。对于你的规范相关的所有要求， 选择所在行的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后点击“为 GitHub 创建 markdown”按钮，并将结果复制到 GitHub issue 列表中。请参见更多详情。
基本要求
背景信息
基方向值
在标记中处理方向
auto。这意味着
基方向将通过检查内容本身来确定。更多auto，内容段落的方向应逐段
确定。更多
处理字符串的基方向
为行内或子字符串文本设置基方向
auto，这意味着
基方向将通过检查内容本身来确定。这里的典型方法是
根据任何标记之外的第一个强方向字符来设置方向。更多检测和匹配方向（TBD）
为使用或混合从右到左文字书写的文本确定方向非常重要。这些文字中的字符 按其输入和发音顺序存储在内存中——称为逻辑顺序。 Unicode 双向算法（UBA）为自动呈现以逻辑顺序存储的字符序列提供了大量支持， 使其能够按预期的视觉顺序排列。遗憾的是，仅靠 UBA 不足以正确呈现双向文本，还必须提供 关于给定字符序列应应用的默认方向上下文的附加信息。
基本要求如下。
上述要求的一个特殊情况适用于数据结构和文档格式中的自然语言字符串值：
为从右到左文本添加注解时，必须让原生使用从右到左文字的人 付出最少的工作量。
要求阿拉伯语、迪维希语、希伯来语、波斯语、乌尔都语等使用者 为他们写的每个段落或小数据项添加标记或控制字符，工作量过大，难以管理。 通常，格式应建立默认方向，并只在需要处理例外情况时要求用户介入。
在本节中，我们试图列出一些与文本方向相关的关键概念， 以便更容易理解后续建议。
为了正确显示以“从右到左”文字书写的文本，或包含双向元素的从左到右文本， 确立基方向很重要，该方向将用于支配 文本中各元素显示的顺序。
如果你不熟悉 Unicode 双向算法（UBA）做什么、不做什么，以及 为什么基方向如此重要，请阅读 Unicode 双向算法基础。
在本节中，词语 paragraph 表示纯文本中后跟
硬换行的一段文本，但在其他情况下可能表示不同的事物。在 CSV 中，
它等同于“单元格”，因此一行逗号分隔项实际上是一组逗号分隔的
段落。 在 HTML 中，它等同于最低层级的块元素，通常是 p 元素，但也可能是 div、li 等，
如果它们只包含文本和/或行内元素。在 JSON 中，它通常等同于带引号的字符串值，
但如果字符串值使用标记，则段落与块元素关联；如果字符串值是
多行纯文本，则每一行都是一个段落。
这里使用术语元数据表示 可以是与数据关联的注解或属性的信息，也可以是在允许这种情况的场景中的 标记，或更高层级协议等。
设置基方向有多种可能方式。
ltr、rtl 或 auto。
dir=auto 时发生的情况。）dir
属性时发生的情况。）html 标签上设置 dir 属性时发生的情况。另一个例子是
包含许多 cue 的字幕文件，全部用阿拉伯语书写；最好允许作者在
文件开头说明所有 cue 文本的默认值为 RTL。应始终有一种方式
在需要时覆盖特定段落的方向信息。
auto 时才会发生这种情况，因为 HTML 指定了默认方向。）
在捕获用户的文本输入时，通常需要理解用户输入
数据时的上下文，以确定输入的基方向。例如在 HTML 中，这
可以由从 html 标签继承的方向设置，或
由用户按键来设置表单字段的基方向。随后需要找到
某种方式存储关于基方向的信息，或在呈现时将其与字符串关联。
通常在这种情况下，输入字符串内部的任何方向变化都由用户处理，
并将作为字符串的一部分被捕获。
单个段落内部嵌入的文本范围可能需要具有不同的 基方向。例如，
"The title was '!NOITASILANOITANRETNI'."
其中单引号内的文本段使用希伯来语/阿拉伯语/迪维希语等，并需要具有RTL 基 方向，而不是周围段落的LTR 基方向， 以便正确放置感叹号。
如果标记可供内容作者使用，使用标记来
指示这类行内范围可能更容易且更安全（见下文）。在 HTML 中，通常会使用带有
dir 属性的行内元素来为这类文本段
确立基方向。如果无法给文本添加标记，例如在 HTML 的 title 元素中，或任何只处理纯文本内容的环境中，
就必须诉诸 Unicode 的成对控制字符来为这类内部范围确立基方向。
此外，基方向发生变化的行内范围应与周围文本进行双向隔离， 以便Unicode 双向 算法不会因为边界之间的干扰而产生不正确结果（“溢出效应”）。
这意味着，如果内容作者使用 Unicode 控制码，他们应使用隔离型
控制 RLI/LRI/FSI…PDI，而不是嵌入型控制
RLE/LRE…PDF。
避免依赖控制字符来设置方向的原因包括：
上面最后两项也可能适用于标记，但实现者通常对所包含标记的支持 优于对所包含控制码的支持。
不要期望用户在每个段落开头和结尾添加控制码。那样工作量太大。
此处有必要说明一下 Unicode 字符 
U+200F RIGHT-TO-LEFT MARK（RLM）、
U+200E LEFT-TO-RIGHT MARK（LRM），以及 
U+061C ARABIC LETTER MARK（ALM）。
首先需要明确的是，这三个字符不会为一段文本确立基方向。 它们只是具有强方向属性的不可见字符。
回想前面的示例，这意味着你不能使用 RLM， 例如，让文本 W3C 出现在 希伯来语文本的左侧。只有使用元数据或成对控制字符才能得到正确显示。
当然，如果你使用 first-strong 启发式方法检测基方向（例如 HTML 中的
dir="auto"），那么插入 RLM、ALM 或 LRM 可以有助于影响
检测到的基方向，特别是在相关文本开头原本会导致错误结果的情况下。
请记住，如果使用元数据来设置基方向，则强方向格式化 字符会被忽略，除非元数据明确表示应使用 first-strong 启发式方法。
最后，关于 U+061C ARABIC LETTER MARK（ALM）的使用说明。
该字符用于影响阿拉伯文字文本中数字序列的显示，
适用于数字前没有阿拉伯字母的情况。
以下都是你不能使用语言标签来提供基方向信息的原因：
auto 值。Suppress-Script: Hebr）。像波斯语这样的语言，
通常用 RTL 文字书写，也可能以转写形式书写，而且无法保证
必要的文字标签会出现并携带方向信息。总之，你不能依赖人们
将文字标签作为语言信息的一部分提供，以影响方向。默认基方向的值应包括从左到右、从右到左和 auto。
auto 值允许自动检测一段文本的基方向。
例如，HTML 中 dir 的 auto
值会在文本中寻找第一个强方向字符，
同时也忽略某些标记项，以猜测文本的基方向。请注意，
自动检测算法远非完美。first-strong 检测无法正确
识别实际是从右到左、但以强 LTR 字符开头的文本。
试图根据文本内容判断基方向的算法也存在问题。最佳
场景是基方向已知并已声明。
本节讨论如何定义适用于使用标记组织内容的资源的双向处理方法。 其中一些建议不同于处理 Web 上字符串的建议（请参见 3.5 处理字符串的基方向）。
规范应指明如何为整个资源定义默认基方向， 即设置整体基方向。
在没有其他信息的情况下，默认基方向应为 auto。
内容作者必须能够指示文本中基方向发生变化的部分。 在块级层面，这应使用属性或元数据实现，并且不应 要求内容作者使用 Unicode 控制字符来控制方向。
依赖 Unicode 控制字符来为每个块确立方向并不可行，因为 换行会终止这类控制字符的作用。如果必须在每个需要的位置 出现控制字符，也会使数据稳定性大大降低，并使管理变得不必要地困难。
这里的典型方法是根据任何标记之外的第一个强方向字符 来设置方向，但这并不是唯一可能的方法。当方向设置为 auto 时， 用于确定方向性的算法应与接收方预期的算法相匹配。
first-strong 算法会根据 Unicode 定义寻找段落中第一个具有强方向 属性的字符。然后根据该字符的方向设置段落的基方向。
请注意，当第一个字符并非段落其余部分的典型字符时，first-strong 算法 可能会错误猜测段落方向，例如 RTL 段落或 行以 LTR 品牌名或技术术语开头时。
有关检测方向算法的更多信息，请参见 讨论 HTML 时所参考文档中的 估算算法。
如果纯文本的整体基方向设置为 auto，内容段落的方向应
逐段确定。
要指示一行的开始/结束，应使用 'start' 和 'end'，或 'inline-start' 和 'inline-end'，而不是 'left' 和 'right'。
例如，HTML 有一个 dir 属性，它能够
在无需 CSS 样式协助的情况下管理基方向。XML 格式应定义专用
标记来表示方向信息，即使它们需要 CSS 来实现所需显示，
因为文本可能以其他方式使用。
样式表（如 CSS）并不总是会随数据一起使用，或在数据被 聚合等情况下随数据携带。方向信息对于数据的正确显示至关重要， 并且应更紧密、更持久地与标记或数据关联。
本节中的信息摘自 Web 上的字符串：语言和方向 元数据。该文档仍在编写中，因此这些指南可能随时发生 变化。
指定字符串消费者应使用启发式方法，最好基于 Unicode 标准的 first-strong 算法，在未提供元数据时检测字符串的 基方向。
最佳实践、建议和 缺口，见Web 上的字符串：语言和方向元数据
这里的“行内文本”在标记中有一个容易理解的含义。它也适用于字符串 （例如 JSON、CSV 或其他纯文本格式中），表示不包含字符串中 所有字符的字符段。
必须能够指示基方向发生变化的行内文本段。 如果标记可用，这是首选方法。否则，你的规范必须 要求接收应用程序识别并正确实现 Unicode 控制字符。
还必须能够将行内文本段的方向设置为 auto，这意味着基方向将通过
检查内容本身来确定。这里的典型方法是根据任何标记之外的
第一个强方向字符来设置方向。
first-strong 算法会根据 Unicode 定义寻找段落中第一个具有强方向 属性的字符。然后根据该字符的方向设置段落的基方向。
请注意，当第一个字符并非段落其余部分的典型字符时，first-strong 算法 可能会错误猜测段落方向，例如RTL 段落或行 以LTR 品牌名或技术术语开头时。
有关检测方向算法的更多信息，请参见 讨论 HTML 时所参考文档中的 估算算法。
如果用户使用 Unicode 双向控制字符，应用程序必须支持 带 PDI 字符的隔离型 RLI/LRI/FSI，并且规范应推荐它们 （而不是带 PDF 的 RLE/LRE）。
RLM/LRM 的使用应是适当的，并且规范中应明确这些控制字符 能做什么、不能做什么。
Unicode 双向控制字符 U+200F RIGHT-TO-LEFT MARK 和 U+200E LEFT-TO-RIGHT MARK 本身不足以管理
双向文本。它们不能为嵌入文本产生不同的基方向。为此，你需要
能够指示嵌入文本范围的开始和结束。 如果可用，最好通过
标记完成；否则使用上面刚提到的其他 Unicode 双向控制符。
对于标记，为控制基方向和双向覆盖提供专用属性； 不要依赖用户将样式属性应用到任意标记来实现双向 控制。
对于标记，允许在所有包含文本的行内元素上使用 双向属性。
对于标记，提供允许用户 (a) 创建隔离或 嵌入的基方向，或 (b) 完全覆盖双向算法的属性。这类属性 应允许用户在这两种场景中的任一种将方向设置为 LTR、RTL 或 Auto。
这是本节中各项要求的列表，可用于自审。对于你的规范相关的所有要求， 选择所在行的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后点击“为 GitHub 创建 markdown”按钮，并将结果复制到 GitHub issue 列表中。请参见更多详情。
字符和字符编码基础
选择“字符串”的定义
DOMString。
（此用途列表并不详尽。）更多USVString。
对任何涉及UTF-8
编码的过程，
或者任何未配对代理项码点会产生
错误的地方，请使用 USVString。更多DOMString 和 USVString。
通常你会选择 DOMString，
而不是 USVString，因为
后者需要额外处理，而这对大多数文档格式或协议并无益处。更多
DOMString，
或在少数情况下指定 USVString，除非
有理由需要与特定字节值交互，或者不能假定使用 UTF-8 字符
编码。更多Uint8Array，
例如不包含文本的数据，或表示文本但从不需要处理的字节序列
（例如复制缓冲区时）。更多
ByteString。更多定义引用处理模型
包含和排除字符范围
使用专用区
选择字符编码
识别字符编码
设计字符转义
存储文本
空白字符
character 一词在不同上下文中含义不同：它可以分别指给定文本单元的 视觉、逻辑或字节层级表示。这使得该术语过于不精确，不适合在规范中随意使用。 因此，理解计算系统中如何定义和编码文本，以及用于使这类规范无歧义的相关术语， 是讨论字符串数据处理的必要前提。
规范开发者以及基于这些规范的软件开发者，可能更熟悉他们所经历过的 “character”一词用法，而不太熟悉国际化上下文中各种各样的用法。 此外，在计算上下文中，字符常常与相关概念混淆，导致规范和软件 不完整或不适当。
在指定字符、字符串或任何处理字符或字符串的过程时， 请使用最具体且适当的术语。除非你有理由不这样做，否则请将码点 定义为Unicode 标量值， 并优先使用该术语，而不是“character”。
使用本节中最适当的术语。以下是一些其他推荐术语：
| 单元类型 | 不要使用 character，而应使用... | 说明 |
|---|---|---|
| 文本单元 | 码点, Unicode 码点, Unicode 标量值 |
文本的逻辑单元，不考虑字符编码 形式或任何特定序列化。 |
| 存储、处理、序列化、编码 | 码元 | 编码和序列化的单位。码元通常 在线缆格式和文件格式、底层文本处理中指定。取决于所使用的字符 编码（最好是 UTF-8 或 UTF-16）。 |
| 视觉单元、用户感知字符、选择/分段 | 字素
簇, 排版 字符单元 |
将文本拆分为视觉单元、大多数视觉选择和截断。这项建议最具细微差别。 |
| 字体元素 | 字形 | 单个显示值。主要在讨论字体内容时使用该术语。 |
如果你无法避免使用术语“character”，你MUST 包含该术语的清晰定义。
以下是核心术语的简要词汇表：
[Unicode] [D7] 将抽象
字符定义为：用于组织、控制或
表示文本数据的信息单元。
该定义必然较为宽泛，并进一步说明抽象
字符没有特定的具体形式（因此不要与字体中的字形混淆），也不是
用户可能认为的“字符”（因此不要与字素混淆）。避免在
你自己的规范中使用该术语。
字符 集是抽象 字符的无序集合（换句话说，它是一个集合），可一起用于编码文本。 字符集中的字符集合 有时称为其字符库。 大多数字符 集只支持特定范围的语言或文字。
[Unicode]，有时称为通用字符 集，包括当前用于在计算机系统中编码文本的所有字符，包括 历史上或已消亡的书写系统以及现代用法、专用字符、排版符号和 其他内容，例如 emoji。所有其他字符集都是 Unicode 的已定义子集。年度 修订会扩展已编码字符集合。
[Unicode] 标准定义的远不止一个字符 集。它还定义了许多用于文本处理和呈现的属性、算法和其他细节。
码 点是在字符集中 一个抽象 字符的唯一标识符。为了使字符集 有用，它需要无歧义地识别每个字符。在大多数字符集中， 码点 是一个数字（或一组数字），用于描述该字符在集合中的字符表或图表中的位置。
在 [Unicode] 中，码点是介于
0x0000 和 0x10FFFF（含）之间的整数。它以十六进制表示法书写（见4.11
引用 Unicode 字符）。Unicode 码点
有时称为Unicode
标量值。
Unicode 中已分配给抽象字符的每个码点也会获得一个唯一且不可变的名称。
Unicode 还会将各种属性与每个已分配字符关联起来。许多这些属性出现在
Unicode 字符数据库（或 UCD）[UAX44]
中，
其他属性则分配在辅助文件或表中。
[Unicode] [D11] 将已编码
字符定义为抽象字符与码点之间的关联
（或映射）
。对于规范而言，通常首选术语码点，或者在需要更高特异性时，使用
Unicode
码点或Unicode
标量
值。
码点 不直接用于软件中的字符存储和交换。相反，存在各种方案，用于编码和处理它们所表示的字符， 或从一种表示转换为另一种表示。
码 元是物理存储和信息交换的单位，构成计算机处理、存储和通信的基础。 最常见的码元称为字节或 八位组，由 8 位组成。
不同运行时环境使用不同大小的码 元。其他常见大小包括 16 位或 32 位 单元。例如，在 Web 上，[DOM]、JavaScript 以及 [INFRA] 中的各种字符串类型使用 16 位码元。这些规范使用 按照 [Unicode] 的 UTF-16 字符编码规则处理的 16 位码元。
字符编码 形式（有时简称为字符 编码）是一组规则，用于从码点（位于字符集中） 编码到用于存储和处理文本的码元； 或用于从码元解码回码点。 非 Unicode 字符编码形式统称为遗留字符 编码。
UTF-8 是 [Unicode] 的一种多字节字符编码形式。 它是 Web 上最常用的字符编码。 UTF-8 使用 8 位字节作为其码元。UTF-8 是可变宽度 编码，因为它根据所编码的码点使用不同数量的码元。
熟悉的 7 位 ASCII 字符（从 U+0000 到 U+007F 的码点）
在 UTF-8 中编码需要一个字节。
| 字符 | 码点 | UTF-8 码元（字节） |
|---|---|---|
| A | U+0041 |
0x41 |
从 U+0080 到 U+07FF 的码点需要两个字节。
| À | U+00C0 |
0xC3 0x80 |
从 U+0800 到 U+FFFF 的码点需要三个字节。
| न | U+0928 |
0xE0 0xA4 0xA8 |
最后，从 U+10000 到 U+10FFFF 的码点需要四个字节。
| 👪 | U+1F46A |
0xF0 0x9F 0x91 0xAA |
规范、软件和内容MUST NOT要求或 依赖码点与呈现单位 （例如字素簇、字形或 排版字符单元）之间的一一映射。
视觉呈现单位 C002，见万维网字符模型 1.0：基础。
字符、击键和 字形示例，见万维网字符模型 1.0：基础。
在本文档中，视觉文本单元指用户感知到的 可见文本的单个单元。它可以在屏幕上，也可以在其他媒介中，例如 印在纸上或写在餐巾纸背面。该术语必然不精确，因为用户 感知常常取决于对文字和书写系统的熟悉程度，尤其是在 使用组合附加符号、复杂定位或基于上下文的复杂塑形的书写系统中。 避免在你自己的规范中使用该术语。
字素簇 是编码文本中对视觉文本单元的计算近似， 也就是说，它是一串码点， 这些码点从用户角度看预期形成单个视觉文本单元。[Unicode] 提供了一种计算这些边界的方法， 以协助文本处理，因为对于许多文本操作而言，这样的序列应作为单个、不可分割的文本单元处理。 例如，当光标穿过文本时，光标应一起“跳过”或选择整个视觉文本单元 （及其底层码点）。不应能够将光标移动到视觉文本单元的“中间”。 （除非另有规定，本文档中的术语字素 簇指Unicode 文本分段 [UAX29] 所称的“扩展默认字素 簇”。）
请注意，有些文本操作确实允许用户与码点 在字素簇内部 交互。例如，某些编辑功能（如退格）会从视觉文本单元末尾逐步删除字符 （例如，允许用户纠正拼写错误，而不必擦除整个簇）。
术语排版 字符单元由 [CSS] 定义，其中它用于指在特定操作中应被视为“单一”的不同类型的 码点 序列。有时它与术语字素 簇一致，有时则不同。只有在你理解上下文和用法时才使用该术语。
字形是字符（或字符序列）由特定字体呈现时的视觉表示。字形并不总是与抽象字符具有
1:1 关系。它们可以表示一个
字符的一部分或多个字符的组合。不同的字形可以表示同一个码点。例如，以下都是
AU+0041 LATIN CAPITAL LETTER A 的不同字形：
因此，字体 是用于呈现文本的特定字形集合。
在某些文字中，字符与音位关系密切（音位是在特定口语语言上下文中最小的可区别声音）， 而在其他文字中，它们与意义关系密切。即使字符（宽泛地）对应于音位， 这种关系也可能并不简单，并且字符与音位之间很少存在一一对应。
以下是术语 character 与声音单位不匹配的一些示例：
规范和软件MUST NOT要求或依赖 一次击键产生一个字符，也不得要求一个字符用一次击键输入（即使使用修饰键）， 也不得要求世界各地的键盘都相同。
输入单位 C005，见 万维网字符模型 1.0：基础。
字符、击键和 字形示例，见万维网字符模型 1.0：基础。
在键盘输入中，击键和输入字符并不总是一一对应。 键盘上能容纳的按键数量有限。有些键盘会通过一次按键产生多个码点。 在其他情况下（“死键”），某个按键不会产生 字符，但会影响后续按键的结果。许多书写系统的字符太多， 无法放入键盘，必须依赖更复杂的输入法，将 击键序列转换为字符序列。其他语言可能需要使用特殊修饰键来 输入某些字符。
有关非平凡输入示例，请参见 字符、击键和 字形示例。
字符串通常被理解为“字符”的序列。由于 [Unicode] 是 理解和处理文本的基础，包括使用遗留字符 编码的文本，因此字符串的基本定义依赖于 Unicode 及其已编码字符概念。具体而言：
字符串是由零个或多个Unicode 标量值组成的格式良好的序列。
由于处理字符串的方式有多种，“字符串”的不同定义已经发展出来， 以支持不同规范的需求。请务必理解你的规范需求，并使用最适当且精确的定义。
在 Web 上，有三种字符串类型：
USVString。基于
Unicode 码
点的字符串，也称为Unicode 标量值DOMString。基于
UTF-16 码元的字符串
ByteString。基于
某种字符编码形式
（最好是 UTF-8）中字节的字符串这些不同字符串类型之间的一个差异是如何处理代理项码点。请注意码点（它表示Unicode 标量 值，即字符）与码元（字符 编码形式中的编码单位）之间的区别。
UTF-16 字符编码形式使用
16 位码元。
标量值需要超过 16 位的字符，会使用一对代理项码元编码：一个“低代理项”（位于
U+D800-U+DBFF 范围内），后跟一个“高代理项”（位于 U+DC00-U+DFFF
范围内）。Unicode 将这些范围中的码点保留为
非字符，以便不会混淆 码元在UTF-16 中的用法与普通文本。
在 USVString 中，孤立的代理项码点是
无效的，并且实现必须将字符串中发现的任何此类码点替换为 Unicode 替换字符（�U+FFFD REPLACEMENT CHARACTER）。对于最常见算法按
标量值操作的字符串（例如百分号编码），或对于无法处理输入中
代理项的操作（例如将字符串传递给原生平台 API 的 API），应使用 USVString。以下任一引用均等同于此：
在 DOMString 中，未配对的代理项码元可以
出现在字符串中。大多数字符串操作不需要解释字符串内部的码元。
指定 DOMString 意味着
实现不需要验证字符串的内容，这使它成为大多数数据结构、格式或 API 的理想字符串类型。
[DOM] 和
JavaScript 字符串使用 DOMString 作为其字符串类型，
而 [INFRA] 标准将术语“string”定义为 DOMString：
字符串是无符号 16 位整数的序列，也称为码元。
ByteString 取决于用于
将字符编码为字节的字符
编码形式。遗留字符
编码没有“代理项”概念，因此通常无法编码
代理项码点。有效的UTF-8 不允许代理项码点：
在将文本编码为UTF-8
或从UTF-8解码文本时，
这些码点会被替换为 �U+FFFD REPLACEMENT CHARACTER。将
UTF-16 转换为UTF-8 时，任何代理项对都会转换为
编码特定标量值的正确
UTF-8 字节序列。
避免在单个文档或协议操作中混用 DOMString 和 USVString。通常你会选择
DOMString，而不是 USVString，因为后者
需要额外处理，而这对大多数文档格式或协议并无益处。
在 Unicode 被广泛采用之前，常见做法是将字符串定义为字节
字符串。这样的字符串只是字节值序列，而不是
字符或码点序列。字节字符串的一个熟悉
表现形式是 C 编程语言中的 char*。
处理或解释字节字符串取决于字符编码形式。 许多遗留字符 编码是有状态的：处理这类编码通常需要从字节缓冲区开头开始， 以便保留字符状态，并能够成功解码、处理或修改抽象字符。这类编码中的给定字节值可能会根据 相邻字节而表示不同含义。例如，完全相同的字节值可能独立表示一个 字符，也可能根据前面的字节成为表示某个不同字符的多字节序列的一部分。 不同遗留字符 编码中，用于确定如何解释每个字节或字节序列的规则不同。使用错误的字符编码 处理字节字符串会产生格式错误的字符（这种效果有时称为乱码）。
UTF-8 是 Web 上线缆格式和文档格式首选的字符编码 [ENCODING]，也是 一般 Internet 上首选的字符编码 [RFC3629]。当内容以 UTF-8 编码时，很少有理由将其作为字节序列来交互。大多数 Web API 和 接口更关注码点序列，因为那表示 所讨论的字符，而不是特定的字节值。
有时规范确实需要处理字节值的存储、解释和操作。特别是，许多
文档格式和协议围绕 7 位 [ASCII]
字节的使用来定义，同时允许通过使用各种字符或数据编码方案来包含或交换非 ASCII 数据值。
有时这是通过指定一种字符编码形式来完成的，
例如 text 媒体类型的 charset 参数。也可能通过使用某种
特殊语法来编码字节值完成，例如百分号
编码。
UTF-8 的普及，包括作为首选和默认的字符编码形式， 减少了大多数规范访问或操作底层字节值的需要。UTF-8 的设计使得 7 位 ASCII 文本 也是有效的 UTF-8，这在处理基于 ASCII 的格式编码或解码时可能很重要。
如果相关字段意在作为字符串处理，那么处理 Unicode 字符会比直接 处理字节值更可靠。编码到这些字段中的数据会从线缆格式反序列化为你的本地 内存中字符串表示，例如 [DOM]、JavaScript 字符串，或你的平台原生 Unicode 字符串类型。稍后它需要使用某种字符编码形式 （通常——且最好——是 UTF-8）序列化为线缆格式。
处理字节序列时指定 Uint8Array，
例如用于不包含文本的数据，或表示文本但从不需要处理的字节序列
（例如复制缓冲区时）。
在极少数情况下，如果规范需要处理使用字节编码的字符串，
并且转换为 Unicode 或从 Unicode 转换是不适当的，请指定 ByteString。
Web 平台设计原则 [DESIGN-PRINCIPLES] 中的 IDL 字符串类型
ByteString 不是
通用字符串类型。不要用它在 [WebIDL] 中定义数据结构。
规范MAY选择禁止或弃用某些 字符编码，并将其他编码设为强制要求。无论实际字符编码是什么， 指定行为MUST与处理按如下方式发生时相同： (a) 实现该规范的应用程序接收的任何文本数据对象的字符编码 MUST被确定，并且该数据对象MUST被解释为 Unicode 字符序列——这MUST等同于将该数据对象转码为某种 Unicode 编码 形式，必要时调整任何字符编码标签，并以该 Unicode 编码形式 接收它，(b) 所有处理MUST在此 Unicode 字符序列上进行，(c) 如果应用程序输出文本，则该 Unicode 字符序列MUST使用规范允许的字符编码之一进行编码。
引用处理模型 C014，见 万维网字符模型：基础
如果某个规范涉及多个文本数据对象（例如 引用外部已解析实体的 XML 文档），它MAY选择 允许这些数据对象使用不同字符编码。在所有情况下，引用 处理模型MUST应用于所有文本数据对象。
引用处理模型 C014，见 万维网字符模型：基础
这里的“代理项码点”指使用 U+D800
到 U+DFFF（含）范围内的字符值。这些码点被保留，
以允许 UTF-16 字符编码寻址补充
字符。代理项始终成对使用，并且只在使用 UTF-16 编码时出现。
单个代理项码点称为“未配对代理项”，并且绝不应使用。
历史上（尤其是在 Unicode 创建之前的时期），有许多编码 字符集被广泛使用，并具有不同的方案，用于将字符编码并序列化 到计算机系统的内存或存储中。除了基于标准的方案（如 ISO/IEC 8859 指定的方案）外，还有许多专有的、特定厂商或特定平台的字符 集，通常还带有关联的字符编码形式。 在本文档中，当提及遗留（非 Unicode）编码字符集的 字符编码形式时， 我们指的是 [Encoding] 中规定的从字节到 Unicode 码点的特定现代映射。
所有文档格式、协议和序列化形式都使用 UTF-8。
UTF-8 是几乎所有应用的最佳选择。
新协议和格式，以及在新上下文中部署的现有格式，都要求使用 UTF-8 字符编码。此政策适用于 IETF 和 Web 标准，并在 [RFC2277]、[RFC3629]、[Encoding]、[design-principles] 以及更多文档中阐明。唯一 需要遗留字符 编码的规范，是那些处理旧协议或格式的规范，即便如此也强烈 推荐使用 UTF-8。
如果出于历史原因，规范允许遗留字符 编码，它MUST将字符编码集合限制为 Encoding Standard 中 “Names and Labels”一节列出的编码。除非基于私人协议，否则其他编码SHOULD NOT被使用。
不能仅凭字节值可靠地检测字符 编码。如果允许 UTF-8 之外的编码，就必须有某种机制让消费者确定所用编码 是什么。
如果协议、格式或 API 基于某个已经具有 选择、应用或标记字符编码规则的格式， 则该规范MUST NOT定义单独的机制来识别字符编码。
字符编码的选择和识别， C017，见万维网字符模型：基础
文档格式或协议有时会提供对遗留字符 编码的支持。建立在这些格式之上的规范，在可行时可以规定 符合要求的实现仅使用 UTF-8。
通常建议提供字符转义，以便可以使用纯文本编辑器输入 难以输入或编辑的序列。转义序列对不可见或有歧义的 Unicode 字符尤其有用， 包括零宽空格、软连字符、各种双向控制、蒙古文元音分隔符等。
有关在标记中使用转义的建议（其中大部分也可推广到其他格式），请参见在标记和 CSS 中使用字符转义。
下面是 Web 或常见编程语言中常见转义机制的一些示例。
这里的示例字符是 😽U+1F63D KISSING CAT FACE WITH CLOSED EYES。
| 出现于 | 类型 | 示例 | 说明 |
|---|---|---|---|
| HTML、XML | 十六进制 NCR | 😽 |
Unicode 码点的十六进制编码 |
| 十进制 NCR | 😽 |
Unicode 码点的十进制编码 | |
| JavaScript、Ruby、Rust、[UTS18] | \u 定界 |
\u{1F63D} |
Unicode 码点的十六进制编码 |
| Perl | \x 定界 |
\x{1F63D} |
Unicode 码点的十六进制编码；使用 x 而不是更常见的
u
|
| Java、JavaScript、JSON、C、C++、Python | \u UTF-16 码元 |
\uD83D\uDE3D |
UTF-16 码元的固定宽度十六进制编码；补充 字符被编码为代理项对 |
| C、C++、Python | \U UTF-32 码元 |
\U0001f63d |
UTF-32 码元的固定宽度十六进制编码；最常与
\u 转义一起使用（后者对更常见的BMP
字符效率更高）。例如， \u00c0 \U0001f63d \u12fe
|
| URL | URL Encode | %F0%9F%98%BD |
UTF-8 字节的十六进制编码；每个字节需要三个字符；每个码点需要 1 到 4 个字节 |
选择转义机制时，请注意通常首选十六进制而不是十进制编码， 因为 Unicode 标准及其引用中通常使用十六进制。
涉及范围选择的协议和 API 规范SHOULD支持非连续逻辑选择，至少达到在这些协议和 API 之上支持屏幕视觉选择实现所需的程度。
视觉呈现和逻辑顺序， C004，见万维网字符模型：基础。
空白字符是在排版中表示水平或垂直空间的字符。 空白字符可以具有不同的视觉效果：有些空白字符没有可见 效果，而另一些则在页面上表示更大、更小或可变数量的空间。
使用术语“whitespace”的规范SHOULD 明确定义该术语的含义。
大多数规范SHOULD将 whitespace 定义为 具有 Unicode White_Space 属性的字符。
为受限于 ASCII 或空白分隔格式 （示例包括 HTML 或 CSS）的词汇表定义 whitespace 的规范SHOULD在其语法中指定ASCII whitespace。
如果规范将“whitespace”定义为不同于 ASCII 或 Unicode whitespace 的内容，则具体码点MUST被列出。
一些规范，例如 ECMAScript， 提供了自己的 whitespace 定义，该定义不同于上述定义，以满足其自身特定 要求。
下表是各种规范中空白字符的定义。
white_space 属性 |
pattern_white_space 属性 |
ASCII whitespace（HTML） | CSS whitespace | ECMAScript | XML | |
|---|---|---|---|---|---|---|
 U+0009 (horizontal tab) |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
 U+000A (line feed) |
✓ | ✓ | ✓ | ✓ | ✓ | |
 U+000B (vertical tab) |
✓ | ✓ | ✓ | |||
 U+000C (form feed) |
✓ | ✓ | ✓ | ✓ | ||
 U+000D (carriage return) |
✓ | ✓ | ✓ | ✓ | ||
 U+0020 SPACE |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
 U+0085 (next line) |
✓ | ✓ | ||||
 U+00A0 NO-BREAK SPACE |
✓ | ✓ | ||||
 U+1680 OGHAM SPACE MARK |
✓ | ✓ | ||||
 U+2000 EN QUAD |
✓ | ✓ | ||||
 U+2001 EM QUAD |
✓ | ✓ | ||||
 U+2002 EN SPACE |
✓ | ✓ | ||||
 U+2003 EM SPACE |
✓ | ✓ | ||||
 U+2004 THREE-PER-EM SPACE |
✓ | ✓ | ||||
 U+2005 FOUR-PER-EM SPACE |
✓ | ✓ | ||||
 U+2006 SIX-PER-EM SPACE |
✓ | ✓ | ||||
 U+2007 FIGURE SPACE |
✓ | ✓ | ||||
 U+2008 PUNCTUATION SPACE |
✓ | ✓ | ||||
 U+2009 THIN SPACE |
✓ | ✓ | ||||
 U+200A HAIR SPACE |
✓ | ✓ | ||||
U+200E LEFT-TO-RIGHT MARK |
✓ | |||||
U+200F RIGHT-TO-LEFT MARK |
✓ | |||||
 U+2028 LINE SEPARATOR |
✓ | ✓ | ||||
 U+2029 PARAGRAPH SEPARATOR |
✓ | ✓ | ||||
 U+202F NARROW NO-BREAK SPACE |
✓ | ✓ | ||||
 U+205F MEDIUM MATHEMATICAL SPACE |
✓ | ✓ | ||||
 U+3000 IDEOGRAPHIC SPACE |
✓ | ✓ | ||||
 U+FEFF ZERO WIDTH NO-BREAK SPACE |
✓ |
有些规范使用与上方某一列相同的定义，因此未列入表中。
例如，WebDriver 使用 white_space 属性，而 WebGPU Shading Language 使用
pattern_white_space 属性。
在规范中使用 U+XXXX 语法表示 Unicode 码点。
在规范中引用 Unicode 码点时，U+XXXX 格式已被很好理解。
当它们以序列形式出现时，用空格分隔。不需要额外装饰。
请注意，一个码点可能包含四个、五个或六个十六进制数字。
当所需数字少于四位时，码点编号会用零填充。
使用 Unicode 字符名称描述特定码点。
Unicode 为每个已分配的 Unicode 码点分配唯一且不可变的名称。
在规范中引用特定字符时使用这些名称（同时使用 U+XXXX 记法中的码点）将有助于使你的规范无歧义。
RECOMMENDED 使用字符命名模板。
对于大多数字符，模板如下所示：
<span class="codepoint" translate="no"><bdi lang="??">&#xXXXX;</bdi><code class="uname">U+XXXX UNICODE_CHARACTER_NAME_ALL_IN_CAPS</code></span>
bdi 元素用于确保从右到左的示例字符
不会干扰页面布局。不要在闭合的 bdi
与后面的 code 元素之间包含换行或空格；间距和呈现由样式控制。
lang 属性应适当填写，以便针对给定上下文
获得正确的字体选择。东亚语言（如中文、日文或韩文）或阿拉伯文字中的示例，
有时在选择语言标签时需要更加谨慎。少数情况下，对于某些语言，可能需要
在你自己的样式表中使用 font-family 和/或
font-size 调整 bdi 元素的样式。
对于不可见字符（如控制字符）、组合字符或空白字符，请使用图片代替该字符；
或者你也可以省略该字符及其周围的 bdi 元素。
<span class="codepoint" translate="no"><img alt="..." src="..."><code class="uname">U+XXXX UNICODE_CHARACTER_NAME_ALL_IN_CAPS</code></span>
短字符序列应列出字符名称，并用 + 分隔。
在某些情况下，包含字符名称和额外标记会显得过于拘泥细节并影响可用性，
但要谨慎，避免过于随意以至于损害含义。特别是，长序列有时只会列出码点，
不过在可能的情况下应保留字符名称以保持清晰。本文档中有一个示例，见
关于组合“family” emoji 的讨论：👨👩👧👧U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467
由于规范通常既需要字符的定义，也需要与这些字符关联的 语义，因此规范SHOULD包含对 Unicode 标准的引用， 无论它们是否包含对 ISO/IEC 10646 的引用。
引用 Unicode 标准和 ISO/IEC 10646，C062，见万维网字符模型：基础。
如果希望在规范发布之后分配的字符也可用于该规范， 则MUST对 Unicode 标准作通用引用。也MAY包含对 Unicode 标准的特定引用，以确保依赖于特定版本的 功能可用且不会随时间改变。
引用 Unicode 标准和 ISO/IEC 10646，C063，见万维网字符模型：基础。
所有对 Unicode 标准的通用引用MUST指向包含该引用的 规范发布日期时可用的 Unicode 标准最新版本。
引用 Unicode 标准和 ISO/IEC 10646，C064，见万维网字符模型：基础。
所有对 ISO/IEC 10646 的通用引用MUST指向包含该引用的 规范发布日期时可用的 ISO/IEC 10646 最新版本。
引用 Unicode 标准和 ISO/IEC 10646，C065，见万维网字符模型：基础。
这是本节中各项要求的列表，可用于自审。对于你的规范相关的所有要求， 选择所在行的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后点击“为 GitHub 创建 markdown”按钮，并将结果复制到 GitHub issue 列表中。请参见 更多详情。
选择用于分段、索引等的文本单元
匹配标识符和语法内容的字符串同一性
使用 Unicode 规范化
大小写折叠
截断或限制字符串长度
字符串拼接
处理文件名和路径名
在许多情况下，软件过程需要访问子字符串或指向字符串内部位置，并通过使用索引来实现， 即字符串内的数字“位置”。当此类索引在 Web 组件之间交换时，就需要对字符串索引作出 约定的定义，以确保行为一致。出现的两个主要问题是：“计数单位是什么？”以及 “我们从 0 还是 1 开始计数？”。
在用户交互是主要关注点的应用中，字素簇MAY 作为字符串索引的基础。
根据字素簇定义索引的规范MUST要么：(a) 按 Unicode 标准附录 #29， Unicode 文本分段（UTR #29）中定义的扩展字素簇来定义字素簇，要么 (b) 明确定义如何将定制应用于索引操作。
反例是在 DOM Level 1 中使用 UTF-16。不鼓励使用 UTF-16 码点，因为它留下了索引出现在两个代理项字符之间的可能性， 这会造成严重问题（见6.5 截断或限制字符串长度）。
实现MUST NOT改变正在交换、读取、解析或处理的 文本数据的规范化形式，除非作为文本转换（如将内容转码为 Unicode 字符编码、 大小写折叠或其他由用户发起的更改）的副作用而必须如此，因为消费者或内容本身可能依赖 去规范化表示。
规范化的其他考虑事项， 见万维网字符模型：字符串匹配。
当操作可能从已规范化的文本输入产生去规范化输出时， 规范MUST定义所得输出是否要求被规范化。规范MAY 声明某些操作可选择执行规范化；在这种情况下，默认值SHOULD 是执行规范化，并且SHOULD使用显式选项关闭规范化。
在文档格式中指定 规范化时的要求，见万维网字符模型：字符串 匹配。
规范化敏感操作MUST NOT执行， 除非实现首先通过检查确认文本处于规范化形式，或者它自身已重新规范化该文本。 私人系统内部MAY创建不受这些规则约束的私人协议， 但任何外部可观察结果MUST与遵守这些规则时相同。
在文档格式中指定 规范化时的要求，见万维网字符模型：字符串 匹配。
修改文本并执行规范化敏感操作的规范化文本处理组件MUST表现得仿佛每次修改之后都进行了规范化， 以便任何后续规范化敏感操作始终表现得像是在处理已规范化文本。
在文档格式中指定 规范化时的要求，见万维网字符模型：字符串 匹配。
执行字符串值比较或匹配的规范SHOULD指定关于 Unicode 规范化的适当说明或警告。
在规范中使用或采用 Unicode 规范化，通常是定义给定格式或协议中如何进行匹配的一部分。为了帮助规范作者和实现者理解其中涉及的 某些复杂性，国际化工作组制定了一份文档，描述字符串匹配和比较的考虑事项： 万维网字符模型：字符串 匹配 [CHARMOD-NORM]。
规范需要作出的选择之一是，是否要求将 Unicode 规范化作为匹配规范词汇表中 各种“值”的一部分。值通常是文档格式或协议语法的一部分，包括属性名称或值、 元素名称或值、ID 等等。遵循建议、不将规范化作为匹配一部分的规范， 应包含以下注，以提醒内容作者。
示例注。此版本必然不会具体说明什么构成“值”： 规范可能希望更加具体。
本规范不允许出于比较目的对值进行 Unicode 规范化。 视觉和语义上相同但使用不同 Unicode 字符序列的值将不会匹配。建议内容作者 始终使用相同的编码序列，或在选择值时避免可能引起问题的字符。更多信息请参见 [CHARMOD-NORM]。
选择要求将规范化作为字符串匹配一部分的规范应包含以下警告：
示例警告。此版本必然不会具体说明什么构成“值”： 规范可能希望更加具体。
本规范在值匹配过程中应用 Unicode 规范化。 这可能会影响受影响文本的外观和含义。更多信息请参见 [CHARMOD-NORM]。
如果上述内容不满足你的需求，或你不确定如何使用，请联系 I18N WG 获取替代方案或协助。
将字符串匹配定义为格式、协议或形式语言定义的一部分 （可能包括解析、匹配、分词等操作）的规范和实现MUST 定义所使用的条件和匹配形式。这些形式MUST是以下之一： (a) 区分大小写 (b) 使用 Unicode 完整大小写折叠的 Unicode 不区分大小写 (c) ASCII 不区分大小写。
在包含超过 Unicode 基本拉丁（ASCII）范围的词汇表中定义不区分大小写 匹配的规范MUST指定 Unicode 完整大小写折叠匹配。
Unicode 不区分大小写 匹配，见万维网字符模型：字符串匹配。
在限制于 Unicode 基本拉丁（ASCII）子集的词汇表中定义不区分大小写 匹配的规范MAY指定 ASCII 不区分大小写匹配。
ASCII 不区分大小写匹配， 见万维网字符模型：字符串匹配。
某些规范、格式、协议或其实现需要为给定字符串的大小指定限制。 这可能有许多原因，例如处理限制、内存限制、数据结构大小限制等。 由于长度限制通常涉及截断或限制文本大小，规范及其实现需要格外谨慎， 以确保文本不会损坏，并且所选择的限制不会使该功能对某些受众不可用。
除非存在特定的实际或技术限制，否则规范SHOULD NOT 对字符串长度施加限制。
如果规范指定长度限制，则它SHOULD 指定任何被截断的字符串都包含一个指示该字符串已被更改的标记，例如省略号。
规范或格式中可能需要长度限制的原因很多。最常见的原因是底层数据存在大小限制。 例如，数据库中可能存在固定大小的字段、数据包大小等实际边界，或与存储分配或效率相关的 其他实现细节。另一个常见原因是显示区域或可见输出的大小可能有限。
截断字符串时，必须决定在计算字符串大小时使用哪些单位。 在某些情况下，这超出了规范的控制范围，因为截断是出于某种预先确定的原因发生的。 但是，在可以选择的情况下，可以应用一些一般性指导。
如果需要视觉长度限制，请使用文本呈现或裁剪机制指定视觉截断，
例如 CSS text-overflow [css-overflow-4]，
这类机制不会更改字符串，并且会考虑文本呈现的复杂性。
规范有时试图通过使用视觉文本单元的数量作为可用可见空间的替代量来处理视觉限制。 这种限制可以有多种形式，例如限制一行中的字符数量，或试图让所有视觉文本单元具有相同的呈现宽度。 使用视觉文本单元比编码字符串中的码点数量或 码元数量更接近 这类任意限制。然而，文本显示的性质通常使这种努力无效。比例字体、复杂文字、样式、 无障碍功能以及许多其他因素都会使情况复杂化。几乎在所有情况下，视觉文本单元限制其实是在试图近似 像素宽度。实际测量限制需要显示上下文中的字体度量。它还可能受到本地设置（如无障碍设置）的影响。 在网页中，CSS text-overflow 属性可在不干扰文本内容的情况下提供视觉截断。 试图根据 Unicode 码点数量甚至 字素 簇数量来估算给定文本片段大小，基本上是徒劳的。
限制字符串最大允许存储长度的规范SHOULD按Unicode 码点指定该长度。
大多数限制实际上与存储限制有关，例如数据库字段大小或协议中的长度限制。 这类限制要么按 Unicode 中的码点表示， 要么按特定字符编码中的 码元（如字节）表示。 码点 提供最佳用户体验，因为所有 Unicode 码点都会被同等对待：如果文本在 40 个码点后截断， 所有语言和文字都有相同数量的码点可用。相比之下，当大小限制用码元表示时， 例如 UTF-8 中的字节，主要使用 ASCII 字母书写语言的用户，在给定大小限制下获得的字符 （码点）数量，会多于其语言主要由每个码点占 2、3 或 4 字节字符组成的用户。
在视觉文本单元中间截断， 例如在组合字符 序列中间截断，可能会改变剩余字符串的含义。
除了选择如何表达长度限制（码点 vs. 字节）之外，还存在选择截断边界的问题。 文本绝不能在码点中间被分割， 因为这会产生损坏的字符。文本也不应在字素 簇中间被分割，因为这会改变所显示字符的外观和含义。 这可能意味着需要移除额外的码点，以确保含义不受影响。
有时字符串长度限制由某些外部因素决定，例如数据库字段大小或其他地方指定的数据值所分配的字节数。 或者，由于某些实际设计原因（例如描述固定长度的面向字节的线缆协议），长度限制可能需要用 码元指定。 这类规范及其实现需要指出这种做法带来的额外复杂性，包括以下考虑事项。
此最佳实践同样适用于 UTF-16，UTF-16 使用 16 位码元，
而不仅适用于 UTF-8 等多字节编码。UTF-16 代理项对用于编码
U+10000 到 U+10FFFF 之间的Unicode 码
点，需要两个码元。
任意地在代理项对中间截断会导致已编码字符损坏。
与 [DOM] 交互的规范或 API 需要处理这样一个事实： 字符数据，包括 length、substringData、 insertData、deleteData 等操作，是使用 UTF-16 码元指定的， 而不是使用Unicode 码点。 这可能导致不适当的字符中间（码点）截断。
可存储在固定大小缓冲区中的码
点数量取决于字符编码形式及其
码元。
例如，UTF-8 使用每个字符 1 到 4 个字节来编码Unicode 码点。
因此，它的最大编码大小是四个码元。相比之下，UTF-16 使用 1 或 2 个 16 位码元。
因此，它的最大编码大小是两个码元。如果给定字符串至少应存储 50 个码点，则 UTF-8 字节中的长度限制应为
50 * 4，即 200 字节。UTF-16 中的长度限制应为
50 * 2，即 100 个 16 位码元（等同于 200 字节）。这样的限制保证
字符串始终可以存储至少 50 个码点，不过根据所用字符，在某些语言中可能能够存储更多字符。
选择长度限制时，请牢记 Unicode 中不同文字和语言的需求。如果文本大小限制按给定 字符编码中的 码元（如字节长度限制）设置， 则该限制需要考虑该字符编码对不同文字的相对效率。尤其是，UTF-8 是 [Unicode] 的多字节字符编码。UTF-8 每个码点使用 1 到 4 个字节， 具体取决于字符的Unicode 标量 值。
当文本字段的限制按字节计数时，该字段可存储的字符数量取决于所存储的字符。 为确保使用各种语言的用户不会处于不利地位，限制需要允许以该语言编码的合理数量字符。
如果规范允许或要求截断字符串，并且长度以码元表示， 字符 编码对于理解该限制的含义非常重要。如果限制以字节为单位，并允许遗留字符 编码，请注意，将 Unicode 数据转换为非 Unicode 编码可能导致数据丢失 （因为大多数遗留字符 编码只编码 Unicode 的一个子集）。
通过将多个字符串拼接在一起来创建自然语言文本值是一种国际化反模式。 语言在词序、数量、语法性或格、标点以及许多其他要求方面差异很大。因此，应避免要求或建议实现 从子字符串生成可供人阅读的消息。
当规范要求实现创建或生成将显示给用户的文本时， 该规范SHOULD向实现者提供指导，说明如何避免与文本方向相关的潜在问题。
API、协议或文档格式的规范有时要求实现创建或提供包含显示名称或描述的字段。 当这类字符串由单独部分组装而成时，由于Unicode 双向算法 [UAX9]处理组装后字符串的方式， 可能导致呈现或理解问题。在这种情况下，规范应指导实现者如何创建能够正确显示的值。
某些规范需要定义各实现如何构造文件名或文件路径。 一个挑战是构建在不同操作系统所用不同文件系统上都能一致工作的定义。 本节包含在定义文件名或文件路径限制时的一般指导。它基于 [EPUB-33] 中制定的要求，以及实现经验。
文件名SHOULD限制为 255 字节长度。
此限制与某些文件系统中的限制有关，最初是 MS-DOS，但也包括某些 Unix 文件系统， 以及依赖这些文件系统或吸收其限制的打包方案（如 PKZIP），其中对特定“路径元素” （包括目录名）的限制为 255 字节。
路径名SHOULD限制为 65535 字节长度。
此限制与 FAT32 或 NTFS 等文件系统中的限制有关，这些文件系统将路径长度限制为 UTF-16 字符编码中的 32760（32K）个码元。每个 UTF-16 码元占 16 位（即 2 字节）， 以字节测量时限制为 65,535。请注意，在 UTF-8 中限制为 64K字节的路径名 可能超过这些文件系统的路径长度限制，因为 UTF-8 是可变宽度编码。
文件名和路径名定义MUST NOT使用以下 Unicode 码点。
已知这些字符会导致与各种文件系统的互操作问题。 当内容互操作性很关键时，规范和实现应在文件命名方面格外谨慎。 受限字符列表旨在帮助避免一些已知问题区域，但并不能保证所有其他 Unicode 字符都受支持。
U+0022 QUOTATION MARKU+002A ASTERISKU+002F SOLIDUSU+003A COLONU+003C LESS-THAN SIGN
U+003E GREATER-THAN SIGNU+005C REVERSE SOLIDUS
U+007C VERTICAL LINE
U+007F DELU+0000...U+001FU+0080...U+009FU+E000...U+F8FFU+FFF0...U+FFFFU+F0000...U+FFFFFU+100000...U+10FFFFU+002E FULL STOP 作为
最后一个字符（请注意，这包括文件名 . 和 ..，它们
对许多文件系统具有特殊含义）应用程序经常需要组织信息或内容集合。这通常涉及对内容进行排序。 许多非文本数据类型（如数字或日期）可以使用内部数据表示轻松排序。 然而，对于文本信息，字符编码的性质以及用户对“字母顺序”的期望会带来一些额外复杂性。
一个关键选择是，文本数据排序是严格用于内部，还是结果将显示给用户。
需要程序内部、快速且确定性地排序文本，且排序结果不打算供人查看或交互的规范或实现SHOULD指定字符串按其字符串定义排序。对于标量值字符串（如 USVString 或许多 XML 过程）， 指定升序码点顺序。对于基于 UTF-16 的字符串类型（如 DOMString 或许多 JavaScript API 中的字符串类型），指定升序码元顺序。
存在两种潜在的内部排序序列：按 Unicode 码点排序，或按 UTF-16 码元排序。 对于任一种排序，所得列表都不会匹配任何特定的字母顺序或词典顺序。
当字符串作为码点序列存储和处理时，例如在 USVString 中，按码 点排序是有意义的。当字符串使用底层编码存储和处理时，例如在 DOMString 中，按码元 排序是有意义的。
这些排序顺序都不会对被比较的字符串应用任何类型的规范化。 这意味着一些看似等价的字符串会被比较为不同。更多信息请参见字符串匹配 [CHARMOD-NORM]。
需要处理用于显示给用户的自然语言文本排序的规范或应用面临一些额外复杂性。 Unicode 在Unicode 排序算法 [UTS10] 中定义了默认排序顺序， 然后对其进行定制，以满足特定语言、区域设置和文化的需求。
语言和文化在如何对文本排序，或如何使用其字母表或书写系统组织文本数据方面各不相同。
例如，德语使用者将字母 üU+00FC LATIN SMALL LETTER U WITH DIAERESIS 视为与字母
u 排序相近（实际上德语有两种排序序列，它们在该字母的具体处理上略有不同），
而丹麦语使用者将同一字母视为字母表中的独立字母，并将其排在字母 “y” 之后。
确定要为排序列表使用哪个区域设置可能取决于许多因素。例如，应用可能根据数据显示所在页面的本地化来排序值列表。 在其他情况下，根据 user-agent 的运行时区域设置排序，或根据传入 API 的某个参数排序，可能更合理。 重要的是要认识到，这一顺序可能因不同用户或不同系统而异。
这是本节中各项要求的列表，可用于自审。对于你的规范相关的所有要求，选择所在行的第一个复选框。 如果你的规范满足该要求，则选择第二个复选框。然后点击“为 GitHub 创建 markdown”按钮， 并将结果复制到 GitHub issue 列表中。请参见 更多详情。
关于在资源标识符中指定对非 ASCII 字符的支持， 情况较为复杂，因为至少有三个规范（URI [RFC3986]、IRI [RFC3987] 以及 [URL]） 定义了资源标识符及其序列化。WHATWG [URL] 规范试图通过记录浏览器和其他 user agent 的实际做法来解决这种复杂性。URL 规范声明的目标是取代这两个 RFC。
一般来说，Web 上的文档格式使用将非 ASCII 字符编码为纯文本的资源标识符， 也就是 “IRI”。诸如但不限于 HTTP [RFC9110]）之类的协议使用 将非 ASCII 字符通过百分号编码编码为字节序列的资源 标识符，也就是 “URI”。由于 [RFC3986] 没有指定任何特定的 字符编码用于将字符编码为字节， 百分号编码转义容易被误解。 为帮助解决这一问题，许多现代协议和规范期望资源标识符在将字符编码到线缆格式和协议支持的 ASCII 子集时， 使用 UTF-8 字符编码，完全如 IRI 所指定。
文档格式或协议需要支持包含非 ASCII 字符的资源标识符，因为在许多情况下， 给定资源的名称或标识符由用户输入生成。通常不应限制用户，也不应限制他们使用自己的语言来填写这些值的能力。
根据 [RFC3986] 中的定义，URI 引用 被限制为 ASCII 的一个子集，不能直接使用非 ASCII 字符。百分号 编码用于转义任意字节值。然而，百分号编码本身价值有限， 因为许多不同的遗留字符 编码可能被用来将给定字节序列解释为字符（或将给定字符序列编码为字节）。国际化资源标识符 （IRI）[RFC3987] 通过一种基于 [Unicode] 的 UTF-8 编码的统一方法，解决了资源标识符中 非 ASCII 字符编码和解释的问题。
虽然通常不建议额外限制，但如果考虑这样做，请查阅 [UAX31] 和 [CHARMOD-NORM] 以获得 进一步指导。
这是本节中各项要求的列表，可用于自审。对于你的规范相关的所有要求，选择所在行的第一个复选框。 如果你的规范满足该要求，则选择第二个复选框。然后点击“为 GitHub 创建 markdown”按钮， 并将结果复制到 GitHub issue 列表中。请参见 更多详情。
在标记中定义元素和属性
在标记中处理纯文本
定义标识符
U+D800 到 U+DFFF）或非字符码点出现在
标识符中。更多
U+0000 到 U+001F）和 C1
（U+0080 到 U+009F）控制字符出现在标识符中。更多
处理形式语言、文档格式、协议或 API 的规范通常需要定义标记、语法或 应用程序内部 标识符。本节中的最佳实践涵盖定义这些内容时的不同需求。
定义标记语言或基于给定标记语言的语法的规范，关注的是定义元素、属性及其值。 例如，[XML] DTD 定义特定文档类型中 有效的元素和属性。
定义给定文档格式、协议或 API 的规范，通常关注的是为保留关键字、字段名或允许值定义标识符。 其中许多是应用程序内部 标识符，其名称和值完全由规范定义。在某些情况下，规范会允许其中部分或全部成为用户提供的值， 可由用户填写或命名。
如果确实定义了包含用户可读内容的属性值，请提供一种方法， 用于独立于元素中包含的文本来指示该文本的方向和语言信息。
提供一个类似 span 的元素，可用于任何文本内容，以应用国际化所需的信息。
国际化信息可能包括语言和基方向元数据、语言的行内更改、双向文本行为变化、translate 标志等。
文档格式的一个常见特性是定义各种标识符。这包括保留关键字以及用户定义的值。 为促进互操作性，实现需要能够可靠且一致地匹配标识符值。关于这一问题的详细分析，请参见 字符模型：字符串匹配 [CHARMOD-NORM]。
定义应用程序 内部标识符（永不显示给用户，且始终用于应用程序或协议内部匹配或处理）的规范， 应将内容限制为 ASCII 的可打印子集。推荐使用 ASCII 不区分大小写匹配。
指定内容 限制，见 [CHARMOD-NORM]
有时规范需要定义一组内容作者会与之交互、或对各种最终用户有意义的标识符。 将允许字符集合限制为 ASCII 会阻碍可用性，特别是对于不使用拉丁文字或使用 ASCII 范围外字符的语言使用者。
当标识符对用户可见或潜在可见时，规范应允许使用非 ASCII Unicode 字符， 以确保所有语言的用户都能平等使用所得文档格式或协议。推荐区分大小写（即不进行大小写折叠）。
指定内容 限制，见 [CHARMOD-NORM]
如果应用程序 内部标识符不限于 ASCII，规范应定义允许用于有效标识符开头和组成部分的字符。
在新规范中定义标识符命名空间或标识符集合时，一个关键问题是处理文档格式解析中的组合标记和某些其他字符 （如连接符或双向控制）：需要特别关注如何对标识符进行“分词”（与周围文本分离）。 实现这一点的一种方式是限制允许开始标识符的字符范围，以确保普通文本处理不会干扰后续标识符匹配。
Unicode 标识符和模式语法 [UAX31] 提供了一个模型，尤其用于 Java 或 JavaScript 等编程语言。HTML 和 CSS 也为自定义标识符提供字符 范围定义，例如这个 EBNF [XML] 产生式：
PCENChar ::=
"-" | "." | [0-9] | "_" | [a-zA-Z] | #xB7 | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x37D] |
[#x37F-#x1FFF] | [#x200C-#x200D] | [#x203F-#x2040] | [#x2070-#x218F] | [#x2C00-#x2FEF] |
[#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]HTML 和 CSS 处理的定义方式是，在解析标识符和 token 时不会考虑 Unicode 字符属性 （例如给定字符是否为组合标记）。这允许标识符以组合字符开头且仍能可靠处理， 但纯文本编辑器可能不会以相同方式处理该值。
规范在定义标识符时，应谨慎处理空白。请注意，除 ASCII 字符 U+0020 SPACE 和 U+0009 TAB 外，还有 Unicode 水平空白字符。
为字段和值选择区域设置中立和文化中立的名称。
定义标识符（包括字段名和值）时，请选择尽可能文化中立的名称。例如，
优先使用 postalCode 而不是（美国特有的）ZIPCode，
或优先使用 givenName/familyName 而不是文化关联更强的 firstName/lastName。
某些规范需要为文档格式或协议中的给定字段定义值。当数据值与特定类型相关联时， 例如数字或日期，该字段的格式通常使用某种众所周知的模式定义，例如 [XMLSCHEMA11-2] 或 [JSON-SCHEMA]。
定义旨在供机器读取且不可本地化的字符串数据值的规范， 应使用不易与自然语言文本混淆的值。
许多协议、文档格式或数据结构为内部使用定义枚举值。这些值并不意味着直接对人可见。 有时为这些值赋予描述性名称（通常用英语）很有帮助，以便帮助使用规范、协议或 API 的用户， 或需要调试给定文档或交互的用户。在规范中分配这些值时，所选名称应显得像“代码”， 以便用户不会假定该值可以像自然语言文本一样显示。
不同群体采用了几种样式，使应用程序内部值看起来像“代码”。请选择最适合你的规范的样式。 这些包括：
U+005F LOW LINE）分隔。包含人类可读字符串的字段，尤其是描述性字符串，必须假定为自然语言字符串。 即便查看该字符串的用户预期是软件开发者，也是如此。必须能够确定文档或数据结构中每个此类字段的语言标签和字符串方向。
此类字段的常见名称包括 name、description、
title、message，偶尔也包括 value。
一个测试方法是：如果作为规范作者或用户，你不愿意把该字段内容写成
SNAKE_CASE_SHOUTED，那么该字段可能更适合被视为自然语言文本。
供人使用的字段应可本地化。
这可以采取多种形式。例如，规范或协议可能允许语言协商，并只返回最佳匹配的本地化字符串。 或者给定资源可能包含多种语言，供消费者选择。
字段名和其他枚举值应包装为可本地化的显示名称。
字段名和枚举值不是自然语言文本，即使这些名称看起来像纯文本并且可能被用户理解。 这些字段和值不应有关联的语言或方向元数据，并且在必要时，规范应指导实现者提供适当的本地化包装。
这是本节中各项要求的列表，可用于自审。对于你的规范相关的所有要求，选择所在行的第一个复选框。 如果你的规范满足该要求，则选择第二个复选框。然后点击“为 GitHub 创建 markdown”按钮， 并将结果复制到 GitHub issue 列表中。请参见 更多详情。
竖排文本
before 和 after
行位置。更多vertical-
值的竖排书写模式（仅这些值）应使用
[UTR50] 来应用字符的默认文本方向。
（这不适用于等同于 CSS 中 sideways- 的书写模式。）更多
sideways-lr 和 sideways-rl 的值，以允许横排文字文本的行进行垂直旋转。
UTR50 不适用于这些情况。更多
RTL/双向文本
文本方向变化时设置框定位坐标
逻辑属性（待定）
Ruby 文本标注
字体管理（待定）
下划线和上划线等文本装饰应允许线条避开墨迹。
应能够指定上划线和下划线与文本之间的距离。
对于某些文字，例如阿拉伯文，跳过墨迹的下划线等文本装饰可能并不适合， 这类文字更倾向于将下划线移得离基线更远。
应能够为日语、中文、韩语、蒙古语等语言竖排呈现文本。
竖排文本必须支持从 LTR（例如蒙古语）和 RTL（例如日语）的行推进方向。
默认情况下，在行从左到右堆叠的竖排文本中
（例如蒙古语），文本装饰、ruby 等应出现在与 CJK 竖排文本相同的一侧。
放置不应依赖 before 和 after
行位置。
书写模式应提供类似 CSS 中 sideways-lr 和 sideways-rl 的值，
以允许横排文字文本的行进行垂直旋转。UTR50 不适用于这些情况。
默认情况下，通常横排的文字的字形在竖排文本中应沿着一行排列， 使字符顶部朝向竖线右侧，但也应有机制允许它们以直立方向沿行向下推进。 这种机制应使用视觉文本单元（例如字素簇）作为 最小文本单元，但在必要时，应允许当音节簇涉及多个字素簇时将其视为一个单元。
竖排线中的直立阿拉伯文本应使用孤立字母形式， 并且文本顺序应自上而下阅读。
应能够让某些字符序列（尤其是数字）在竖排线中横向排列（纵中横）。
允许字母形状倾斜的规范SHOULD 根据特定语言的需求，提供字符向右或向左倾斜的能力。
框定位坐标必须考虑文本是横排还是竖排。
本地化用户界面或网页时，通常会为 RTL 和 LTR 版本创建镜像图像。
例如，包含英语内容的窗口左侧附近出现的框，如果内容是阿拉伯语或希伯来语，
很可能会出现在窗口右侧附近。除非有充分理由使用绝对几何位置，
否则最好能够根据当前上下文的基方向自动更改。实现这一点的一种方式是使用
start 和 end
等关键字，而不是 left 和 right
来指示位置。
当对连写文本中的连字应用透明度时， 不应暴露重叠部分，例如阿拉伯文、蒙古文和 N'Ko。
添加文本描边或阴影时，连写文字文本中的连字不应与相邻字母分离。
在横排和竖排书写模式中，应支持中文、日语、韩语和蒙古语文本中 基本文本旁的 “Ruby” 样式标注。
Ruby 实现应支持繁体中文的注音符号（bopomofo）ruby。
Ruby 实现应支持表格式内容模型（使 ruby 内容能够排列为近似
rb rb rt rt 的序列）。
Ruby 实现应能够使用显式元素表示 ruby 基文本，
例如 HTML 中的 rb 元素。
Ruby 实现应允许标注出现在基本文本的一侧或两侧。
HTML 中的 Ruby 标记专为中文、日语、韩语和蒙古语需求而设计， 不应作为通用的注释机制使用。
行高必须允许比英语更高的字符。
框大小必须允许翻译时文本扩展。
换行应考虑非拉丁文字所需的特殊规则。
各种非拉丁书写系统并不只是按词间空格换行。它们有必须遵守的额外规则。 例如
更多背景请参见 CSS Text Level 3 规范。 （如有需要，本教程 提供了更多示例。）
最好避免使用呈现性标记 b、i 或 u，因为它在不同书写系统之间
不具备互操作性，而且可能给本地化造成不必要的问题。此外，一些文字有自己的强调等原生方式，
这些方式不涉及粗体、斜体等，并且可能与其非常不同。
在 HTML 情况下，存在历史遗留问题，但除非你的规范也存在类似问题， 否则建议使用样式来确定文本的呈现，并且任何标记或标签都应允许通用语义方法。
关于 b 和 i 标签相关问题的说明，请参见
使用 <b> 和 <i>
元素。
这是本节中各项要求的列表，可用于自审。对于你的规范相关的所有要求，选择所在行的第一个复选框。 如果你的规范满足该要求，则选择第二个复选框。然后点击“为 GitHub 创建 markdown”按钮， 并将结果复制到 GitHub issue 列表中。请参见 更多详情。
处理受区域设置影响的值
处理时间
处理人名
处理数字
设计表单
用户输入（待定）
创建示例（待定）
本地化
支持语言和文化偏好的软件系统被称为国际化
系统。
国际化系统使用 API，基于用户偏好提供特定语言或文化的处理。
这些用户偏好通常称为区域设置
。有关通用国际化术语的更多信息，
请参见 Language Tags and Locale
Identifiers [LTLI]
定义数据格式时，使用区域设置中立的序列化形式。
机器可读且不特定于任何特定语言或文化的数据值，比使用众多不同文化表示之一的值更持久， 也更不容易被误解。日期、货币和数字等内容可能看起来相似，但在不同区域设置中含义不同。 例如，以字符串 4/7 表示的日期，根据用户偏好，可以被读作 4 月 7 日或 7 月 4 日。 类似地，€2,000 要么表示两千欧元，要么表示对两欧元的过度精确表示。 通过使用区域设置中立的格式，系统可以避免建立会随用户语言或位置而变化的特定交换规则。 当数据已经采用区域设置特定格式时，通过提供区域设置参数 （通常以语言标签形式） 明确区域设置和语言，可以让用户确定如何处理这些数据，或可能启用自动翻译服务。
最常见的数据序列化格式都是区域设置中立的。例如，[XMLSchema-2] 类型（如
xsd:integer 和 xsd:date）旨在用于区域设置中立的数据交换。
使用区域设置中立的表示，可以在无需复杂解析或避免误解的情况下准确处理数据值，
也允许以任何区域设置中数据消费者最舒适的格式呈现数据。例如，与其将 "€2000,00" 存储为字符串，
更强烈推荐交换如下数据结构：
…
"price" {
"value": 2000.00,
"currency": "EUR"
}
…定义日历和日期系统时，务必允许公元纪年之前的日期， 或至少定义最常见范围之外日期的处理。
定义时间或日期数据类型时，确保始终定义时区或与 UTC 的关系。
在日期和时间数据类型中允许闰秒。
当一分钟中的秒数允许从 0 到 60（即那一分钟有六十一秒）时， 这种情况偶尔会发生。
讨论日期和时间值时使用一致的术语。对时区无关的值使用 “floating” time。
将时区定义与时区偏移的定义分开。
使用 IANA 时区 ID 来标识时区。不要使用偏移或 LTO 作为时区代理。
使用单独字段标识时区。
定义“week”的规则时，允许应用文化特定规则。
例如，周末并不总是星期六/星期日；一周的第一天并不总是星期日 [或星期一或……]，等等。
定义年份中的周数规则时，允许应用文化特定规则。
允许使用非公历日历时，请注意 “month” 字段可到 13（undecimber）。
创建使用人名的应用程序（在 Web 表单、数据库、本体等中）的开发者， 往往不了解其他国家的人名可能有多大差异。他们构建表单或数据库的方式， 对外国用户作出了过多假设。本节提供处理世界各地人名的指南。
世界各地的人名在组成和组成部分顺序方面差异很大（参见世界各地的人名）。 如果你试图将一个人的姓名拆分成较小部分以存储到数据库中，然后之后又试图取回它们， 尤其是在需要某种重组时，这可能造成困难。困难包括理解一个人姓名的哪一部分属于哪个数据库字段 （特别是当姓名部分多于或少于数据库字段时），以及在从数据库取回某人的姓名用于实际用途时， 处理姓名部分的顺序。
如果正在设计一个表单或数据库，以接受来自不同背景的人名，你应问自己是否真的需要 为 given name 和 family name 等内容设置单独字段。这取决于你需要如何使用这些数据， 但显然，在可能的情况下，直接使用用户提供的全名会更简单。
请记住，一些文化中的姓名可能比你自己的姓名长得多。让字段足够长， 以便输入长姓名。也不要假设姓名一定超过一个字母。
尤其要避免按字节计数长度（参见4.2 选择 “字符串”的定义）——不要假设 UTF-8 中的四字符日语姓名能放入四个字节； 你很可能实际上需要 12 个字节。
本节中的指南适用于已经决定有必要拆分一个人的姓名以便存储或呈现的情况。
尽量避免使用 “first name” 和 “last name” 标签。考虑使用替代表达， 例如 “given name(s)” 和 “family name(s)”。
拆分 姓名的策略，见世界各地的人名。
差异 示例，见世界各地的人名。
使用 “first” 和 “last” 这些术语，可能会让通常先写 family name 再写 given names 的人感到困惑。 虽然对于面向美国用户的表单，使用 “first” 和 “last” 似乎可以接受， 但这些表单最终可能会被具有不同文化背景的人使用，无论是在美国境内还是可能在美国之外。
还要记住，在某些文化中这仍然存在问题，例如冰岛人，他们实际上没有 family name， 而是有 given name 和父名（见Given name and patronymic）。不过，除非进行高度本地化的定制，否则这可能是通用方案中我们能做到的最好方式。
例如，在某些情况下，你可能想识别姓名的某些部分，以便按字母顺序排序姓名列表， 或在联系他们时称呼他们等。
这个额外字段也有助于从很长的姓名组成部分列表中找到适当的称呼， 并处理昵称（例如，在泰国常用昵称称呼人）。
有时你可能选择单独字段，是因为你希望能够使用姓名的一部分直接称呼此人， 或指代他们。例如，当社交媒体应用提到 “David's contacts” 时。又或者是因为你想向他们发送 顶部带有其姓名的电子邮件。请注意，这里你不仅可能因姓名语法而遇到问题， 还必须考虑世界各地对正式程度的不同期望（并非所有人都乐意让陌生人直呼其 given name）。 例如在设置个人资料时，单独询问此人希望你如何称呼他们，可能更好。
例如，不要假设他们提供姓名的顺序会是 “given name” 后跟 “family name”， 也不要假设一个由多个词组成的姓名中，甚至可能识别出哪一部分适合这些类别， 哪些部分涉及完全不同的内容，例如父亲的名字、村名、氏族名等。
例如，v-card 和 h-card 的隐式 “n” 优化方法可能在处理中文姓名等情况时遇到困难。 输入表单在告诉人们如何指定其姓名时应尽可能清晰，以便捕获你认为需要的数据。
确实有人拥有只有一个字母的姓名。如果表单验证器拒绝接受他们的姓名， 并要求他们提供完整姓名，这些人就会遇到问题。如果你想鼓励人们不要使用首字母缩写， 也许应把它做成警告消息，而不是阻止表单提交。
在印度南部、马来西亚和印度尼西亚部分地区等文化中，很多人的姓名只有 given name， 没有父名。如果你要求 family name，可能会在这些文化中造成重大问题， 用户为了绕过表单，只能在 family name 字段中输入 "." 或 "Mr." 等垃圾数据。
这确保了 Dina Asher-Smith 和 Christopher O'Connell 等人的姓名能被正确处理。
请注意，撇号可能表现为 'U+0027 APOSTROPHE 或 ʼU+02BC MODIFIER LETTER APOSTROPHE，甚至可能是
’U+2019 RIGHT SINGLE QUOTATION MARK。连字符可能使用
-U+002D HYPHEN-MINUS 或 ‐U+2010 HYPHEN 表示，
或者在日本使用 ゠U+30A0 KATAKANA-HIRAGANA DOUBLE HYPHEN。
有些姓名（如 'McNamara'）包含不是首字母的大写字母；另一些（如 'van der Waals'） 包含不大写的词。表单应保留用户输入的大小写，而不应强制这类姓名始终或仅在每个词开头使用大写字母。
允许正确捕获 family name，例如 Gabriel García Márquez 的 family name（García Márquez），或 given name，例如 José María Olazábal 的 given name（family name 为 Olazábal）。
假设同一家庭成员共享相同的 family name 是错误的。西方有越来越多的人在婚后保留自己的姓名， 但在其他文化中，例如中国，这本就是常见做法。在一些国家，妻子可能会也可能不会采用丈夫的姓氏。
处理西班牙语姓名时，可能只有家庭中的孩子拥有相同的 family names， 但这些 family names 可能与父母双方都不同。Manuel Pérez Quiñones 的 apellidos （Pérez Quiñones）来自其父亲的 apellidos Pérez Rodríguez 和其母亲的 apellidos Quiñones Alamo。后来，他追求一位 apellidos 为 Padilla Falto 的女孩。 他们结婚后，她的 apellidos 变为 Padilla de Pérez。他们的孩子被称为 Pérez Padilla，依此类推。
你也不应简单假设姓名采纳一定是从丈夫到妻子。有时男性会在婚后采用妻子的姓氏。 在这些情况下，表单使用 “Previous name” 可能比 “Maiden name” 或 “née” 更好。
你可能需要同时存储拉丁文字和本族文字形式的姓名； 在这种情况下，需要让用户分别提交本族文字形式和仅拉丁文字形式的姓名。
字符支持的 影响，见世界各地的人名。
差异 示例，见世界各地的人名。
是否需要多个字段，在一定程度上取决于你收集人们姓名的目的以及你打算如何使用它们。
例如，日本用户可能需要以日语音节文字提供转写，而不是/或除了表意形式之外提供转写。 这个字段用于排序日语姓名，也允许查看姓名的人检查其读音。
在试图强制使用真实姓名时，不要阻止不常见或意料之外的姓名。
不难找到人们因为自己的姓名不符合开发者预期而被阻止使用某项服务的例子。 如果你计划强制使用真实姓名，就需要提供一种机制，让姓名罕见或结构出乎意料的人能够验证其真实姓名。
在包含人物姓名示例的标准和标准相关文档中，使用多样化姓名来反映全球受众。 避免偏向特定地区的姓名。
许多规范提供示例，例如用户故事或用例，并使用人名来增强叙事。 一些组织甚至有惯例，例如安全规范使用 "Alice" 和 "Bob" 这类姓名， 以提供一定程度的一致性。构建系统和服务时，包容性应是一个重要目标， 因此建议在形成示例时使用全球多样化姓名。这有助于确保我们用技术代表全球用户社区， 并使规范对全球用户显得更相关。
尝试选择代表世界不同地区人群的姓名，而不仅仅是少数欧洲来源的姓名。 请注意，选择包含非 ASCII 字符的姓名，有助于提醒实现者 Unicode 支持和其他国际化关注点适用于其用户。
任何姓名集合在处理文化和性别相关问题时都不可能完全无偏。 为帮助规范作者创建更具包容性的示例，本文档提供了一组来自多种文化的姓名。 这些姓名大致按地区组织，通常指示国家或语言。请注意，即使在这些地区内部， 对人名的处理也存在相当多样的影响和实践。姓名也按其文化性别关联划分，以协助规范作者编写示例， 尽管许多姓名并不特定于任何特定性别。
将其他文化中的人名插入英文示例时，也会受到世界各地姓名使用方式差异很大的影响。 例如，一些文化期望在 given name 之外使用父名/母名；或者一些文化偏好更正式的称呼 （例如 "Herr Dürer" 而不是非正式的 "Albrecht"）。
中国人几乎从不在不包含 family name 的情况下使用 given name。 用中文编写示例时，可能会看到类似 路人甲 的表达 （意思是 Person A，使用汉字“天干”序数，参见现成计数器样式）， 而不是一个“示例姓名”。使用示例时，会同时包含 family name 和 given name。 请记住，在中文中 family name 位于 given name 之前。
在日语中，与正式程度相关的选择很复杂。一个人可能在非常非正式的情境下被用
given name 称呼（Hiroshi），但通常会用 family name 加上（除非粗鲁）头衔或后缀称呼，
例如 -san 或 -sama（如 Tanaka-san）。
也会使用其他后缀或头衔，例如 senpai 或 sensei（用于资深或备受尊敬的人）
或 shi（当不熟悉该人时）。因此，英文示例中写作
Suppose Hiroki wants to set up a... 的内容，如果写成
Suppose Tanaka-san wants to set up a...，可能在文化上更合适。
下表由国际化工作组编制。欢迎贡献以及添加或更正建议。
这个姓名集合的目的是帮助通常为英语受众编写规范的规范作者。 该集合主要由 given names 组成，并在必要时转写为拉丁文字。 这些姓名也以非正式方式呈现（"Alice" 而不是 "Ms. Jones"）， 尽管在许多这些文化中姓名并非如此使用。翻译规范时，应作出适合目标受众的调整。
当姓名取自非拉丁文字语言或文化时，也提供非拉丁表示，以提醒姓名绝不限于拉丁文字， 或用于你想包含非拉丁文字示例的情况。
点击表头行中的 △ 或 ▽ 箭头可对此表排序。
| 姓名 △▽ | 本族文字 △▽ | 性别 △▽ | 地区和注释 △▽ | 语言 △▽ |
|---|---|---|---|---|
| Akamu | m | 大洋洲；波利尼西亚；夏威夷姓名 | haw | |
| Alinta | f | 大洋洲；澳大利亚原住民姓名 | nys | |
| Amélie | f | 欧洲；法国 | fr | |
| An | 杏 | f | 东亚；日本 | ja |
| Aoi | 葵; 蒼; 碧 | f, m | 东亚；日本 | ja |
| Aroha | f | 大洋洲；毛利 | mi | |
| Åsa | f | 欧洲；瑞典 | sv | |
| Asahi | 朝陽 | m | 东亚；日本 | ja |
| Atlahua | m | 拉丁美洲；纳瓦特尔姓名 | nah | |
| Beata | f | 欧洲；多个国家 | it, de, pl, sv, etc. | |
| Chanda | चंदा | f | 南亚；原出自梵语 | sa |
| Chirapathi | சிரபதி | f | 南亚；泰米尔 | ta |
| Citlali | f | 拉丁美洲；纳瓦特尔 | nah | |
| Coen | m | 欧洲；荷兰；也见于大洋洲（澳大利亚原住民）或希伯来姓名 | nl, he, nys | |
| Daisho | 大翔 | m | 东亚；日本 | ja |
| Dara | f | 西亚；欧洲；Türkiye | tr | |
| Eva | Е́ва | f | 欧洲；俄罗斯 | ru |
| Faheem | فهيم | m | 西亚；阿拉伯语 | ar |
| Fátima | فَاطِمَة | f | 西亚；阿拉伯语；也以拉丁文字用于若干欧洲文化 | ar |
| Genet | ገነት | f | 非洲；埃塞俄比亚 | am |
| Haruto | 陽翔 | m | 东亚；日本 | ja |
| Haukea | f | 大洋洲；波利尼西亚；夏威夷姓名 | haw | |
| Himari | 陽葵 | f | 东亚；日本 | ja |
| Hina | 陽菜 | f | 东亚；日本 | ja |
| Hīnano | m | 大洋洲；波利尼西亚；塔希提 | ty | |
| Hua | 李华 | m | 东亚；中国 | zh-Hans |
| Iakopo | m | 大洋洲；萨摩亚 | sm | |
| Ilango | இளங்கோ | m | 南亚；泰米尔 | ta |
| Irepani | m | 拉丁美洲；普雷佩查语 | tsz | |
| Işık | f | 西亚；欧洲；Türkiye | tr | |
| Işıtan | m | 西亚；欧洲；Türkiye | tr | |
| Itsuki | 樹 | m | 东亚；日本 | ja |
| Jarra, Jarrah, Cerrah | جراح | m | 西亚；阿拉伯语 | ar, tr |
| Jean-François | m | 欧洲；法语 | fr | |
| João | m | 拉丁美洲；巴西 | pt-BR | |
| Júlía | f | 欧洲；冰岛 | is | |
| Kai | f, m | 大洋洲；澳大利亚；出现在许多语言中，是一个很好的通用示例 | aus, sm | |
| Khaliun | f, m | 东亚；蒙古 | mn | |
| Kylie | f | 大洋洲；澳大利亚原住民姓名 | aus | |
| Lani | f | 大洋洲；菲律宾 | fil | |
| Lei | 李雷 | m | 东亚；中国 | zh-Hans |
| Livia | f | 欧洲，拉丁美洲 | es | |
| Lowanna | f | 大洋洲；澳大利亚原住民 | aus | |
| Lucas | m | 拉丁美洲 | es | |
| Maevarau | m | 大洋洲；萨摩亚 | sm | |
| Mahmut | m | 西亚；欧洲；Türkiye | tr | |
| Martina | f | 拉丁美洲 | es | |
| Mei | 芽依 (ja); 梅
(zh) |
f | 东亚；中国；日本 | ja, zh |
| Minato | 湊 | m | 东亚；日本 | ja |
| Mio | 澪 | f | 东亚；日本 | ja |
| Miriam | מרים | f | 西亚；希伯来语 | he |
| Müge | f | 西亚；欧洲；Türkiye | tr | |
| Muhammad | محمد | m | 西亚；阿拉伯语；有许多变体和语言。 | ar |
| Ngatemi | f | 大洋洲；印度尼西亚 | id, ms | |
| Onosaʻi | f | 大洋洲；萨摩亚 | sm | |
| Potira | f | 拉丁美洲；巴西；原住民姓名 | gn | |
| Qiàn | 倩 | f | 东亚；中国 | zh-Hans |
| Rattiya | รัตติยา | f | 东南亚；泰国 | th |
| Ren | 蓮 | m | 东亚；日本 | ja |
| Rin | 凛 | f | 东亚；日本 | ja |
| Ritthichai | ฤทธิชัย | m | 东南亚；泰国 | th |
| Santiago | m | 拉丁美洲 | es | |
| Senthil | செந்தில் | m | 南亚；泰米尔 | ta |
| Sione | m | 大洋洲；汤加 | to | |
| Slobodan | Слободан | m | 欧洲；塞尔维亚语 | sr |
| Sofia | f | 欧洲；拉丁美洲 | es | |
| Tahnee | f | 大洋洲；澳大利亚原住民 | aus | |
| Tamizhachi | தமிழச்சி | f | 南亚；泰米尔 | ta |
| Temuera | m | 大洋洲；波利尼西亚 | sm | |
| Thị Anh | f | 东南亚；越南 | vi-VN | |
| Tuulikki | f | 欧洲；芬兰 | fi | |
| Uriel | אוּרִיאֵל | m | 西亚；希伯来语 | he |
| Văn Hoa | m | 东南亚；越南 | vi-VN | |
| Vasa | m | 大洋洲；萨摩亚；欧洲；Vasilije/Василије 的小称形式 | sm, hr, sr | |
| Vassilios | Βασίλειος | m | 欧洲；希腊语 | el |
| Voula | Βούλα | f | 欧洲；希腊语 | el |
| Wafaa | وفاء | f | 西亚；阿拉伯语 | ar |
| Wissam | وسام | m | 西亚；阿拉伯语 | ar |
| Xiaoxia | 晓霞 | f | 东亚；中国 | zh-Hans |
| Xóchitl | f | 拉丁美洲；纳瓦特尔 | nah | |
| Yevdokia | Евдокия | f | 欧洲；俄罗斯 | ru |
| Yevgeny | Евгений | m | 欧洲；俄罗斯 | ru |
| Zafirah | زفره | f | 西亚；阿拉伯语 | ar |
解析用户输入的数值时，允许数字形状变化（非 ASCII 数字）。
格式化用于显示的数值时，允许文化敏感的显示， 包括使用非 ASCII 数字（数字形状变化）。
定义自动为显示给用户的项目递增标号的功能时 （例如创建编号列表），允许标签的本地化呈现，以及各种计数/列表系统或样式。
相关示例可见于 CSS Counter Styles [css-counter-styles-3]，尤其是配套的 Ready-made Counter Styles [predefined-counter-styles]。
定义电子邮件字段验证时，允许 EAI（smtputf8）名称。
本地化 [LTLI] 使 用户能够以其选择的语言和区域设置使用软件。协议和文档格式的规范需要考虑如何提供最终用户期望的语言和格式。
自然语言数据值需要语言和基方向，以确保正确呈现， 即使没有提供本地化消息。这包括 API 或协议中任何人类可读的错误消息或其他内部消息。 另请参见 [STRING-META]。
规范MAY为 API 或协议中的消息或错误定义 特定默认语言。
规范不需要要求以所有可能或所有可用的区域设置返回消息。 只要能够本地化最终用户的客户体验就足够了。实现可以选择支持哪些语言或区域设置。
协议、API 和文档格式有时会提供一个字段，用于以字符串形式将服务中的人类可读错误或异常消息传递给调用方。 一般来说，并且如上文所示，任何传达人类可读消息或人类可读内容的自然语言文本， 都需要关联语言和方向元数据。缺少这种元数据时，文本的处理或显示可能受到影响。
规范作者提供错误或异常消息的意图，通常是向软件开发者传达调试信息。 规范作者有时会假设最终用户看不到错误或异常消息；软件开发者会更喜欢这些消息不本地化， 或以特定语言（通常是英语）出现；或者认为存在其他“实际原因”，使错误消息本地化可能成为障碍。 例如，有一些轶事称，开发者发现用错误消息中（通常晦涩）的文本在 Web 上搜索更容易， 因为消息本身不足以很好地解释问题。搜索这些文本可能产生使用开发者偏好语言的结果， 并且更有帮助。
错误消息就是消息，它们是面向人的，而不是面向机器的。在许多情况下， 错误消息包含关于出了什么问题的所有附加信息；在某些情况下，调用方还必须向实际最终用户显示该消息， 因为没有其他方式向调用方传达如何修复问题（“你的信用卡已过期”；“值 10484977 太大” [哎呀，忘了小数点]；等等）。这些类型消息的本地化实际上是一件好事， 在某些应用中甚至可能是强制性的。
API 和协议SHOULD为错误提供与语言无关的标识符。
例如，HTTP 结果代码（如熟悉的 404）可帮助用户交流他们收到的错误，
或查找翻译。
提供自然语言错误消息字段时，这些字段SHOULD是可选的，并且SHOULD包含语言 和方向元数据。
提供自然语言错误消息字段时，这些字段在可能的情况下SHOULD匹配为请求协商得到的用户界面语言。
以下概述了自上次发布以来的实质性更改，但随着材料的发展，它仍然可能发生显著变化。 这不应成为不使用本文档的理由。它目前包含的内容是有用的，任何不足都可以报告或讨论。
更多详细信息请参见 github 提交日志。
感谢 Addison Phillips 帮助审查旧审查中的建议。
其他通过审查或 issue 作出贡献的人包括 Steve Atkin、 Andrew Cunningham、 Martin Dürst、 Asmus Freytag、 John Klensin、 Tomer Mahlin、 Chaals McCathieNevile、 Florian Rivoal、 Najib Tounsi。 关于区域设置中立表示的一些材料改编自 [DWBP]。
引用于：