面向规范开发者的国际化最佳实践
关于本文档的更多详情
Copyright © 2014-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2014-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
本文档提供了在制定规范时与国际化相关的考虑事项清单。大多数清单项都指向其他文档中的详细支持信息。如果此类 信息尚不存在，可以暂时放在本文档中。随着新内容的加入以及根据 经验和讨论对现有内容进行修改，本文档中的信息将定期变化。
本节描述本文档在发布时的状态。当前的 W3C 出版物列表以及本技术报告的最新修订版可在 W3C 标准和草案 索引中找到。
本文档为规范开发者提供有关如何纳入国际化使用要求的建议。目前此处提供的内容预计可以立即发挥作用，但仍然是 早期草案，文档内容尚不稳定；随着评审和讨论中应用的知识逐渐凝练为指南，本文档将不断扩充。
本文档由国际化 工作组使用 说明 标准轨道发布为工作组说明。
本工作组说明已获得 国际化工作组认可，但未获得 W3C 本身或其 成员的认可。
W3C 专利 政策 不对本文档施加任何许可要求或承诺。
本文档受 2025 年 8 月 18 日的 W3C 流程文档管辖。
规范开发者需要相关建议，以确保他们制定的内容能够适用于全球各地的社群。
国际化（i18n）工作组尝试通过审查规范和参与讨论来协助各工作组。然而，这类介入往往比理想时间更晚， 或者意味着 i18n 工作组不得不向与其互动的每个工作组重复相同的信息。
如果规范开发者能够访问一份最佳实践检查清单，并在需要时通过该清单找到解释、示例和理由， 情况会更好。这样，开发者就能从工作的最早阶段开始将这些知识纳入其中，从而减少 i18n 工作组 审查其规范时所需的返工。
本文档包含一份初步的检查清单，并指向可以找到相关建议的解释、示例和理由的位置。 如果没有其他此类位置， 则会将这些补充信息添加到本文档中。本文档也可用于发展和整理想法。
本文档中的指南并非旨在成为严格且不可变通的要求。如果你不理解这些指南或不同意这些指南时， 能够联系国际化工作组讨论应如何处理，那么本文档就已经实现了其目的的重要部分。
在本文档中，术语自然语言通常 用于指文档或协议中供人类阅读的部分。术语可本地化 文本用于指形式语言、协议语法等内容中的自然语言内容，以区别于语法内容或用户提供的值。有关国际化工作组使用的这些术语和 其他术语的定义，请参阅 [I18N-GLOSSARY]。
本页面提供了一项检查清单功能，可帮助你审查规范的国际化情况。审查结果应发布到 GitHub 议题中。
对于与你的规范相关的每个章节，请执行以下步骤：
对国际化注意事项章节进行的所有新增或修改都必须由国际化（i18n）工作组审查。
如果创建国际化注意事项章节，则该章节的标题必须为国际化注意事项或 国际化（i18n）注意事项。
规范不必包含专门的章节或附录来描述其国际化注意事项。通常，国际化工作组更希望 与语言、区域或文化差异、支持或适配有关的信息出现在规范正文中，并与相关功能 紧密关联。
不过，在少数情况下，你可以考虑提供此类章节。在以下情况下，可以考虑 加入国际化注意事项章节：
如果决定创建国际化注意事项章节，该章节通常会作为 附录。不过，它相对于规范其他部分或其他附录的顺序和位置由你决定。
如果决定创建国际化注意事项章节，则需要在提交给国际化工作组的 横向审查请求中提及该章节。审查请求模板中包含一个 复选框，可让你轻松完成此操作。
这是本节要求的汇总列表，可用于自我审查。对于与你的规范相关的所有要求， 选择相应行中的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后单击“为 GitHub 创建 Markdown”按钮，并将结果复制到 GitHub 议题列表中。请参阅更多详细信息。
语言基础
lang 和 XML xml:lang
语言属性标识文本处理语言，而不是创建
新属性或机制。更多lang 和
XML xml:lang 语言属性；当这些属性表示元数据
（用于指明资源的预期用途，而不是某个特定文本范围的语言）时，应使用
其他属性。更多定义语言值
声明语言
识别字符串的语言
zxx（“无
语言内容”）与每个字符串值关联。更多und
（“未确定”）与每个字符串关联。规范可以
在适当情况下允许使用启发式方法，或根据其他字段值推断语言。更多
U+E0000 至
U+E007F）进行语言识别。更多
@context 和内置的 @language 属性作为
文档级默认值。更多
i18n
命名空间功能。更多i18n 命名空间不可用或不适合使用，
规范应当要求使用 [JSON-LD]
普通字符串字面量，为自然语言值提供特定于字符串的语言
信息。更多
检测语言
文本会根据其所用语言以不同方式呈现或处理。例如，语言发生变化时需要提示屏幕阅读器， 拼写检查器也应能感知语言。呈现文本时，需要了解其语言，才能应用正确的字体、断字、 换行、大小写转换及其他功能。
例如，雪、刃、直、令、垔等表意字符在使用日文字体和中文字体时存在细微但重要的差异， 因此向用户呈现文本时，不应对日文文本使用中文字体，反之亦然。
给定资源的语言信息可以用于两个主要目的：文本处理，或声明资源的预期用途。下面将说明两者的区别。
指定文本处理 语言时，你是在声明某个特定文本范围实际使用的 语言，从而使语音浏览器、拼写检查器、样式处理器、 断字器等操作文本的用户代理或应用程序能够对相关文本应用适当的规则。 因此，我们必然是在讨论将单一语言与特定文本范围关联。
通常会将文本处理语言表示为处理整个资源时使用的默认语言， 但也可能需要指明资源内部语言发生变化的位置。
为标识某段文本的文本处理语言，HTML 提供了lang 属性，而 XML 提供了可在所有 XML 格式中使用的 xml:lang。对于相关的标记格式，继续使用
这些属性非常有用，因为内容作者以及 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 是互联网和 Web 标准（以及许多其他场景）使用的语言标签系统。 它定义了一种使用 IANA 注册表中的子标签组成字符串的方法， 该字符串用于描述内容的语言。注册表中的子标签主要基于用于识别语言、文字、区域和国家的 ISO 和联合国标准，并与这些标准保持严格兼容。BCP 47 也是Unicode 区域设置的基础。
有关 BCP 47 主要功能的概述，请参阅HTML 和 XML 中的语言标签。
应引用 BCP 47，而不是其组成部分，例如 RFC 5646 或 RFC 4647。
创建 BCP 47 的名称和链接，是为了对用于识别语言的标签定义提供不会变化的引用。 RFC 1766、3066 和 4646 是之前的（已被取代的）版本。 BCP 47 的当前版本由两个 RFC 组成：5646 和 4647。
应明确说明你期望语言标签达到何种一致性级别：BCP 47 定义了两个一致性级别，即“有效”和“格式正确”。
格式正确的 BCP 47 语言标签遵循语言标签定义的语法： 实现需要检查每个语言标签是否由连字符分隔的子标签组成；每个子标签的 长度和内容（字母、数字或特定组合）取决于其在标签中的位置。 有效的 BCP 47 语言标签不仅格式正确，还要确保 只使用 IANA 子标签注册表中列出的子标签。请注意，IANA 子标签注册表会频繁更新并添加新的子标签。
规范可以要求实现检查语言标签是否“有效”， 但在大多数情况下，应只要求语言标签“格式正确”。
大多数规范都是语言元数据的二级使用者——它们使用文档格式中已提供的数据 （HTML lang、XML xml:lang，或文档格式的语言字段或属性）。
通常，大多数规范关注的是选择资源（例如拼写检查器、分词器、 字体等）或进行匹配（例如选择显示哪个字符串），而不直接关心 语言标签的内容。无效但格式正确的标签只是什么都匹配不到， 而回退机制通常会提供某种适当的行为。
可能存在某些规范确实需要在实现级别检查有效性的情况。 在这种情况下，必须规定标签无法通过有效性检查时的结果（应用程序是否应终止、 警告用户等）。注册表规模很大且会随时间变化，这也是一个问题， 因此每个实现都依赖特定的注册表版本。随时间发生的变化通常很小， 但如果随机的过时规范实现拒绝后来变得有效的语言标签，真实用户将遇到互操作性问题。
此外，BCP 47 还具有定义附加子标签序列的扩展机制。例如，一个扩展 [RFC6067]（使用单例 -u 的 Unicode 区域设置）通常用于控制 JavaScript 的国际化功能，也有其他用途。验证这些附加子标签很可能超出 大多数规范的范围。
规范应要求内容和内容作者使用“有效”的语言标签。
关于语言标签的规范性措辞，可能在内容要求和实现要求之间有所不同。 规范作者需要仔细考虑其规范需要哪些一致性要求和测试，以及实现需要执行哪些操作。 一种解决方案是在规范上要求内容作者使用“有效”的语言标签， 但只要求实现检查语言标签是否“格式正确”。
过去，一些用于提供语言标签中子标签的标准无法免费或公开获得， 因此某些规范会提供代码列表，以帮助确保互操作性。现在已不再需要这样做。 作为 BCP 47 的一部分，IANA 维护语言子标签注册表，它是一个公开可用且机器可读的 有效子标签列表，可用于构造语言标签。该注册表以底层标准为基础， 包括 ISO 639 的各个部分（639-1、639-2、639-3 等）、ISO 15924 文字代码以及 ISO 3166 和联合国 M.49 区域代码。与互联网上的其他列表相比，该注册表得到积极维护、 保持稳定且内容全面。借助这些标准维护者的帮助和参与，每种子标签类型都与其上游标准保持同步， 因此自行提取或创建代码列表，或引用其他位置的列表，可能会导致维护问题或混淆。
自行创建完整语言标签列表，会不必要地限制可以使用的语言。 此外，区域设置数据始终在扩展，因此描述当前支持情况的列表将来会变得过时。 限制用户可使用的标签或子标签，与我们提供普遍访问能力的目标相冲突。
这里讨论的是包含结构化文本的独立数据单元。例如， 整个 HTML 页面、XML 文档、JSON 文件、WebVTT 脚本、注释等。
规范应说明如何为整个资源定义默认文本处理 语言。
在一个位置标识整个资源的语言，或至少标识其默认语言，通常可以避免许多麻烦。
例如，在 HTML 文件中，可以通过在 html 元素上设置 lang 属性来完成此操作。
除非被明确覆盖，否则资源中的内容应继承 在资源级别声明的文本处理语言。
应考虑是否有必要分别使用不同声明来指明 文本处理语言以及有关资源预期用途的元数据。
在许多情况下，资源只包含一种语言的文本；在更多情况下， 被声明为文本处理默认语言的语言，与描述整个资源的元数据语言相同。 在这种情况下，使用单一声明是合理的。
不过，如果单一声明引用了多种语言，并且没有办法确定应将哪一种语言 用作文本处理默认语言，就会产生问题。
如果资源只有一个语言声明，且该声明包含多个 语言标签值，则必须能够确定该资源的默认文本处理 语言。
这里使用术语块和/或分块，指整个资源中的一种结构 组件，它将内容组合在一起，并将其与相邻内容分隔开。 一个块与另一个块之间的边界，相当于文本中的段落或章节边界， 或文件中的离散数据项。
例如，它可以指 XML 或 HTML 中的块或段落、JSON 中的对象声明、 WebVTT 中的提示、CSV 文件中的一行等。与此相对的是内联内容， 它描述段落、句子等内部的某个范围。
要判断规范中定义的哪些结构与这些要求相关，可能需要进行一些考虑， 并且会取决于所涉及的数据格式。
默认情况下，内容块应继承为整个资源设置的任何文本处理语言。
有关默认文本处理语言信息的指导，请参阅2.1 语言基础。
应当能够指明语言发生变化的内容块中的语言变化。
本节讨论需要为段落或字符串中间的一段字符提供的信息。
应当能够指明语言发生变化的内联文本范围所使用的语言。
如果语言切换会影响对内容的操作，例如拼写检查、呈现、 样式设置、语音生成、翻译、信息检索等，则需要 指明受影响的文本范围，并标识该内容的语言。
本节中的信息正在数据格式中的语言和方向元数据要求 [STRING-META] 中制定。 该文档仍在编写中，因此这些指南可能随时发生变化。
Web 上的数据交换应尽可能使用区域设置中立的标准化 格式。不过，Web 上的某些数据必然由供人类查看的自然语言信息组成。 为正确显示，此类自然语言信息 依赖语言和方向元数据，并能从中受益。除了支持 Unicode 外，提供用于包含和指定文本范围的基本方向及自然语言的机制， 是为 Web 开发新格式和技术时需要考虑的关键国际化事项之一。
国际化工作组在每份规范中都会检查的最基本最佳实践是：
字符串格式的语言和方向元数据工作仍在进行中。规范 可能需要加入说明，指出未来采用元数据的必要性。以下是一个 原型：
字段 {fieldname} 应遵循
Web 上的字符串：语言和方向元数据 [STRING-META] 中的最佳实践。
这包括使用未来可能出现的、与报告字符串
语言和方向元数据有关的任何标准。
各个数据值的语言或方向可能与同一数据文件或文档中的其他值不同。 为每个可本地化文本字段提供直接关联的元数据值， 可以适当地覆盖元数据，并帮助应用程序在组合、提取、转发或 以其他方式处理每个数据字段时实现自动化。
规范可以定义一种机制，为给定资源中的所有 字符串提供默认语言和默认字符串方向。 不过，规范不得假定资源范围的默认值已经足够。 即使存在资源范围的设置，也必须能够使用字符串特定的元数据覆盖该默认值。
许多文档包含单一语言的数据。提供一种指明预期语言受众的方式， 例如在标头中指明，可以减少文档的整体大小和复杂性。不过，覆盖特定字符串值的能力 仍然很重要，因为某些字符串可能无法使用文档语言提供， 或者其基本方向可能与文档整体中其他可本地化文本值的默认方向 不一致。
应规定，在没有其他信息的情况下，默认方向和 默认语言均为未知。
规范不应为无法包含自然语言文本的字段 指定或要求使用语言元数据。
Web 上的文档格式由文本组成。在大多数情况下，给定文档格式中的数据值 旨在具有代表性和特定含义，而不只是任意字符串。某个数据值 由英文关键字组成，并不意味着该数据值就是用于显示为文本的自然语言字符串 （也就是说，该值并不是可本地化文本）。 此类数据值属于文档的语法内容： 它们不仅不需要语言和方向元数据，也不应与此类元数据关联。
对于已知包含可本地化文本，但
底层格式无法提供语言元数据的字符串值和字符串字段，
规范应当规定内容的语言未知，并建议将语言标签
und（“未确定”）与每个
字符串关联。规范可以在适当情况下允许使用启发式方法，
或根据其他字段值推断语言。
某些字符串值依赖现有协议或格式，或由它们定义。这些字符串通常 不与语言或方向元数据关联，也不提供此类元数据。例如，许多 HTTP 标头在定义其内容时， 将内容视为并非可本地化文本， 即使其中某些内容包含自然语言文本。使用方规范有时需要依赖此类字符串， 或定义一种描述其中某个字符串的格式。在这些情况下，规范的数据结构或文档格式中 不会有可供使用者与该字符串关联的 语言或方向元数据，并且规范的数据结构或文档格式提供的任何元数据 （当其充当生成者时） 都不会通过底层格式序列化。
规范不应使用 Unicode“语言标签”
字符（码位 U+E0000 至 U+E007F）进行语言识别。
Unicode“语言标签”字符已不推荐用作语言标签，并且在文档格式和传输协议中， 它们并不是解决语言元数据问题的良好方案，原因有很多。 规范作者应避免重新赋予这些字符用途，也不应尝试基于这些字符建立 传输语言信息的新机制。
生成者有时 需要为给定内容项或数据记录提供本地化值。有时，这通过语言 协商完成，该协商发生在生成者与使用者之间。 随后，生成者 使用协商得到的语言选择返回的内容，从而完成本地化。
在其他情况下，内容项的本地化通过以下方式完成：由生成者返回该内容项的多种语言 表示形式，再由使用者选择要显示的值。 后一种过程称为语言索引。有关语言索引的更多信息，请参阅 [STRING-META] 中的本地化 注意事项。
[JSON-LD] 提供了多种机制，可满足本节中的部分 最佳实践：
本文档中的最佳实践以及Web 上的字符串：语言和方向 元数据 [STRING-META] 都要求 自然语言内容与语言元数据关联。在 Web 上，“语言元数据”指 语言标签， 特别是由 [BCP47] 定义的语言标签。规范或应用程序 有时需要根据语言或用户的区域设置 选择或筛选内容。
[BCP47] 由两个 RFC 组成。
第一个是 [RFC5646]，它定义了语言标签的语法、处理方式和构成方式， 以及列出有效子标签的IANA 语言子标签注册表 的内容和维护方式。
第二个是 [RFC4647]，它定义了语言范围、语言 优先级列表，以及应用程序在使用语言标签进行选择或筛选时可以使用 （或由规范指定）的几种常见匹配方案。
Unicode [CLDR] 定义了其他算法、 规则和流程，用于在语言标签作为区域设置标识符使用时 管理和匹配语言标签。
语言标签存在两种不同的匹配类型： 查找和筛选。
查找 [RFC4647] 将由基本语言范围组成的 语言优先级列表 与一组语言 标签进行匹配，以找到与指定范围最匹配的唯一一个语言标签。 也就是说，当结果需要是恰好一个最符合用户需求的项目或值 （或适当的默认值）时，应使用查找。查找的示例包括：
筛选将语言优先级列表 与一组语言 标签进行匹配，以产生零个或多个匹配项。也就是说，它用于筛选内容， 只产生与语言优先级列表 匹配的项目。这可能会排除所有语言标签值，也可能包含许多 （甚至全部）项目。
[BCP47] 定义了两种筛选方式：基本筛选和扩展筛选 [RFC4647]。
基本筛选使用由基本语言范围组成的 语言优先级列表， 对语言标签列表或带有语言标签的内容进行筛选。在基本筛选中， 语言标签与每个语言范围进行前缀匹配。当你只需要选择语言优先级列表中各语言范围的 严格后代语言标签时，基本筛选非常有用。
扩展筛选使用由扩展语言范围组成的
语言优先级列表，
对语言标签列表或带有语言标签的内容进行筛选。扩展语言范围
可以在一个或多个子标签的位置包含通配符 * 子标签。
（位于第一个“主要语言子标签”位置之外的通配符会被忽略。）与基本
筛选不同，扩展筛选用于选择语言标签内部的特定子标签。
使用扩展筛选，可以筛除与指定语言范围中的
特定子标签列表不匹配的语言标签。
这是本节要求的汇总列表，可用于自我审查。对于与你的规范相关的所有要求， 选择相应行中的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后单击“为 GitHub 创建 Markdown”按钮，并将结果复制到 GitHub 议题列表中。请参阅更多详细信息。
基本要求
背景信息
基本方向值
在标记中处理方向
auto。这意味着
将通过检查内容本身来确定基本方向。更多auto，则内容段落的方向
应逐段确定。更多
处理字符串的基本方向
为内联文本或子字符串设置基本方向
auto，这意味着
将通过检查内容本身来确定基本方向。典型做法是
根据所有标记之外的第一个强方向字符设置方向。更多
检测和匹配方向（待定）
对于使用从右到左书写系统书写或与其混排的文本，确定方向非常重要。这些书写系统中的字符 按照输入和发音的顺序存储在内存中，这称为逻辑顺序。 Unicode 双向算法（UBA）为自动呈现按逻辑顺序存储的字符序列提供了大量支持， 使它们能够按照预期的视觉顺序排列。遗憾的是，仅靠 UBA 并不足以正确呈现双向文本，还必须提供有关应应用于给定字符序列的 默认方向上下文的附加信息。
基本要求如下。
上述要求的一种特殊情况适用于数据结构和文档格式中的自然语言字符串值：
对于以从右到左书写系统为母语工作方式的人， 标注从右到左文本所需的工作量必须尽可能少。
要求阿拉伯语、迪维希语、希伯来语、波斯语、乌尔都语等语言的使用者， 为其编写的每个段落或小型数据项添加标记或控制字符，工作量过大而难以管理。 通常，格式应建立默认方向，并且只在需要处理例外情况时 要求用户进行干预。
本节尝试阐述与文本方向有关的一些关键概念， 以便更容易理解后续建议。
为了正确显示使用“从右到左”书写系统编写的文本， 或包含双向元素的从左到右文本，确定用于规定 文本元素显示顺序的基本方向非常重要。
如果你不熟悉 Unicode 双向算法（UBA）能做什么、不能做什么， 以及基本方向为何如此重要，请阅读Unicode 双向算法基础。
在本节中，术语段落指纯文本中后跟
强制换行符的一段文本，但在其他情况下可能表示不同内容。在 CSV 中，
它相当于“单元格”，因此一行由逗号分隔的项目实际上是一组由逗号分隔的
段落。 在 HTML 中，它相当于最低级别的块元素，通常是 p 元素，但如果只包含
文本和/或内联元素，也可以是 div、li
等。
在 JSON 中，它通常相当于带引号的字符串值；但如果字符串值使用标记，
则段落与块元素关联；如果字符串值由多行纯文本组成，则每一行都是一个段落。
这里使用术语元数据， 指可以作为与数据关联的注释或属性的信息，或在允许使用标记的场景中作为标记， 或作为更高层协议等。
设置基本方向有多种可能的方法。
ltr、rtl 或 auto。
dir=auto 时就是如此。）dir
属性时就是如此。）html 标签上设置
dir 属性时就是如此。另一个示例是
包含许多提示且全部使用阿拉伯语编写的字幕文件；最好允许作者
在文件开头声明所有提示文本的默认方向为 RTL。
在需要时，应始终能够覆盖特定段落的方向信息。
auto 时才会如此，因为 HTML 规定了默认方向。）
捕获用户输入的文本时，通常需要了解用户输入数据时所处的上下文，
以确定输入内容的基本方向。例如在 HTML 中，这可能由从 html 标签继承的方向设置，也可能由用户按键设置
表单字段的基本方向。随后，需要找到某种方式存储基本方向信息，
或在呈现字符串时将该信息与字符串关联。通常，在这种情况下，
输入字符串内部的任何方向变化都由用户处理，并作为字符串的一部分捕获。
单个段落内部嵌入的文本范围可能需要采用不同的基本方向。例如：
“标题是‘!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 显示在 希伯来语文本的左侧。只有使用元数据或成对控制字符才能得到正确的显示结果。
当然，如果使用首个强方向字符启发式方法检测基本方向
（例如 HTML 中的 dir="auto"），那么在相关文本以某些
原本会产生错误结果的内容开头时，插入 RLM、ALM 或 LRM
可以帮助影响检测到的基本方向。
请记住，如果使用元数据设置基本方向，强方向格式化字符会被忽略， 除非元数据明确规定应使用首个强方向字符启发式方法。
最后，说明一下 U+061C ARABIC LETTER MARK（ALM）的使用。
当数字之前没有阿拉伯字母时，该字符用于影响阿拉伯书写系统文本中
数字序列的显示。
以下原因都说明不能使用语言标签提供基本方向信息：
auto 值。Suppress-Script: Hebr）。
波斯语等通常使用 RTL 书写系统的语言也可能以转写形式书写，
因此无法保证存在承载方向信息所需的文字子标签。总而言之，
无法依赖人们在语言信息中提供文字子标签来影响方向。默认基本方向的值应包括从左到右、从右到左和自动。
auto 值允许自动检测一段文本的基本方向。
例如，HTML 中 dir 的 auto
值会查找文本中的第一个强方向字符，
同时也会忽略某些标记项，以推测文本的基本方向。请注意，
自动检测算法远非完美。首个强方向字符检测无法正确识别实际上为从右到左方向、
但以强 LTR 字符开头的文本。尝试根据文本内容判断基本方向的算法也存在问题。
最理想的情况是基本方向已知并被明确声明。
本节介绍如何定义适用于使用标记组织内容的资源的双向文本处理方法。 某些建议与处理 Web 上字符串的建议不同（请参阅 3.5 处理字符串的基本方向）。
规范应说明如何为整个资源定义默认基本方向， 即设置整体基本方向。
在没有其他信息的情况下，默认基本方向应为 auto。
内容作者必须能够指明文本中基本方向发生变化的部分。 在块级别，应使用属性或元数据实现此目的， 并且不应要求内容作者使用 Unicode 控制字符来控制方向。
依赖 Unicode 控制字符为每个块建立方向并不可行， 因为换行符会终止此类控制字符的效果。如果必须在每个需要的位置 出现控制字符，还会使数据稳定性大幅降低，并造成不必要的管理困难。
典型做法是根据所有标记之外的第一个强方向字符设置方向， 但这并不是唯一可行的方法。方向设置为自动时，用于确定方向性的算法 应与接收方预期使用的算法一致。
首个强方向字符算法会根据 Unicode 定义， 查找段落中第一个具有强方向属性的字符。然后根据该字符的方向 设置段落的基本方向。
请注意，如果第一个字符不能代表段落其余内容， 首个强方向字符算法可能会错误猜测段落方向，例如 RTL 段落或 行以 LTR 品牌名称或技术术语开头时。
有关检测方向的算法的其他信息，请参阅讨论 HTML 相关内容的文档中的估算算法。
如果纯文本的整体基本方向设置为 auto，则内容段落的方向应逐段确定。
例如，HTML 具有 dir 属性，
可以在不借助 CSS 样式的情况下管理基本方向。XML 格式应定义
用于表示方向信息的专用标记，即使它们需要 CSS 才能实现所需显示效果，
因为文本可能还会以其他方式使用。
CSS 等样式表不一定始终与数据一起使用，也不一定会在数据联合分发时 随数据一起传递。方向信息对于正确显示数据至关重要， 因此应与标记或数据建立更紧密、更持久的关联。
本节中的信息取自Web 上的字符串：语言和方向 元数据。该文档仍在编写中，因此这些指南可能随时发生变化。
应规定，除非提供了元数据，字符串使用者应使用启发式方法， 并且最好基于 Unicode 标准的首个强方向字符算法， 检测字符串的基本方向。
Web 上的字符串：语言和方向元数据中的最佳实践、建议和 缺口
这里的“内联文本”在标记中具有容易理解的含义。它也适用于字符串 （例如 JSON、CSV 或其他纯文本格式中的字符串），指不包含字符串中所有字符的 字符范围。
必须能够指明基本方向发生变化的内联文本范围。 如果可以使用标记，则首选使用标记。否则，规范必须要求 接收应用程序能够识别 Unicode 控制字符，并正确实现这些字符。
还必须能够将一段内联文本的方向设置为 auto，这意味着将通过检查内容本身
来确定基本方向。典型做法是根据所有标记之外的
第一个强方向字符设置方向。
首个强方向字符算法会根据 Unicode 定义， 查找段落中第一个具有强方向属性的字符。然后根据该字符的方向 设置段落的基本方向。
请注意，如果第一个字符不能代表段落其余内容， 首个强方向字符算法可能会错误猜测段落方向，例如RTL段落或行以 LTR 品牌名称或技术术语开头时。
有关检测方向的算法的其他信息，请参阅讨论 HTML 相关内容的文档中的估算算法。
如果用户使用 Unicode 双向控制字符，应用程序必须支持 隔离型 RLI/LRI/FSI 与 PDI 字符，并且规范应推荐使用它们 （而不是 RLE/LRE 与 PDF）。
RLM/LRM 的使用应当适当，并且规范应明确说明 这些控制字符能做什么以及不能做什么。
Unicode 双向控制字符 U+200F RIGHT-TO-LEFT MARK 和 U+200E LEFT-TO-RIGHT MARK 本身不足以管理
双向文本。它们无法为嵌入文本产生不同的基本方向。
为此，需要能够指明嵌入文本范围的起点和终点。 如果可以使用标记，
最好使用标记实现；否则应使用上文提到的其他 Unicode 双向控制字符。
对于标记，应提供专用属性来控制基本方向和 双向覆盖；不要依赖用户将样式属性应用于任意标记 来实现双向文本控制。
对于标记，应允许所有包含文本的内联元素 使用双向属性。
对于标记，应提供属性，使用户能够 (a) 创建隔离或嵌入的基本方向，或 (b) 完全覆盖双向算法。 在这两种情况下，此类属性都应允许用户将方向设置为 LTR、RTL 或 Auto。
这是本节要求的汇总列表，可用于自我审查。对于与你的规范相关的所有要求， 选择相应行中的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后单击“为 GitHub 创建 Markdown”按钮，并将结果复制到 GitHub 议题列表中。请参阅更多详细信息。
字符和字符编码基础
选择“字符串”的定义
DOMString。
（此用途列表并不详尽。）更多USVString。
对于涉及UTF-8
编码的任何过程，
或在未配对的代理项码位会产生错误的任何位置，
都应使用USVString。更多
DOMString和USVString。
通常应选择DOMString而不是
USVString，
因为后者需要额外处理，而这些处理对大多数文档格式或协议并无益处。更多
DOMString，
或在极少数情况下指定USVString，
除非有理由需要与特定字节值交互，或者不能假定使用 UTF-8字符
编码。更多Uint8Array，
例如不包含文本的数据，或表示无需处理的文本的字节序列
（例如复制缓冲区时）。更多ByteString。更多定义参考处理模型
包含和排除字符范围
使用专用区
选择字符编码
识别字符编码
设计字符转义
ካ 或
\u{12F}，或者使用固定数量的数字，例如 \u12AB 或
\U001234AB。更多
存储文本
空白字符
“字符”一词在不同上下文中具有不同含义： 它可以分别指给定文本单元在视觉、逻辑或字节级别的表示。 因此，该术语不够精确，不宜在规范中随意使用。 要讨论字符串数据的处理，必须首先理解文本在计算系统中如何定义和编码， 以及用于使此类规范明确无歧义的相关术语。
规范开发者以及基于这些规范开发软件的开发者， 可能更熟悉自己曾经接触过的“字符”一词的用法， 而不太熟悉该术语在国际环境中的广泛用法。此外，在计算环境中， 字符经常与相关概念混淆，从而导致规范和软件不完整或不适当。
指定字符、字符串或任何处理字符或字符串的过程时， 应使用最具体且适当的术语。除非有理由不这样做， 应将码位定义为Unicode 标量值， 并优先使用该术语，而不是“字符”。
应使用本节中最适当的术语。以下是其他一些推荐术语：
| 单元类型 | 应使用以下术语代替字符…… | 说明 |
|---|---|---|
| 文本单元 | 码位、 Unicode 码位、 Unicode 标量值 |
文本的逻辑单元，不考虑字符编码 形式或任何特定序列化方式。 |
| 存储、处理、序列化、编码 | 码元 | 编码和序列化单元。码元通常在 线上格式、文件格式和低级文本处理中规定。其含义取决于使用的字符 编码（最好是 UTF-8 或 UTF-16）。 |
| 视觉单元、用户感知字符、选择/分段 | 字素
簇、 排版 字符单元 |
将文本划分为视觉单元，用于大多数视觉选择和截断。此建议包含最多的细微差别。 |
| 字体元素 | 字形 | 单独的显示值。该术语主要用于讨论字体内容。 |
如果无法避免使用“字符”一词，则必须 清楚定义该术语。
以下是核心术语的简要词汇表：
[Unicode] [D7] 将抽象
字符定义为：用于组织、控制或表示文本数据的信息单元。
该定义必然比较宽泛，并进一步指出，抽象字符没有具体形式
（因此不能与字体中的字形混淆），
也不等同于用户可能理解的“字符”
（因此不能与字素混淆）。
请避免在自己的规范中使用该术语。
字符集 是一组无序的抽象 字符（换言之，它是一个集合），这些字符可以一起用于编码文本。 字符集中的字符集合 有时称为其字符库。 大多数字符集 只支持特定范围的语言或书写系统。
[Unicode]，有时也称为通用字符 集，包含当前用于在计算机系统中编码文本的所有字符， 包括历史或已灭绝的书写系统，以及现代用法、专用字符、排版符号和表情符号等其他内容。 所有其他字符集都是 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 |
规范、软件和内容不得要求或依赖码位与呈现单元（例如字素簇、字形或排版字符单元） 之间的一一映射。
万维网字符模型 1.0：基础中的视觉呈现单元 C002。
万维网字符模型 1.0：基础中的字符、按键和字形示例。
在本文档中，视觉文本单元指用户感知到的可见文本的单个单元。 它可以显示在屏幕上，也可以出现在其他介质中，例如打印在纸上或写在餐巾纸背面。 该术语必然不够精确，因为用户的感知经常取决于其对书写系统和文字系统的熟悉程度， 尤其是在使用组合标记、复杂定位或基于上下文的复杂塑形的书写系统中。 请避免在自己的规范中使用该术语。
字素簇 是编码文本中视觉文本单元的计算近似值， 即一系列预期从用户角度构成单个视觉文本单元的码位。 [Unicode] 提供了一种计算这些边界的方法， 以帮助处理文本，因为对于许多文本操作，此类序列应作为一个不可分割的文本单元处理。 例如，在文本中移动光标时，光标应一起“跳过”或选择整个视觉文本单元 （及其底层码位）。不应能够将光标移动到视觉文本单元的“中间”。 （除非另有规定，本文档中的术语字素簇 指Unicode 文本分段 [UAX29] 所称的“扩展默认字素簇”。）
请注意，某些文本操作确实允许用户与字素 簇内的各个码位交互。 例如，某些编辑功能（如退格）会逐步删除视觉文本单元末尾的字符 （例如，使用户无需删除整个字素簇即可纠正拼写错误）。
术语排版 字符单元由 [CSS] 定义，用于指在特定操作中应视为“单一单元”的 不同类型码位序列。 有时它与术语字素簇一致， 有时则不同。只有在理解其上下文和用法时才应使用该术语。
字形
是使用特定字体呈现字符（或字符序列）时的视觉表示。
字形与抽象字符并不总是存在一一对应关系。
字形可以表示字符的一部分，也可以表示多个字符的组合。
不同的字形可以表示同一个码位。
例如，以下都是 AU+0041 LATIN CAPITAL LETTER A
的不同字形：
因此，字体是用于呈现文本的一组特定字形。
在某些书写系统中，字符与音位之间关系密切 （音位是特定口语中最小的区别性声音单元）， 而在其他书写系统中，字符则与含义密切相关。 即使字符大致对应音位，这种关系也可能并不简单， 并且字符与音位之间很少存在一一对应关系。
以下是“字符”一词与声音单元不匹配的一些示例：
规范和软件不得要求或依赖 一次按键产生一个字符，也不得要求一个字符通过一次按键输入 （即使使用修饰键），还不得假定世界各地的键盘都相同。
万维网字符模型 1.0：基础中的输入单元 C005。
万维网字符模型 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] 标准将“字符串”一词定义为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] 或整个互联网 [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 与其之间转换并不适当时，应指定ByteString。
Web 平台设计原则 [DESIGN-PRINCIPLES] 中的IDL 字符串类型
ByteString
并不是通用字符串类型。不要使用它在
[WebIDL] 中定义数据结构。
规范可以选择禁止或弃用某些字符编码， 并将其他字符编码设为强制要求。无论实际字符编码为何， 规定的行为必须与按照以下方式处理时相同： (a) 实现规范的应用程序接收到的任何文本数据对象的字符编码必须得到确定，并且该数据对象必须解释为 Unicode 字符序列；这必须等效于将数据对象转码为某种 Unicode 编码形式， 必要时调整字符编码标签，并以该 Unicode 编码形式接收； (b) 所有处理必须在该 Unicode 字符序列上进行； (c) 如果应用程序输出文本，则 Unicode 字符序列必须使用规范允许的字符编码之一进行编码。
万维网字符模型：基础中的参考处理模型 C014
如果规范涉及多个文本数据对象 （例如引用外部已解析实体的 XML 文档），则规范可以 允许这些数据对象使用不同的字符编码。在所有情况下， 都必须将参考处理模型应用于所有文本数据对象。
万维网字符模型：基础中的参考处理模型 C014
这里的“代理项码位”指使用 U+D800 到 U+DFFF（含）范围内的字符值。
这些码位被保留，以允许 UTF-16 字符编码寻址补充
字符。代理项始终成对使用，并且只在使用 UTF-16 编码时出现。
单个代理项码位称为“未配对的代理项”，绝不应使用。
从历史上看（尤其是在 Unicode 创建之前），常用的编码字符集有很多种， 这些字符集使用不同方案将字符编码并序列化到计算机系统的内存或存储中。 除了 ISO/IEC 8859 等标准规定的方案外，还存在许多专有的供应商或平台特定字符集， 通常还包含相关的字符编码形式。 在本文档中提及旧式（非 Unicode）编码字符集的字符编码形式时， 指的是 [编码] 中规定的 从字节到 Unicode 码位的特定现代映射。
所有文档格式、协议和序列化形式都应使用 UTF-8。
UTF-8 是几乎所有应用程序的最佳选择。
新协议和格式，以及部署到新上下文中的现有格式，都必须使用 UTF-8 字符编码。 此政策适用于 IETF 和 Web 标准，并在 [RFC2277]、 [RFC3629]、 [编码]、 [design-principles] 等许多文档中阐明。 只有处理较旧协议或格式的规范才需要旧式字符 编码，即使在这些情况下，也强烈推荐使用 UTF-8。
仅根据字节值无法可靠检测字符编码。 如果允许使用 UTF-8 以外的编码，就必须提供某种机制， 使使用者 能够确定所使用的编码。
文档格式或协议有时支持旧式字符 编码。基于这些格式构建的规范，在可行情况下， 可以规定一致性实现只使用 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 编码 | %F0%9F%98%BD |
UTF-8 字节的十六进制编码；每个字节需要三个字符； 每个码位需要 1 到 4 个字节 |
选择转义机制时，请注意，通常优先使用十六进制而不是十进制编码， 因为 Unicode 标准及其引用普遍使用十六进制。
空白字符是在排版中表示水平或垂直空间的字符。 空白字符可能具有不同的视觉效果：某些空白字符没有可见效果， 而其他空白字符则表示页面上较大、较小或可变的空间量。
使用“空白”一词的规范应当 明确界定该术语的含义。
大多数规范应当将空白定义为 具有 Unicode White_Space 属性的字符。
如果规范对“空白”的定义与 ASCII 或 Unicode 空白不同， 则必须列出具体码位。
某些规范（例如 ECMAScript） 为满足自身特定要求，提供了与上述定义不同的空白定义。
下表列出了各种规范中空白字符的定义。
white_space 属性 |
pattern_white_space 属性 |
ASCII 空白（HTML） | CSS 空白 | 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 着色语言
使用 pattern_white_space 属性。
在规范中，应使用 U+XXXX
语法表示 Unicode 码位。
在规范中引用 Unicode 码位时，U+XXXX 格式已得到广泛理解。
当多个码位按序列出现时，应使用空格分隔。无需添加其他修饰。
请注意，码位可以包含四位、五位或六位十六进制数字。
如果所需数字少于四位，则应在码位编号前补零。
应使用 Unicode 字符名称描述特定码位。
Unicode 为每个已分配的 Unicode 码位指定唯一且不可变的名称。
在规范中引用特定字符时，同时使用这些名称和采用
U+XXXX 表示法的码位，
有助于使规范明确无歧义。
推荐使用字符命名模板。
对于大多数字符，模板如下所示：
<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>
较短的字符序列应列出字符名称，并使用 + 分隔。
在某些情况下，包含字符名称和其他标记会显得过于拘泥细节，
并降低可用性，但也应谨慎，避免因过于随意而损害含义。
尤其是，较长序列有时只列出码位，不过在可能的情况下，
应保留字符名称以提高清晰度。本文档中关于组合“家庭”表情符号的讨论提供了一个示例：
👨👩👧👧U+1F468 U+200D U+1F469 U+200D U+1F467 U+200D U+1F467
由于规范通常既需要字符的定义，也需要与这些字符关联的语义， 因此无论是否包含对 ISO/IEC 10646 的引用，规范都应当包含 对 Unicode 标准的引用。
引用 Unicode 标准和 ISO/IEC 10646，C062，位于万维网字符模型：基础中。
如果希望在规范发布后分配的字符也可用于该规范，则必须对 Unicode 标准作一般性引用。可以包含对 Unicode 标准的 特定版本引用，以确保依赖特定版本的功能可用，并且不会随时间发生变化。
引用 Unicode 标准和 ISO/IEC 10646，C063，位于万维网字符模型：基础中。
所有对 Unicode 标准的一般性引用都必须指向 包含该引用的规范发布之日可用的最新版 Unicode 标准。
引用 Unicode 标准和 ISO/IEC 10646，C064，位于万维网字符模型：基础中。
所有对 ISO/IEC 10646 的一般性引用都必须指向 包含该引用的规范发布之日可用的最新版 ISO/IEC 10646。
引用 Unicode 标准和 ISO/IEC 10646，C065，位于万维网字符模型：基础中。
这是本节要求的汇总列表，可用于自我审查。对于与你的规范相关的所有要求， 选择相应行中的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后单击“为 GitHub 创建 Markdown”按钮，并将结果复制到 GitHub 议题列表中。请参阅更多详细信息。
为分段、索引等操作选择文本单元
匹配标识符和语法内容的字符串同一性
使用以下步骤定义标识符和语法内容的字符串同一性匹配：
使用 Unicode 规范化
大小写折叠
截断或限制字符串长度
使用文件名和路径名
在许多情况下，软件过程需要访问子字符串或指向字符串内部的位置， 并通过索引（即字符串中的数字“位置”）来实现。如果这些索引在 Web 组件之间交换， 就需要对字符串索引采用一致认可的定义，以确保行为一致。由此产生的两个主要问题是： “计数单元是什么？”以及“从 0 还是 1 开始计数？”。
在主要关注用户交互的应用程序中，可以使用字素簇作为字符串索引的基础。
根据字素簇定义索引的规范必须采用以下任一方式：(a) 按照Unicode 标准附录第 29 号：Unicode 文本分段 （UTR #29）中定义的扩展字素簇来定义字素簇；或者 (b) 明确定义如何将定制规则应用于索引操作。
一个反例是 DOM 第 1 级中使用 UTF-16。 不建议使用 UTF-16 码位，因为这可能使索引落在两个代理项字符之间， 从而导致严重问题（请参阅6.5 截断或限制字符串长度）。
使用以下步骤定义标识符和语法内容的字符串同一性匹配：
万维网字符模型：字符串匹配中的匹配算法
“ASCII 大小写折叠” 应当仅用于限制为 ASCII 的应用程序 内部标识符。
实现不得更改正在交换、读取、解析或处理的 文本数据的规范化形式，除非作为文本转换的副作用而必须这样做，例如将内容转码为 Unicode 字符编码、执行大小写折叠或进行其他由用户发起的更改，因为使用者或内容本身 可能依赖未规范化的表示形式。
万维网字符模型：字符串匹配中的规范化的其他注意事项。
如果某些操作可能根据规范化的文本输入产生未规范化的输出， 规范必须定义所得输出是否需要规范化。规范可以声明某些操作可选择执行规范化；在这种情况下， 默认值应当为执行规范化，并且应当使用显式选项关闭规范化。
万维网字符模型：字符串匹配中的在文档格式中规定规范化时的 要求。
除非实现首先通过检查确认文本采用规范化形式，或自行重新规范化文本， 否则不得执行对规范化敏感的操作。不受这些规则约束的 私有系统内可以建立私下约定，但任何外部可观察结果都必须与遵守这些规则时相同。
万维网字符模型：字符串匹配中的在文档格式中规定规范化时的 要求。
修改文本并执行对规范化敏感操作的规范化文本处理组件必须表现得像在每次修改后都执行了规范化， 从而使后续所有对规范化敏感的操作始终表现得像是在处理规范化文本。
万维网字符模型：字符串匹配中的在文档格式中规定规范化时的 要求。
执行字符串值比较或匹配的规范应当规定有关 Unicode 规范化的适当说明或警告。
在规范中使用或采用 Unicode 规范化，通常是定义给定格式或协议中如何进行匹配的一部分。为了帮助规范作者和实现者理解其中的一些 复杂性，国际化工作组编写了一份描述字符串匹配和比较注意事项的文档：万维网字符模型：字符串 匹配 [CHARMOD-NORM]。
规范需要作出的选择之一，是是否要求将 Unicode 规范化作为匹配规范词汇表中定义的 各种“值”的一部分。这些值通常是文档格式或协议语法的一部分，包括属性名称或值、 元素名称或值、ID 等。遵循建议，不将规范化 用于匹配的规范，应包含以下注释，以提醒内容作者。
注释示例。此版本必然没有具体说明哪些内容构成“值”： 规范可以根据需要写得更具体。
本规范不允许为了比较而对值进行 Unicode 规范化。 外观和语义相同但使用不同 Unicode 字符序列的值不会匹配。建议内容作者始终使用 相同的编码序列，或者在选择值时避免可能引发问题的字符。有关更多信息， 请参阅 [CHARMOD-NORM]。
选择要求将规范化作为字符串匹配一部分的规范，应包含以下警告：
警告示例。此版本必然没有具体说明哪些内容构成“值”： 规范可以根据需要写得更具体。
本规范在匹配值时应用 Unicode 规范化。 这可能影响相关文本的外观和含义。有关更多信息，请参阅 [CHARMOD-NORM]。
如果上述内容不能满足你的需求，或你不确定如何使用，请联系 I18N 工作组 获取其他方案或帮助。
将字符串匹配定义为格式、协议或形式语言定义一部分的规范和实现 （可能包括解析、匹配、标记化等操作）必须定义所使用的条件 和匹配形式。这些形式必须是以下之一：(a) 区分大小写； (b) 使用 Unicode 完整大小写折叠的不区分 Unicode 大小写；(c) 不区分 ASCII 大小写。
如果词汇表包含超出 Unicode 基本拉丁文（ASCII）范围的字符， 并且规范定义了不区分大小写的匹配，则规范必须规定使用 Unicode 完整大小写折叠匹配。
万维网字符模型：字符串匹配中的不区分 Unicode 大小写的匹配。
如果词汇表仅限于 Unicode 基本拉丁文（ASCII）子集， 并且规范定义了不区分大小写的匹配，则规范可以规定 不区分 ASCII 大小写的匹配。
万维网字符模型：字符串匹配中的不区分 ASCII 大小写的匹配。
某些规范、格式、协议或其实现需要对给定字符串的大小规定限制。 这可能出于多种原因，例如处理能力、内存、数据结构大小等方面的限制。 由于长度限制通常涉及截断或限制文本大小，因此规范及其实现需要格外谨慎， 以确保文本不会损坏，并且所选择的限制不会使该功能对某些用户群体不可用。
除非存在具体的实际或技术限制，规范不应限制字符串长度。
如果规范规定长度限制，则规范应当 规定任何被截断的字符串都包含表示字符串已被修改的标记，例如省略号。
规范或格式可能出于许多原因需要长度限制。最常见的原因是底层数据本身存在大小限制。 例如，数据库中可能存在固定大小的字段，也可能存在数据包大小等实际边界， 或与存储分配或效率有关的其他实现细节。另一个常见原因是显示区域或可见输出的大小有限。
截断字符串时，需要决定使用什么单元计算字符串大小。在某些情况下， 这超出了规范的控制范围，因为截断是出于某种预先确定的原因而发生的。 不过，如果可以选择，则可以应用一些通用指南。
如果需要视觉长度限制，应使用文本呈现或裁剪机制规定视觉截断，
例如 CSS text-overflow [css-overflow-4]。
此类机制不会更改字符串，并且会考虑文本呈现的复杂性。
规范有时会尝试使用视觉文本单元的数量作为可用可见空间的近似值， 以处理视觉限制。此类限制可以采用多种形式，例如限制一行中的字符数量， 或尝试使所有视觉文本单元具有相同的呈现宽度。与编码字符串中的码位 或码元数量相比， 使用视觉文本单元与此类任意限制更加接近。 不过，文本显示的性质通常会使这种做法失效。比例字体、复杂书写系统、样式、 无障碍功能以及许多其他因素都会使问题复杂化。几乎在所有情况下， 视觉文本单元限制实际上都是在尝试近似像素宽度。准确测量限制需要使用显示上下文中的 字体度量，并且还可能受到无障碍设置等本地设置的影响。在网页中， CSS text-overflow 属性可以在不影响文本内容的情况下提供视觉截断。 根据 Unicode 码位数量， 甚至根据字素簇数量 估算一段文本的大小，基本上都不会奏效。
限制字符串最大允许存储长度的规范应当使用Unicode 码位 表示该长度。
大多数限制实际上都与存储限制有关，例如数据库字段的大小或协议中的长度限制。 此类限制要么使用 Unicode 中的码位表示， 要么使用特定字符编码中的码元 （例如字节）表示。码位能够提供最佳用户体验， 因为所有 Unicode 码位都会得到相同处理：如果文本在 40 个码位后截断， 所有语言和书写系统都可以使用相同数量的码位。相比之下，当大小限制使用码元 表示时（例如 UTF-8 中的字节），主要使用 ASCII 字母的语言在给定大小限制下可以使用的字符 （码位）数量，要远多于主要由每个码位占用 2、3 或 4 个字节的字符组成的语言。
在视觉文本单元内部截断， 例如在组合字符序列内部截断， 可能会改变剩余字符串的含义。
除了选择如何表示长度限制（码位还是字节）外，还需要选择截断边界。 文本绝不能在码位中间断开， 因为这会导致字符损坏。文本也不应在字素簇中间断开， 因为这会改变所显示字符的外观和含义。为了确保含义不受影响， 可能需要删除额外的码位。
有时，字符串的长度限制由某个外部因素决定，例如数据库字段的大小， 或在其他位置规定的数据值所分配的字节数。长度限制也可能由于某些实际设计原因 而需要以码元表示 （例如描述面向字节的固定长度线上协议）。此类规范及其实现需要明确说明由此带来的 额外复杂性，包括以下注意事项。
此最佳实践同样适用于使用 16 位码元的 UTF-16，
而不仅适用于 UTF-8 等多字节编码。用于编码 U+10000 到
U+10FFFF 之间Unicode 码位的
UTF-16 代理项对需要
两个码元。
在代理项对中间任意截断会损坏已编码字符。
与 [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] 的多字节字符编码。根据字符的Unicode 标量值， UTF-8 每个码位使用一到四个字节。
当文本字段的限制按字节计算时，该字段能够存储的字符数量取决于所存储的字符。 为确保使用不同语言的用户不会处于不利地位，该限制需要允许存储以相应语言编码的 合理数量的字符。
如果规范允许或要求截断字符串，并且长度使用码元表示， 则了解该限制含义时，字符编码非常重要。 如果限制以字节为单位，并且允许使用旧式字符 编码，请注意，将 Unicode 数据转换为非 Unicode 编码可能导致数据丢失 （因为大多数旧式字符 编码只能编码 Unicode 的一个子集）。
通过连接多个字符串来创建自然语言文本值， 是一种国际化反模式。不同语言在词序、数量、语法性别或格、标点符号以及许多其他要求方面 差异很大。因此，应避免要求或建议实现根据子字符串生成人类可读的消息。
当规范要求实现创建或生成将向用户显示的文本时， 规范应当为实现者提供有关如何避免与文本方向相关的潜在问题的 指南。
API、协议或文档格式的规范有时要求实现创建或提供包含显示名称或说明的字段。 当此类字符串由不同部分组合而成时，由于Unicode 双向算法 [UAX9] 处理组合字符串的方式， 可能会导致呈现或理解问题。在这种情况下，规范应指导实现者如何创建能够正确显示的值。
某些规范需要定义各种实现如何构造文件名或文件路径。其中一项挑战是构建能够在不同操作系统 所使用的不同文件系统上一致工作的定义。本节包含定义文件名或文件路径限制时的一般指南。 这些指南基于 [EPUB-33] 中制定的要求以及实现经验。
文件名长度应当限制为 255 字节。
此限制与某些文件系统中存在的限制有关，最初是 MS-DOS，但某些 Unix 文件系统中也有 此限制；依赖这些文件系统或继承其限制的 PKZIP 等打包方案同样如此。在这些系统中， 特定“路径元素”（包括目录名）的长度限制为 255 字节。
路径名长度应当限制为 65535 字节。
此限制与 FAT32 或 NTFS 等文件系统中的限制有关，这些文件系统将路径长度限制为 UTF-16 字符编码中的 32760（32K）个码元。每个 UTF-16 码元占用 16 位 （即 2 字节），因此按字节计算时限制为 65,535。请注意，UTF-8 中限制为 64K 字节的路径名可能超过这些文件系统的路径长度限制， 因为 UTF-8 是一种可变宽度编码。
文件名和路径名定义不得使用以下 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
作为最后一个字符（请注意，这包括文件名 . 和 ..，
它们对许多文件系统具有特殊含义）应用程序经常需要组织信息或内容集合，这通常涉及对内容进行排序。 数字或日期等许多非文本数据类型可以使用内部数据表示轻松排序。 不过，对于文本信息，字符编码的性质以及用户对“字母顺序”的期望会带来一些额外复杂性。
一个关键选择是，文本数据的排序是严格在内部使用，还是会将结果显示给用户。
对于需要在程序内部快速、确定性地排序文本，且结果不供人类查看 或交互的规范或实现，应当规定根据其字符串定义对字符串排序。 对于标量值字符串（例如 USVString 或许多 XML 处理过程），应规定按码位升序排序。对于基于 UTF-16 的字符串类型 （例如 DOMString 或许多 JavaScript API），应规定按码元升序排序。
可能存在两种内部排序序列：按 Unicode 码位排序， 或按 UTF-16 码元排序。 对于任一种排序类型，所得列表都不会与任何特定的字母顺序或词典顺序匹配。
当字符串以码位序列的形式存储和处理时，例如在 USVString 中， 按码位排序是合理的。 当字符串使用底层编码存储和处理时，例如在 DOMString 中， 按码元排序是合理的。
这两种排序顺序都不会对所比较的字符串应用任何类型的规范化。 这意味着某些看起来等价的字符串会被比较为不同的字符串。有关更多信息， 请参阅字符串匹配 [CHARMOD-NORM]。
需要对自然语言文本进行排序并显示给用户的规范或应用程序面临一些额外复杂性。 Unicode 在Unicode 排序算法 [UTS10] 中定义了默认排序顺序， 随后可对其进行定制，以满足特定语言、区域设置和文化的需求。
不同语言和文化在对文本排序，或使用其字母表或书写系统组织文本数据方面存在差异。
例如，德语使用者认为字母 üU+00FC LATIN SMALL LETTER U WITH DIAERISIS
的排序方式与字母 u 类似（德语实际上存在两种排序序列，
它们对该字母的具体处理略有不同），而丹麦语使用者则将同一个字母视为字母表中的
独立字母，并将其排在字母“y”之后。
确定排序列表使用哪个区域设置可能取决于多种因素。例如，应用程序可能根据数据所在页面 的本地化设置对值列表进行排序。在其他情况下，根据用户代理的运行时区域设置， 或根据 API 中传递的某个参数进行排序可能更合理。重要的是要认识到， 不同用户或不同系统上的排序顺序可能不同。
这是本节要求的汇总列表，可用于自我审查。对于与你的规范相关的所有要求， 选择相应行中的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后单击“为 GitHub 创建 Markdown”按钮，并将结果复制到 GitHub 议题列表中。请参阅更多详细信息。
规定资源标识符对非 ASCII 字符的支持是一件复杂的事情，因为至少有三项规范（URI [RFC3986]、IRI [RFC3987] 和 [URL]） 定义了资源标识符及其序列化方式。WHATWG [URL] 规范试图通过记录 浏览器和其他用户代理的实际做法来解决这种复杂性。URL 规范声明的目标是取代这两个 RFC。
通常，Web 上的文档格式使用将非 ASCII 字符编码为纯文本的资源标识符，也就是“IRI”。 HTTP [RFC9110] 等协议 （但不限于 HTTP）使用通过百分号编码将非 ASCII 字符编码为字节序列的资源标识符，也就是“URI”。由于 [RFC3986] 没有规定将字符编码为字节时 所使用的任何特定字符编码， 因此百分号编码转义容易被误解。 为了帮助解决这一问题，许多现代协议和规范要求资源标识符按照 IRI 的明确规定使用 UTF-8 字符编码，将字符编码为线路格式和协议所支持的 ASCII 子集。
文档格式或协议需要支持包含非 ASCII 字符的资源标识符，因为在许多情况下， 给定资源的名称或标识符是根据用户输入生成的。通常不应限制用户使用自己的语言填写这些值， 也不应限制用户这样做的能力。
根据 [RFC3986] 中的定义，URI 引用仅限于 ASCII 的一个子集，不能直接使用非 ASCII 字符。提供百分号 编码是为了转义任意字节值。然而，单独使用百分号编码的作用有限， 因为可能使用许多不同的旧式字符 编码将给定字节序列解释为字符（或将给定字符序列编码为字节）。 国际化资源标识符（IRI）[RFC3987] 采用基于 [Unicode] UTF-8 编码的统一方式，解决了资源标识符中 非 ASCII 字符的编码和解释问题。
虽然通常不建议施加其他限制，但如果正在考虑此类限制，请参阅 [UAX31] 和 [CHARMOD-NORM] 以获得更多指导。
这是本节要求的汇总列表，可用于自我审查。对于与你的规范相关的所有要求， 选择相应行中的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后单击“为 GitHub 创建 Markdown”按钮，并将结果复制到 GitHub 议题列表中。请参阅更多详细信息。
在标记中定义元素和属性
处理标记中的纯文本
在语法内容中定义关键字、标识符和命名空间
U+D800 到
U+DFFF）或非字符码位。更多
U+0000 到 U+001F）和
C1（U+0080 到 U+009F）控制字符。更多
处理形式语言、文档格式、协议或 API 的规范通常需要定义标记、语法或应用程序内部 标识符。本节中的最佳实践涵盖定义这些内容时的不同需求。
定义标记语言或基于给定标记语言的语法的规范，需要关注元素、属性及其值的定义。 例如，[XML] DTD 定义在特定文档类型中有效的 元素和属性。
定义给定文档格式、协议或 API 的规范通常需要定义保留关键字、字段名称或允许值的标识符。 其中许多都是应用程序内部 标识符，其名称和值完全由规范定义。在某些情况下，规范将允许其中部分或全部是可由 用户填写或命名的用户提供的值。
如果确实定义了包含用户可读内容的属性值，请提供一种方法， 使该文本的方向和语言信息能够与元素中包含的文本分开指示。
提供一个类似于 span 的元素，使其可用于任何文本内容， 以应用国际化所需的信息。
国际化信息可以包括语言和基本方向元数据、内联语言变化、双向文本行为变化、 翻译标志等。
万维网字符模型：字符串 匹配 [CHARMOD-NORM] 的第 2 节： 字符串匹配问题指出：
Web 主要由基于字符数据的文档格式和协议组成。这些格式或协议可以视为一组资源， 主要由包含某种形式的结构标记或语法内容的文本文件 组成。处理此类语法内容或文档数据， 需要执行基于字符串的操作，例如匹配（包括正则表达式）、索引、搜索、排序等。
用户，尤其是实现者，有时会对相似字符串能否匹配，或对文本应用不同转换的有效性抱有 过于简单的预期。这尤其涉及语法内容，但也包括 Web 上的许多文本处理类型。
由于 Web 对文档中文本的不同表示方式十分敏感，如果未考虑同一文本可能采用的不同 表示方式，就可能使用户感到困惑，或者产生意外或令人沮丧的结果。
语法内容是指这种已定义格式 中的全部文本内容。形式文法中的各种记号（例如标识符）称为词汇表。
词汇表中的“保留关键字”通常被视为 应用程序 内部标识符：这些值供程序内部使用，不向最终用户显示， 即使所选择的值表达了某种语义含义（通常使用英语）。
规范还可以允许内容作者设置值，例如变量名称或各种 ID，但并不限于这些值。
为了促进互操作性，实现需要能够可靠且一致地匹配其所定义的语法内容的不同部分。
首先应假定任何文档格式或协议都由 Unicode 字符串组成，并且必须能够传输 Unicode 数据。 某些字符的属性看起来可能会使处理“复杂化”，但它们是许多语言不可或缺的组成部分。 限制有效字符的范围可能会无意中损害国际用户的可用性，尤其是母语不使用拉丁字母的用户。 除非绝对必要，否则应避免损害或禁止传输、处理和交换国际化数据的能力。
规范可能出于许多原因限制内容。重要的是，规范作者应考虑施加此类内容限制所产生的影响， 并为实现者记录该限制。
当某项限制已由上层规范记录时，该内容限制就根据上下文显而易见。例如，如果正在定义 HTTP 标头， 就隐含着将标头的名称限制为 ASCII 的特定子集 （请注意，这不适用于 HTTP 标头的值）。
规范作者常用的一种策略是，将其词汇表或其子集 （例如应用程序 内部标识符或本地定义的命名空间）限制为一组经过谨慎选择的 ASCII 字符。 当值并非用于传输任意数据时，将标识符、保留关键字和值限制为 ASCII， 可以避免输入、显示以及（尤其是）比较 Unicode 字符串时固有的技术难题。
ASCII 的可打印子集是Unicode
基本拉丁文码位的任意子集，
但不包括 C0 控制字符（包括从 U+0000 到
U+001F 的范围）和 
U+007F DEL。
具体子集取决于规范或应用程序的本地要求。大多数子集包含所有ASCII 字母数字字符。
允许使用的标点符号范围和／或是否包含 U+0020 SPACE 字符，取决于本地要求
（例如是否将这些字符用于语法、转义或分隔符）。
可由文档作者选择（或根据数据派生）的标识符或数据值通常需要支持其他语言。 将允许使用的字符集限制为 ASCII 可能会妨碍国际化可用性，尤其会影响语言不使用 拉丁字母的用户，或使用 ASCII 范围之外字符的应用程序。如果标识符等值根据用户数据生成， 或者可能以具有较强助记意义的方式被外部引用，则这一问题尤为突出。例如，CSS 允许类名 使用广泛的 Unicode 码位，尽管其保留关键字词汇表仅限于 ASCII 的 可打印子集。
8.3.2 定义应用程序内部数据值，了解选择名称的指南
在解析给定文档格式时，组合标记和某些其他字符（例如连接符或双向格式字符）的处理可能会 带来问题：需要特别注意如何将每个标识符“标记化”（与周围文本分开）。 一种方法是限制允许作为标识符起始字符的范围，以确保普通文本处理不会干扰 后续对标识符的匹配。
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 处理的定义方式是，在解析标识符和记号时不考虑 Unicode 字符属性 （例如给定字符是否为组合标记）。这使标识符能够以组合字符开头并仍得到可靠处理， 但纯文本编辑器对该值的处理方式可能并不相同。
定义标识符时，应谨慎处理空白字符。请注意，除了 ASCII 字符 U+0020 SPACE
和 U+0009 TAB 之外，还存在其他 Unicode 水平空白字符。
为字段和值选择不依赖区域设置且文化中立的名称。
定义标识符（包括字段名称和值）时，应尽可能选择文化中立的名称。例如，应优先使用
postalCode，而不是仅适用于美国的 ZIPCode；
或优先使用 givenName/familyName，而不是更受文化影响的
firstName/lastName。
规范必须决定一种格式是区分大小写，还是不区分大小写。
例如，值 green 是否与值 GREEN 或 GrEeN 匹配。
在本节中，术语“区分大小写”和“不区分大小写” 会像此处一样额外强调，因为“区分”和“不区分”很容易混淆。
使用 [INFRA] 中的不区分 ASCII 大小写，规定仅限于ASCII 可打印子集的值采用 不区分大小写的匹配。
只要允许使用非 ASCII 字符，就应使标识符区分大小写。 只有当内容限制为ASCII 可打印子集时， 才应进行不区分大小写的比较。以不区分大小写的方式比较 非 ASCII 字符串，需要处理万维网字符模型：字符串 匹配 [CHARMOD-NORM] 中记录的诸多问题， 包括规范化和语言敏感性。
某些规范需要定义文档格式或协议中给定字段的值。当数据值与数字或日期等特定类型关联时， 通常使用某种知名模式定义字段格式，例如 [XMLSCHEMA11-2] 或 [JSON-SCHEMA]。
定义供机器读取且不可本地化的字符串数据值的规范， 应使用不容易与自然语言文本混淆的值。
许多协议、文档格式或数据结构定义供内部使用的枚举值。这些值并非用于直接向人类显示。 有时为这些值提供描述性名称（通常使用英语）会有所帮助，以协助使用规范、协议或 API 的用户，或者需要调试给定文档或交互的用户。在规范中分配这些值时， 所选名称应当具有“类似代码”的外观，使用户不会误以为该值可以像自然语言文本一样显示。
不同的组织采用了多种样式，使应用程序内部值看起来“类似代码”。 应选择最适合你的规范的样式。这些样式包括：
U+005F LOW LINE）分隔。包含人类可读字符串的字段，尤其是说明性字段，必须假定为自然语言字符串。 即使预期查看该字符串的用户是软件开发者，也是如此。必须能够确定文档或数据结构中 每个此类字段的语言标签和字符串方向。
此类字段的常见名称包括 name、description、
title、message，有时还包括 value。
一种判断方法是：作为规范作者或用户，如果你不愿将该字段的内容写成
SNAKE_CASE_SHOUTED，则最好将该字段视为自然语言文本。
供人类使用的字段应当可以本地化。
这可以采用多种形式。例如，规范或协议可以允许语言协商，并且只返回最匹配的 本地化字符串。或者，给定资源可以包含多种语言，供使用者选择。
字段名称和其他枚举值应使用可本地化的显示名称包装。
字段名称和枚举值不是自然语言文本，即使这些名称看起来像纯文本，并且用户可能理解它们。 不应为这些字段和值关联语言或方向元数据；如有必要，规范应指导实现者提供适当的 本地化包装。
这是本节要求的汇总列表，可用于自我审查。对于与你的规范相关的所有要求， 选择相应行中的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后单击“为 GitHub 创建 Markdown”按钮，并将结果复制到 GitHub 议题列表中。请参阅更多详细信息。
竖排文本
before 和 after
行位置。更多vertical- 值等效的（仅限此类）书写模式，应使用
[UTR50] 应用字符的默认文本方向。
（这不适用于与 CSS 中 sideways-
等效的书写模式。）更多
sideways-lr 和 sideways-rl 的值，以允许水平书写体系的文本行进行垂直旋转。
UTR50 不适用于这些情况。更多
从右到左／双向文本
文本方向变化时设置框定位坐标
逻辑属性（待定）
注音文本标注
字体管理（待定）
下划线和上划线等文本装饰应允许线条避开字形。
应当能够指定上划线和下划线与文本之间的距离。
让下划线等文本装饰避开字形可能不适合某些文字体系，例如阿拉伯文更倾向于将下划线 移到离基线更远的位置。
应当能够为日语、中文、韩语、蒙古语等语言竖排呈现文本。
竖排文本必须支持从左到右（例如蒙古文）和从右到左 （例如日文）的行进方向。
默认情况下，对于行从左向右堆叠的竖排文本（例如蒙古文），
文本装饰、注音及类似内容应与 CJK 竖排文本出现在同一侧。
其放置不应依赖 before 和 after
行位置。
书写模式应提供类似 CSS 中 sideways-lr 和 sideways-rl
的值，以允许水平书写体系的文本行进行垂直旋转。UTR50 不适用于这些情况。
默认情况下，通常水平书写的文字体系的字形应沿竖排文本的行排列， 使字符顶部朝向竖行的右侧；但还应提供一种机制，使其能够以直立方向沿行向下排列。 这种机制应使用视觉文本单元（例如字素簇） 作为最小文本单元，但在必要时，如果音节簇涉及多个字素簇，应允许将音节簇作为一个单元处理。
竖行中的直立阿拉伯文应使用独立字母形式，文本顺序应从上到下阅读。
应当能够使某些字符序列（尤其是数字）在竖行内横向排列（纵中横）。
允许字形倾斜的规范应当根据具体语言的需要， 支持字符向右或向左倾斜。
框定位坐标必须考虑文本是横排还是竖排。
对用户界面或网页进行本地化时，通常会为从右到左和从左到右版本创建镜像布局。
例如，包含英文内容且出现在窗口左侧附近的框，在内容为阿拉伯文或希伯来文时，
很可能会出现在窗口右侧附近。除非有充分理由使用绝对几何位置，
否则最好根据当前上下文的基本方向自动进行这种变化。一种实现方法是使用
start 和 end
等关键字，而不是使用 left 和 right
来表示位置。
对阿拉伯文、蒙古文和西非书面字母等连写文本的相连字母应用透明度时， 不应显露重叠部分。
添加文本描边或阴影时，连写文字体系中的相连字母不应与相邻字母分离。
对中文、日文、韩文和蒙古文，应在横排和竖排书写模式下支持基本文本旁的 “Ruby”式标注。
注音实现应支持繁体中文的注音符号 Ruby。
注音实现应支持表格式内容模型
（使注音内容能够按照近似 rb rb rt rt 的序列排列）。
注音实现应允许使用显式元素表示注音基文本，
例如 HTML 中的 rb 元素。
注音实现应允许标注出现在基本文本的一侧或两侧。
HTML 中的注音标记专为中文、日文、韩文和蒙古文的需求而设计， 不应将其用作通用的释义机制。
行高必须容纳比英文字符更高的字符。
框尺寸必须允许翻译造成的文本扩展。
换行应考虑非拉丁文字体系所需的特殊规则。
各种非拉丁书写体系并不只是简单地在单词之间的空格处换行。 它们还有必须遵守的其他规则。例如：
有关其他背景信息，请参阅 CSS 文本第 3 级规范。（如有需要，本教程 提供了其他示例。）
最好避免使用表现性标记 b、i 或 u，因为它们无法在各种
书写体系间实现互操作，并且可能给本地化造成不必要的问题。此外，
某些文字体系具有自身的强调方式，不涉及粗体、斜体等，并且可能与这些方式截然不同。
对于 HTML，存在历史遗留问题；但除非你的规范也存在此类问题，否则建议改用样式确定文本的 呈现方式，并使所有标记或标签支持通用的语义方法。
有关 b 和 i 标签相关问题的说明，请参阅使用 <b> 和 <i>
元素。
这是本节要求的汇总列表，可用于自我审查。对于与你的规范相关的所有要求， 选择相应行中的第一个复选框。如果你的规范满足该要求，则选择第二个复选框。 然后单击“为 GitHub 创建 Markdown”按钮，并将结果复制到 GitHub 议题列表中。请参阅更多详细信息。
处理受区域设置影响的值
处理时间
处理人名
处理数字
设计表单
用户输入（待定）
创建示例（待定）
本地化
支持语言和文化偏好的软件系统称为“国际化”系统。国际化系统使用 API， 根据用户偏好提供语言或文化特定的处理。这些用户偏好通常称为“区域设置”。 有关一般国际化术语的更多信息，请参阅语言标签和区域设置标识符 [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 之间 （也就是说，该分钟有六十一秒）。
讨论日期和时间值时使用一致的术语。 对不依赖时区的值使用“浮动”时间。
将时区的定义与时区偏移量分开。
使用 IANA 时区 ID 标识时区。不要使用偏移量或 LTO 代替时区。
使用单独的字段标识时区。
定义“一周”的规则时，允许应用特定文化的规则。
例如，周末并不总是星期六和星期日；一周的第一天也不总是星期日 （或星期一，或其他日期）等。
定义一年中周数的规则时，允许应用特定文化的规则。
允许使用非公历时，请注意“月份”字段可能达到 13（第十三月）。
创建使用人名的应用程序（Web 表单、数据库、本体等）的开发者， 往往不了解其他国家的姓名可能有多么不同。他们构建表单或数据库时， 对外国用户作出了过多假设。本节提供处理世界各地人名的指南。
世界各地姓名的组成和各部分顺序差异很大（请参阅世界各地的人名）。 例如，如果尝试将一个人的姓名拆分成较小部分以存储到数据库中， 然后再尝试检索这些部分，尤其是在需要重新组合时，就可能遇到困难。 这些困难包括理解姓名的哪一部分应放入哪个数据库字段 （尤其是姓名部分多于或少于数据库字段时），以及从数据库中检索某人的姓名以供实际使用时， 如何处理姓名各部分的顺序。
如果设计的表单或数据库将接收来自不同背景人群的姓名， 应考虑是否确实需要为名字和姓氏等内容设置单独字段。 这取决于需要如何使用数据，但显然，在可行的情况下， 直接使用用户提供的完整姓名会更简单。
请记住，某些文化中的姓名可能比你的姓名长得多。字段应足够长，以便输入较长的姓名。 也不要假定姓名一定包含一个以上的字母。
尤其应避免以字节计数长度（请参阅4.2 选择 “字符串”的定义）——不要假定 UTF-8 中由四个字符组成的日文姓名能放入四个字节； 实际上很可能需要 12 个字节。
当已经决定必须拆分一个人的姓名以便存储或呈现时，适用本节中的指南。
对于通常先写姓氏、后写名字的人而言，“第一个”和“最后一个”这样的术语可能会造成混淆。 虽然对于面向美国用户的表单，使用“第一个”和“最后一个”看似可以接受， 但这些表单最终可能被具有不同文化背景的人使用，包括美国境内及境外的用户。
还应注意，在某些文化中，这种做法仍然存在问题。例如冰岛人实际上没有姓氏， 而是有名字和父名（请参阅名字和 父名）。不过，除非进行高度本地化的定制，否则对于通用解决方案而言， 这可能已经是最好的做法。
例如，在某些情况下，你可能希望识别姓名的某些部分， 以便按字母顺序排列姓名列表，或在联系对方时称呼他们等。
这个额外字段也有助于从较长的姓名组成部分列表中找到合适的称呼， 以及处理昵称（例如在泰国，人们通常使用昵称来称呼他人）。
有时你可能会选择设置单独字段，因为希望能够使用姓名的一部分直接称呼或提及此人。 例如，社交媒体应用提到“David 的联系人”时。或者，你可能希望向他们发送 顶部带有其姓名的电子邮件。请注意，此处不仅可能因姓名语法而遇到问题， 还必须考虑世界各地对正式程度的不同预期 （并非所有人都乐于被陌生人直呼其名）。例如，在设置个人资料时， 最好单独询问此人希望如何被称呼。
例如，不要假定用户提供姓名的顺序一定是先“名字”后“姓氏”； 也不要假定对于由多个单词组成的姓名，一定能够识别哪个部分属于这些类别， 哪些部分又表示完全不同的内容，例如父亲的姓名、村庄名称、氏族名称等。
例如，v-card 和 h-card 的隐式“n”优化方法可能难以处理中文姓名。 输入表单应尽可能清楚地告诉用户如何填写姓名， 以便采集你认为所需的数据。
确实有人拥有仅一个字母的姓名。如果表单验证器拒绝接受他们的姓名， 并要求他们提供完整姓名，这些人就会遇到问题。如果希望鼓励人们不要使用首字母缩写， 可以将其设为警告消息，而不是阻止提交表单。
在印度南部部分地区、马来西亚和印度尼西亚等文化中， 许多人的姓名只有名字，没有父名。如果要求必须填写姓氏， 可能会给这些文化中的用户造成严重问题，因为用户为了通过表单， 只能在姓氏字段中输入“.”或“先生”等无意义数据。
这可以确保正确处理 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”）包含不大写的单词。 表单应保留用户输入的大小写，而不应强制此类姓名始终或仅在每个单词开头使用大写字母。
这样才能正确采集 Gabriel García Márquez 这样的姓氏 （姓氏为 García Márquez），或 José María Olazábal 这样的名字 （姓氏为 Olazábal）。
假定同一家族的成员使用相同姓氏是错误的。在西方， 个人结婚后保留自己姓名的趋势日益普遍；而在中国等其他文化中， 这本来就是常见做法。在某些国家，妻子可以选择是否采用丈夫的姓氏。
处理西班牙语姓名时，可能只有家中的孩子拥有相同的姓氏组合， 但他们的姓氏组合与父母双方都不同。Manuel Pérez Quiñones 的姓氏 （Pérez Quiñones）源自父亲的姓氏 Pérez Rodríguez 和母亲的姓氏 Quiñones Alamo。后来，他与一位姓氏为 Padilla Falto 的女孩交往。 他们结婚后，她的姓氏变为 Padilla de Pérez。他们的孩子姓 Pérez Padilla， 依此类推。
也不应简单假定姓名采用总是从丈夫传给妻子。有时男性结婚后会采用妻子的姓氏。 在这种情况下，表单使用“曾用名”可能比使用“婚前姓氏”或“原姓”更合适。
你可能需要同时以拉丁文字和本族文字存储姓名， 在这种情况下，需要让用户分别提交本族文字形式和仅使用拉丁文字的姓名。
世界各地的人名中的对字符支持的 影响。
世界各地的人名中的差异示例。
是否需要多个字段，在一定程度上取决于收集姓名的目的，以及准备如何使用这些姓名。
例如，日本用户可能需要提供使用日本音节文字书写的姓名转写， 以替代或补充表意文字形式。该字段用于对日文姓名进行排序， 也可以让查看姓名的人确认其读音。
在尝试强制使用真实姓名时，不要阻止不常见或不符合预期的姓名。
不难找到有人因姓名不符合开发者预期而无法使用某项服务的例子。 如果计划强制使用真实姓名，就需要提供一种机制， 让姓名罕见或结构不符合预期的人能够验证其真实姓名。
在包含人名示例的标准及标准相关文档中， 使用多样化的姓名来反映全球受众。避免偏向特定地区的姓名。
许多规范提供用户故事或用例等示例，并使用人名增强叙述效果。 某些组织甚至形成了惯例，例如安全规范使用“Alice”和“Bob”这两个姓名， 以保持一定程度的一致性。构建系统和服务时，包容性应是重要目标， 因此建议在示例中使用来自世界各地的多样化姓名。 这有助于确保我们的技术能够代表全球用户群体， 并使规范与全球用户显得更加相关。
应尽量选择代表世界不同地区人群的姓名，而不是只使用少数源自欧洲的姓名。 请注意，选择包含非 ASCII 字符的姓名，可以提醒实现者： Unicode 支持和其他国际化问题同样适用于他们的用户。
任何姓名集合都不可能在处理文化和性别相关问题时完全中立。 为帮助规范作者创建更具包容性的示例，本文档提供了从多种文化中选取的姓名集合。 这些姓名大致按地区组织，通常会注明国家或语言。 请注意，即使在这些地区内部，人名的处理方式也受到非常多样的影响，并存在不同惯例。 姓名还按照文化上的性别关联进行划分，以帮助规范作者编写示例， 不过许多姓名并不专属于任何特定性别。
在英语示例中插入其他文化的人名，也会受到世界各地姓名使用方式差异的影响。 例如，某些文化希望在名字之外使用父名或母名； 某些文化则偏好更正式的称呼 （例如“Herr Dürer”，而不是非正式的“Albrecht”）。
中文姓名几乎不会只使用名字而不包含姓氏。用中文编写示例时， 可能会看到类似 路人甲 的名称 （表示“人物甲”，使用天干序号；参见预定义计数器 样式），而不是“示例姓名”。使用真实姓名作为示例时， 姓氏和名字都会包含在内。请记住，在中文中，姓氏位于名字之前。
在日语中，正式程度涉及复杂的选择。在非常不正式的情况下，
可能会直呼一个人的名字（Hiroshi）；
但通常会使用姓氏称呼，并且除非有意无礼，还会加上称谓或后缀，
例如 -san 或 -sama
（例如 Tanaka-san）。还会使用其他后缀或称谓，
例如 senpai 或 sensei
（用于资深或极受尊敬的人），以及 shi（用于不熟悉的人）。
因此，英语示例中的
Suppose Hiroki wants to set up a...
如果改为
Suppose Tanaka-san wants to set up a...
可能在文化上更合适。
下表由国际化工作组编制。欢迎贡献内容以及提出增补或更正建议。
本姓名集合旨在帮助通常面向英语受众编写文档的规范作者。 该集合主要由名字组成，并在必要时转写为拉丁文字。 这些姓名还采用非正式形式呈现 （例如使用“Alice”，而不是“Jones 女士”）， 即使在许多文化中，人名并不会这样使用。翻译规范时， 应根据目标受众进行适当调整。
当姓名取自非拉丁文字语言或文化时，还会提供非拉丁文字形式， 以提醒人们姓名绝不限于拉丁文字；也可用于需要包含非拉丁文字示例的情况。
单击标题行中的 △ 或 ▽ 箭头可对此表进行排序。
| 姓名 △▽ | 本族文字 △▽ | 性别 △▽ | 地区和说明 △▽ | 语言 △▽ |
|---|---|---|---|---|
| Akamu | 男 | 大洋洲；波利尼西亚；夏威夷姓名 | haw | |
| Alinta | 女 | 大洋洲；澳大利亚原住民姓名 | nys | |
| Amélie | 女 | 欧洲；法国 | fr | |
| An | 杏 | 女 | 东亚；日本 | ja |
| Aoi | 葵; 蒼; 碧 | 女、男 | 东亚；日本 | ja |
| Aroha | 女 | 大洋洲；毛利 | mi | |
| Åsa | 女 | 欧洲；瑞典 | sv | |
| Asahi | 朝陽 | 男 | 东亚；日本 | ja |
| Atlahua | 男 | 拉丁美洲；纳瓦特尔姓名 | nah | |
| Beata | 女 | 欧洲；多个国家 | it, de, pl, sv 等 | |
| Chanda | चंदा | 女 | 南亚；源自梵语 | sa |
| Chirapathi | சிரபதி | 女 | 南亚；泰米尔 | ta |
| Citlali | 女 | 拉丁美洲；纳瓦特尔 | nah | |
| Coen | 男 | 欧洲；荷兰；也可见于大洋洲（澳大利亚原住民）或希伯来姓名 | nl, he, nys | |
| Daisho | 大翔 | 男 | 东亚；日本 | ja |
| Dara | 女 | 西亚；欧洲；土耳其 | tr | |
| Eva | Е́ва | 女 | 欧洲；俄罗斯 | ru |
| Faheem | فهيم | 男 | 西亚；阿拉伯语 | ar |
| Fátima | فَاطِمَة | 女 | 西亚；阿拉伯语；拉丁文字形式也用于多种欧洲文化 | ar |
| Genet | ገነት | 女 | 非洲；埃塞俄比亚 | am |
| Haruto | 陽翔 | 男 | 东亚；日本 | ja |
| Haukea | 女 | 大洋洲；波利尼西亚；夏威夷姓名 | haw | |
| Himari | 陽葵 | 女 | 东亚；日本 | ja |
| Hina | 陽菜 | 女 | 东亚；日本 | ja |
| Hīnano | 男 | 大洋洲；波利尼西亚；塔希提 | ty | |
| Hua | 李华 | 男 | 东亚；中国 | zh-Hans |
| Iakopo | 男 | 大洋洲；萨摩亚 | sm | |
| Ilango | இளங்கோ | 男 | 南亚；泰米尔 | ta |
| Irepani | 男 | 拉丁美洲；普雷佩查语 | tsz | |
| Işık | 女 | 西亚；欧洲；土耳其 | tr | |
| Işıtan | 男 | 西亚；欧洲；土耳其 | tr | |
| Itsuki | 樹 | 男 | 东亚；日本 | ja |
| Jarra, Jarrah, Cerrah | جراح | 男 | 西亚；阿拉伯语 | ar, tr |
| Jean-François | 男 | 欧洲；法语 | fr | |
| João | 男 | 拉丁美洲；巴西 | pt-BR | |
| Júlía | 女 | 欧洲；冰岛 | is | |
| Kai | 女、男 | 大洋洲；澳大利亚；出现在许多语言中，是一个良好的通用示例 | aus, sm | |
| Khaliun | 女、男 | 东亚；蒙古 | mn | |
| Kylie | 女 | 大洋洲；澳大利亚原住民姓名 | aus | |
| Lani | 女 | 大洋洲；菲律宾 | fil | |
| Lei | 李雷 | 男 | 东亚；中国 | zh-Hans |
| Livia | 女 | 欧洲、拉丁美洲 | es | |
| Lowanna | 女 | 大洋洲；澳大利亚原住民 | aus | |
| Lucas | 男 | 拉丁美洲 | es | |
| Maevarau | 男 | 大洋洲；萨摩亚 | sm | |
| Mahmut | 男 | 西亚；欧洲；土耳其 | tr | |
| Martina | 女 | 拉丁美洲 | es | |
| Mei | 芽依（ja）；梅
（zh） |
女 | 东亚；中国；日本 | ja, zh |
| Minato | 湊 | 男 | 东亚；日本 | ja |
| Mio | 澪 | 女 | 东亚；日本 | ja |
| Miriam | מרים | 女 | 西亚；希伯来语 | he |
| Müge | 女 | 西亚；欧洲；土耳其 | tr | |
| Muhammad | محمد | 男 | 西亚；阿拉伯语；存在许多变体和语言形式。 | ar |
| Ngatemi | 女 | 大洋洲；印度尼西亚 | id, ms | |
| Onosaʻi | 女 | 大洋洲；萨摩亚 | sm | |
| Potira | 女 | 拉丁美洲；巴西；原住民姓名 | gn | |
| Qiàn | 倩 | 女 | 东亚；中国 | zh-Hans |
| Rattiya | รัตติยา | 女 | 东南亚；泰国 | th |
| Ren | 蓮 | 男 | 东亚；日本 | ja |
| Rin | 凛 | 女 | 东亚；日本 | ja |
| Ritthichai | ฤทธิชัย | 男 | 东南亚；泰国 | th |
| Santiago | 男 | 拉丁美洲 | es | |
| Senthil | செந்தில் | 男 | 南亚；泰米尔 | ta |
| Sione | 男 | 大洋洲；汤加 | to | |
| Slobodan | Слободан | 男 | 欧洲；塞尔维亚语 | sr |
| Sofia | 女 | 欧洲；拉丁美洲 | es | |
| Tahnee | 女 | 大洋洲；澳大利亚原住民 | aus | |
| Tamizhachi | தமிழச்சி | 女 | 南亚；泰米尔 | ta |
| Temuera | 男 | 大洋洲；波利尼西亚 | sm | |
| Thị Anh | 女 | 东南亚；越南 | vi-VN | |
| Tuulikki | 女 | 欧洲；芬兰 | fi | |
| Uriel | אוּרִיאֵל | 男 | 西亚；希伯来语 | he |
| Văn Hoa | 男 | 东南亚；越南 | vi-VN | |
| Vasa | 男 | 大洋洲；萨摩亚；欧洲；Vasilije／Василије 的昵称形式 | sm, hr, sr | |
| Vassilios | Βασίλειος | 男 | 欧洲；希腊语 | el |
| Voula | Βούλα | 女 | 欧洲；希腊语 | el |
| Wafaa | وفاء | 女 | 西亚；阿拉伯语 | ar |
| Wissam | وسام | 男 | 西亚；阿拉伯语 | ar |
| Xiaoxia | 晓霞 | 女 | 东亚；中国 | zh-Hans |
| Xóchitl | 女 | 拉丁美洲；纳瓦特尔 | nah | |
| Yevdokia | Евдокия | 女 | 欧洲；俄罗斯 | ru |
| Yevgeny | Евгений | 男 | 欧洲；俄罗斯 | ru |
| Zafirah | زفره | 女 | 西亚；阿拉伯语 | ar |
解析用户输入的数值时，允许数字字形变换（非 ASCII 数字）。
格式化用于显示的数值时，允许使用符合文化习惯的显示方式， 包括非 ASCII 数字（数字字形变换）。
定义自动以递增方式为向用户显示的项目添加标签的功能时 （例如创建编号列表），应允许对标签进行本地化呈现， 并支持各种计数／列表系统或样式。
相关示例可见于CSS 计数器样式 [css-counter-styles-3]， 尤其是配套的预定义计数器样式 [predefined-counter-styles]。
定义电子邮件字段验证时，允许使用 EAI（smtputf8）名称。
本地化 [LTLI] 使用户能够使用其选择的语言和 区域设置操作软件。协议和文档格式规范需要考虑如何提供最终用户所期望的语言和格式。
自然语言数据值需要语言和基本方向信息，才能确保正确呈现， 即使未提供本地化消息也是如此。这包括 API 或协议中任何人类可读的错误消息或其他内部消息。 另请参阅 [STRING-META]。
规范可以为 API 或协议中的消息或错误定义特定的 默认语言。
规范不需要要求以所有可能或所有可用的区域设置返回消息。 只需使最终用户的使用体验能够本地化即可。实现可以选择支持哪些语言或区域设置。
协议、API 和文档格式有时会提供一个字段， 以字符串形式将人类可读的错误或异常消息从服务传递给调用方。 通常，正如上文所述， 任何传达人类可读消息或内容的自然语言文本，都需要关联语言和方向元数据。 如果缺少这些元数据，文本的处理或显示可能会受到影响。
规范作者提供错误或异常消息的目的，通常是向软件开发者传递调试信息。 规范作者有时会假定最终用户看不到错误或异常消息； 软件开发者更喜欢这些消息未经本地化，或以特定语言（通常是英语）显示； 或者存在其他“实际原因”，使错误消息的本地化成为障碍。 例如，有一种说法是，开发者发现使用错误中通常晦涩的文本搜索 Web 更容易， 因为消息本身不足以清楚说明问题。搜索该文本可能会产生使用开发者偏好语言编写、 且更有帮助的结果。
错误消息是消息，其目标是人类，而不是机器。在许多情况下， 错误消息包含有关出错原因的所有附加信息；在某些情况下， 调用方还必须向实际最终用户显示该消息，因为除此之外没有其他方法告诉调用方如何修复问题 （“你的信用卡已过期”；“值 10484977 过大”[糟糕，忘记了小数点]；等等）。 对这类消息进行本地化实际上是有益的，在某些应用程序中甚至可能是强制要求。
API 和协议应当为错误提供与语言无关的标识符。
例如，熟悉的 404 等 HTTP 结果代码有助于用户说明收到的是哪种错误，
或查找相应翻译。
如果提供自然语言错误消息字段，该字段应当为可选，并且应当 包含语言和方向元数据。
如果提供自然语言错误消息字段， 应尽可能使其与为请求协商的用户界面语言相匹配。
以下内容概述了自上次发布以来的实质性更改，但随着文档继续发展， 这些内容仍可能发生重大变化。这不应成为不使用本文档的理由。本文档目前包含的内容是有用的， 任何不足都可以报告或讨论。
有关更多详细信息，请参阅 GitHub 提交日志。
感谢 Addison Phillips 协助审查以往审查意见中的建议。
其他通过审查或议题作出贡献的人包括 Steve Atkin、 Andrew Cunningham、 Martin Dürst、 Asmus Freytag、 John Klensin、 Tomer Mahlin、 Chaals McCathieNevile、 Florian Rivoal、 Najib Tounsi。 关于与区域设置无关的表示形式的部分材料改编自 [DWBP]。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: