Unicode®技术标准#39

Unicode安全机制

总结

因为Unicode包含如此大量的字符和融合了世界上不同的书写系统，不正确使用可能会使程序或系统受到可能的安全攻击。本文档规定了可用于检测的机制可能的安全问题。

状态

本文档已由Unicode成员和其他感兴趣的各方，并已被Unicode批准出版联合体。这是一份稳定的文件，可以用作参考材料或被其他规范引用为规范性参考。

Unicode技术标准（UTS）是独立的规范。符合Unicode标准并不意味着符合任何UTS。

请在网上提交更正和其他意见报告表[反馈].有助于理解本文档的相关信息是在中找到工具书类。最新消息Unicode标准的版本，请参见[Unicode码]. 对于当前Unicode技术报告列表，请参见[报告]. 更多信息有关Unicode标准版本的信息，请参阅[版本].

目录

• 1介绍
• 2一致性
• 三标识符字符
  • 3.1概述标识符的安全配置文件
    • 表1。标识符状态和标识符类型
    • 3.1.1连接控件
  • 3.2IDN安全标识符的配置文件
  • 3.3电子邮件标识符的安全配置文件
• 4易混淆检测
  • 4.1完整脚本令人困惑的
  • 4.2混合脚本令人困惑的
• 5检测机制
  • 5.1混合脚本检测
    • 表1a。混合脚本示例
  • 5.2限制级别检测
  • 5.3混合编号检测
  • 5.4可选检测
• 6开发过程
  • 6.1可混淆数据收藏
  • 6.2标识符修改数据收集
• 7数据文件
  • 表2。数据文件列表
• 迁移
  • 表3。版本通信
  • 正在迁移持久数据
  • 8.0版迁移
  • 7.0版迁移
• 致谢
• 工具书类
• 修改

1介绍

Unicode技术报告#36，“Unicode安全性注意事项”[UTR36标准]提供检测和避免安全问题的指南与Unicode的使用有关。本文件规定了机制在该文档中使用的，并且可以在其他地方使用。读者应该熟悉[UTR36标准]之前持续的。另请参阅上的Unicode常见问题解答安全问题[常见问题解答].

2一致性

声明符合此规范的实现必须遵守以下条款：

C1类 声称实现的实现标识符的通用配置文件应按照第3.1节中的规范，标识符的通用安全配置文件.

或者，应声明其使用了修改，并提供添加到或中的字符的精确列表从配置文件中删除。

第1.1条 声称实现的实现标识符的IDN安全配置文件应按照第3.2节中的规范，标识符的IDN安全配置文件.

或者，应声明其使用了修改，并提供添加到或中的字符的精确列表已从配置文件中删除。

第1.2条 声称实现的实现标识符的电子邮件安全配置文件应按照第3.3节中的规范，标识符的电子邮件安全配置文件.

或者，应声明其使用了修改，并提供添加到或中的字符的精确列表从配置文件中删除。

指挥与控制 声称实现的实现以下任何一个易混淆的检测函数都必须在符合第4节中的规范，易混淆检测.

1. X和Y是单脚本可混淆的
2. X和Y是混合脚本可混淆的
3. X和Y是整个脚本的混淆
4. X在脚本集S中有全脚本可混淆

或者，应声明其使用了修改，并提供添加到或从提供的文件中删除。

C3类 声称检测的实现混合脚本必须按照第5.1节，混合脚本检测.

或者，应声明其使用了修改，并提供以下方面差异的精确说明行为。

补体第四成份 声称检测的实现限制等级必须符合第5.2节，限制级别检测.

或者，应声明其使用了修改，并提供以下方面差异的精确说明行为。

C5级 声称检测的实现混合数字必须符合第5.3节，混合数字检测.

或者，应声明其使用了修改，并提供以下方面差异的精确说明行为。

三标识符字符

标识符（“ID”）是应用程序上下文中使用的字符串指在给定应用程序中具有一定意义的特定实体。在一个给定应用程序，标识符最多映射到一个特定实体。许多应用程序都有与标识符相关的安全要求。一个常见的例子是指向页面的URL或Internet上的其他资源：当用户希望访问资源，重要的是用户可以确定他们的资源正在与交互。例如，他们需要知道他们正在与特定的金融服务，而不是欺骗恶意服务。这说明了标识符的一般安全问题：字符串的潜在模糊性。虽然机器很容易区分任何两种不同的字符序列，人类可能很难如果应用程序没有限制标识符中可以包含Unicode字符。本规范的重点是缓解此类相关问题标识符的安全性。

故意限制标识符中可以使用的字符是一种重要的安全技术。从标识符中排除字符不会影响将这些字符用于其他目的，例如用于文档中的一般文本。Unicode标准附件#31，“Unicode标识符和模式语法”[UAX31型]提供了一种建议的方法来确定哪些字符串应该符合标识符的条件。UAX#31规范扩展了通用用字母和数字定义标识符的实施规程Unicode曲目。

该规范还允许其他协议使用该方法作为基础，并定义轮廓添加或删除字符。例如，特定编程的标识符语言通常会添加一些字符，如“$”，以及删除其他类似“-”的内容（因为将用作减),IDNA删除“_”（以及其他）-请参阅Unicode技术标准#46，“Unicode IDNA兼容性正在处理“[UTS46标准]，以及[IDNA2003年]、和[IDNA2008年].

本文档为存在安全问题的环境。这些是基于的属性和规范的扩展标识符Unicode标准[Unicode码]包括：

• 中定义的XID_Start和XID_Continue属性Unicode字符数据库（请参见[D芯])
• 中定义的toCasefold（X）操作第章3、合规性第页，共页[Unicode码]
• 中定义的NFKC和NFKD规范化第章3、合规性第页，共页[Unicode码]

定义这些配置文件时使用的数据文件遵循UCD文件格式，它具有以分号分隔的数据字段列表与给定字符关联，每个字段由数字。有关更多详细信息，请参阅[UCD格式].

3.1通用安全配置文件标识符

下的文件[身份识别模块]为配置文件提供数据存在安全问题的环境中的标识符。文件包含一组建议禁止使用的字符。它们还包含一组建议用作XID_Start和XID_Continue属性，因为它们可能用于比编程标识符更广泛的上下文。

受限字符是不常用的字符，以及它们可以被阻挡，以进一步减少可视的可能性混乱。它们包括以下内容：

• 不在现代使用的字符
• 仅在专用字段中使用的字符，例如礼拜式字符、拼音字母和数学字母状符号
• 极少数社区有限使用的字符

将哪些字符指定为受限字符的选择以保守方式开始，但允许添加在未来，随着对字符的要求不断完善。有关处理修改的信息随着时间的推移，请参阅2.10.1，向后兼容性在里面Unicode技术报告#36，“Unicode安全注意事项”[UTR36标准].

通用安全配置文件之后的实现不会允许\p｛Identifier_Status＝Restricted｝中的任何字符，除非它记录它允许的其他字符。此类文档可以通过属性（例如\p{Identifier_Status=Technical}）、显式列表或这些属性的组合来指定字符。实现还可以指定允许的字符数少于\p{Identifier_Status=Restricted}；例如，它们可以将字符限制为[IDNA2008年].

此类的常见候选人新增内容包括中列出的脚本字符表7，有限使用脚本第页，共页[UAX31型]. 然而，这些脚本中的字符对于检查混淆或确定专业、非现代、，或不常用字符。

测试候选标识符时应用规范等效用于包含允许字符。例如，假设候选字符串是序列

<u，合并透析>

目标字符串将在中被允许任何一个的以下2种情况：

1. 允许u和¨允许，或
2. 允许使用ü

有关的格式的详细信息[身份识别模块]文件，请参见第7节，数据文件.

表1。标识符状态和标识符类型

注：在Unicode 15.0中，Joiner_Control字符（ZWJ/ZWNJ）已从标识符_类型=包容性.因此，它们具有以下特性标识符_类型=默认可忽略和标识符_状态=受限制的.它们包含在编程语言标识符配置文件中具有可用性和安全性的含义。

希望保留ZWJ和ZWNJ的标识符通用配置文件的实现应声明其根据使用配置文件的修改第2节，合规性,并应确保他们执行第3.1.1节，连接控制.

标识符状态和标识符类型是字符（代码点）的属性。请参见UTS#18:Unicode正则表达式[UTS18标准] 和UTR#23：Unicode字符属性模型[德国标准23]对于更多讨论。

有关稳定性注意事项，请参见正在迁移持久数据.

限制一个字符可能有多种原因；因此，Identifier_Type属性允许与受限制的。例如，某些字符的Identifier_Type值为限制使用和技术。多个值未分配给具有强限制的字符：not_Character、Deprecated、Default_Ignorable、not_NFKC。对于例如，如果一个字符被弃用，那么在将其标记为Uncommon_Use。对于使用上的限定符，Obsolete，不常见的用法和技术，Identifier_Type值之间的区别并不严格可能只给出一个。重要特征是Identifier_Status：字符是否受限。

如果没有其他类别适用，则默认的Identifier_Type属性值应为Uncommon_Use。

作为更多收集有关字符的信息，此数据可能会在后续版本。这可能导致Identifier_Status或Identifier_Type更改特定字符。因此这些数据应该为后续版本中的更改做好准备，例如就像之前制定了祖父政策一样支持的字符或注册。两个标识符_状态与Identifier_Type值进行比较区分大小写，忽略连字符和下划线。

考虑在标识符中可能使用的限制字符时，应谨慎对待，除非有充分的理由允许他们进入环境问题。然而，Identifier_Status集=Allowed实现通常不按原样使用字符。相反，它们作为过滤器应用于字符集C由标识符语法支持，生成新的集合C′。通常也有特定的字符或类别C中的字符保留为例外字符。

C′=（C{Identifier_Status=允许}）↓例外

该实现可能只是将新标识符的使用限制为C′，或者可能应用其他策略。例如，可能有一个包含字符的id注册的上诉流程在C′外（但仍在C内），或在用户界面中查找标识符、某种警告可能是合适的。对于更多信息，请参阅[UTR36标准].

这个例外字符将是具体实施。例如，一个特定的实现可以通过添加例外具有Unicode属性的字符XID_Continue=假,例如“$”、“-”和“.”。这些字符是特定的标识符语法，即使它们不在Identifier_Status=Allowed集合。一些实现可能还希望添加一些[CLDR公司]具有以下特性的特定支持语言的示例字符不寻常的字符。

Identifier_Type=已包含字符包含一些不是字母或数字的字符，但它们是在某些语言的单词中使用。例如，建议标识符中允许使用U+00B7（·）中间点，因为它是加泰罗尼亚语要求。

实施还可能应用讨论的其他限制在本文档中，例如检查易混淆的字符或混合脚本检测。

3.1.1连接控件

通用安全配置文件之后允许附加字符ZWJ和ZWNJ的实现只允许它们出现在满足中的条件A1、A2和B第2.3.1节，Joiner控件的有限上下文第页，共页[UAX31型]，除非它记录它允许的其他上下文。

更高级的实现可以使用特定于脚本的信息进行更详细的测试。特别是，他们可以：

1不允许连接控件在满足A1、A2和B条件的序列中，在普通字体中，序列的结果外观通常与删除连接控件后的相同序列中的外观没有区别。

2允许连接控件在不满足A1、A2和B条件的序列中（例如以下），在常见字体中，序列的结果外观通常与删除连接控件后相同序列中的外观不同。

/$L ZWNJ$V$L/

/$L ZWJ$V$L/

符号来自[UAX31型].

3.2国际域名标识符的安全配置文件

本文件第1版定义了适用于[IDNA2003年]，已被取代[IDNA2008年]和Unicode技术第46号标准，“Unicode IDNA兼容性正在处理“[UTS46标准]. 标识符修改数据可应用于任何IDNA规范正在使用。有关更多信息，请参阅[国际域名常见问题].

然而，实现可以声明与的其他功能的一致性此文档适用于域名，例如限制级别.

3.3标识符的电子邮件安全配置文件

这个用于国际化电子邮件的SMTP扩展提供国际化电子邮件地址的规范[EAI公司]. 然而，它并没有提供对这些地址进行安全问题测试的功能。本节提供了可用于此目的的电子邮件安全配置文件。它可以用于不同的目的，例如：

1. 注册电子邮件地址时，标记以下内容不符合配置文件：
   • 要么禁止注册，要么
   • 允许申诉程序。
2. 当在普通链接中检测到电子邮件地址时文本：
   • 如果标识符不符合，则不进行链接个人资料。
3. 当收到的电子邮件中显示电子邮件地址时：
   • 用波浪下划线将其标记为可疑，如果不符合配置文件。
   • 筛选引用字符串部分中的字符以防止显示问题。

此配置文件不排除是的。相反，它提供了一个可用于注册、链接、，和通知。目标是旗帜鲜明“结构不健全”和“意外”垃圾”地址。

电子邮件地址由三个主要部分组成。（电子邮件地址中有更多的元素，但Unicode安全性对这些元素很重要。）例如：

“乔伊”<joe31834@gmail.com>

• 这个域部分是“gmail.com”
• 这个本地部分是“joe31834”
• 这个引用字符串部分是“乔伊”

为了满足标识符的电子邮件安全配置文件在本规范第节中，标识符必须满足以下要求指定<限制级别>的条件。

域-部件

电子邮件地址的域部分必须满足第3.2节，国际域名标识符的安全配置文件，并满足一致性的条款[UTS46标准].

本地部件

电子邮件地址的本地部分必须满足以下所有条件：

1. 它必须是NFKC格式
2. 它必须具有级别=<限制级别>或更低，从限制级别检测
3. 根据混合编号检测
4. 它必须满足点-原子-文本从副本请求5322 §3.2.3，其中atext（文本）扩展如下：

当C≤U+007F时，C的定义如下§3.2.3. （即C∈[!#-'*+\-/-9=?A-Z\^-~].此列表复制了§3.2.3中已有的内容，并遵循HTML5对于ASCII。）

当C>U+007F时，以下两种情况均为真：

1. C具有Identifier_Status=Allowed from通用_安全_配置文件
2. 如果C是第一个字符，它必须是XID_Start from默认标识符语法英寸[UAX31型]

请注意，在副本请求5322 §3.2.3:

点-原子-文本=1*atext*（“.”1*atext）

也就是说，点也可以出现在本地部分，但是不领先、不落后或不连续两个。在更传统的正则表达式语法中，这将是：

点-原子-文本=atext+（“.”atext+）*

注意，双向控件和其他格式字符是根据以上。

引用字符串部分

电子邮件地址的引用字符串部分必须满足以下条件：

1. 它必须在NFC中。
2. 它不能包含任何有状态的双向格式字符。
   • 也就是说，除了LRM、RLM和ALM之外，没有[：bidcontrol:]，因为双向控制可能会影响外部字符的顺序引号。
3. 一行中不得包含超过四个非空格标记，并且两个相同的非间隔标记的序列。
4. 它可能包含混合的脚本、符号（包括表情符号）、，等等。

其他问题

上述限制不足以防止可能混合引用字符串部分的双向重新排序显示local-part或domain-part。为了防止这种情况发生，实现可以在每一个部件都在展示中。

实现可能还希望使用其他检查，如混淆性检查，或使用安全浏览等服务。

一个严重的实际问题是，客户不知道标识规则适用于任何特定的电子邮件服务器：即，当两个电子邮件地址被认为是等效的。例如mark@macchiato.com和马克@macchiato.com被服务器同样对待？不幸的是，无法查询服务器以查看它遵循什么身份规则。用于处理的技术之一这个问题是有一个电子邮件提供商的白名单，指明其中哪些是区分大小写的，哪些是区分点的，或者两者兼而有之。

4令人困惑的检测

中的数据[易混淆的]提供一个用于确定两个字符串何时在视觉上混淆的机制。随着时间的推移，这些文件中的数据可能会被细化和扩展。对于有关处理随时间变化的修改的信息，请参见章节2.10.1，向后兼容性在Unicode技术报告#36中，“Unicode安全注意事项”[UTR36标准]以及迁移本文档的第节。

不收集用于检测看门人可混淆字符串的数据目前，可混淆检测机制的目标是文档。有关更多信息，请参阅第2节，视觉安全问题英寸[UTR36标准].

数据提供了从源字符到其原型的映射。原型应该被视为一个或多个符号类的序列，其中每个类都有一个范例字符。例如，字符U+0153（œ），即拉丁语小型连词OE，其原型由两个符号类组成：一个具有示例字符U+006F（o），另一个具有实例字符U+0055（e）。如果输入字符没有在数据文件中显式定义的原型，则假定原型由输入字符作为示例字符的符号类组成。

对于输入字符串X，定义骨架（十） 为字符串上的以下转换：

1. 将X转换为NFD格式，如中所述[UAX15型].
2. 根据指定的数据连接X中每个字符的原型，生成一个示例字符字符串。
3. 重新应用NFD。

字符串X和Y被定义为容易混淆的当且仅当骨架（X）=骨架（Y）时。它缩写为X≅Y。

这种机制将及物性强加于数据，因此如果X≅Y和Y \8773»Z，那么X≋Z。通过在给定字符之间提供一个度量，表明其“接近性”，可以提供更复杂的易混淆检测。然而，这在计算上要昂贵得多，并且需要更复杂的数据，因此，此时选择了更简单的机制。这意味着在某些情况下，测试可能过于全面。

注：字符串骨架（十） 和骨架（是）是不用于显示、存储或传输。应将其视为中间处理形式，类似于哈希码。示例角色包括不保证为标识符字符。

定义

混淆可分为三类：单脚本混淆、混合脚本混淆和全脚本混淆，定义如下。所有可混淆的部分要么是单个脚本，要么是混合脚本，但不是两者都可混淆。所有全脚本可混淆也都是混合脚本可混淆。

这三类混淆词的定义取决于解析的脚本集和单脚本，在中提供第5节，混合脚本检测.

X和Y是单一脚本易混淆如果只有当它们容易混淆，并且它们解析的脚本集至少有一个共同的元素时。

例如：拉丁语中的“ljto”和“ljeto”（克罗地亚语中的单词“summer”），其中第一个单词只使用四个代码点，第一个代码点是U+01C9（\457'）Latin SMALL LETTER LJ。

X和Y是混合脚本可混淆如果只有当它们容易混淆，但它们解析的脚本集没有共同的元素时。

示例：“paypal”和“pаypаl”，其中第二个单词具有字符U+0430号机组（а）CYRILLIC小写字母A。

X和Y是全脚本可混淆如果只有当他们是混合脚本易混淆，每一个都是单脚本字符串。

例如：拉丁语中的“scope”和西里尔文中的“ѕсоре”。

如第5节所述，已解析的脚本集忽略带有script_Extensions{Common}和{Inherited}的字符，并使用CJK脚本及其各自的书写系统增加字符。Script_Extension属性值为COMMON或在测试脚本中的差异时，将忽略INHERITED。

数据文件格式

数据文件中的每一行具有以下格式：字段1为源，字段2是目标，字段3是过时的，始终包含字母“MA”以实现向后兼容性。例如：

0441 ; 0063 ; MA#（с→ c）CYRILLIC小写字母ES→ 拉丁语（小）字母C#

2CA5；0063 ; MA编号（ⲥ → c）复制小字母SIMA→ 拉丁语小写字母C#→ϲ→

#后面的所有内容都是评论，纯粹是提供信息。一个注释后的星号表示该字符不是XID字符[UAX31型]. 评论提供了字符名称。

使用易混淆数据的实现不必递归地应用映射，因为转换是幂等元。那就是，

骨架（骨骼（X））=骨架（X）

如果数据是通过传递性导出的，则存在结尾处的额外注释。例如，在上面的示例中推导如下：

1. ⲥ （U+2CA5复制小写字母SIMA）
2. → ϲ（U+03F2希腊月形西格玛符号）
3. → c（U+0063拉丁文小写字母c）

为了降低安全风险，建议使用标识符casefold形式，从而尽可能消除大写变体。

数据可能会在不同版本之间发生变化。即使数据是同样，文件中的行顺序可能会在不同版本之间发生变化。有关更多信息，请参阅迁移.

• 注：由于生产问题，版本7.0之前的所有病例均未维持幂等性。更多信息信息，请参见迁移.

4.1全脚本混淆

对于某些应用程序，确定给定的输入字符串是否有任何可混淆的完整脚本是很有用的。例如，使用西里尔字符的标识符“ѕсоре”将通过第5.2节限制级别检测尽管这可能是一次恶作剧。

可以确定单个脚本字符串X是否具有可混淆的全脚本：

1. 考虑一下Q，它是所有可与X混淆的字符串的集合。
2. 从Q中删除其解析脚本集与解析脚本集X相交的所有字符串。
3. 如果Q为非空且包含任何单脚本字符串，则返回TRUE。
4. 否则，返回FALSE。

上面的逻辑描述可以用于测试的参考实现，但不是特别有效。只要产生相同的结果，就可以优化生产实现。

注意，易混淆的数据包括拉丁语和西里尔语文本之间的大量映射。出于这个原因，上述算法可能会将大量用拉丁语或西里尔语书写的合法字符串标记为潜在的全字混乱。为了有效地使用全脚本可混淆性，通常可以确定字符串是否具有可混淆的全脚本，以及哪一个那些全脚本可混淆的脚本。

例如，可以使用此信息来区分合理与可疑的全脚本混淆。考虑拉丁语脚本的域名标签“circle”。将其放在域名“circle.com”中是合适的。在西里尔语域名“сiГсӀе.рф”中使用可混淆的西里尔文“сiiГС\1216m;е的”也是合适的。然而，如果西里尔文“сиГсӀе”与.com一起使用，或拉丁语“圆圈”与.rephф一起使用，浏览器可能会提醒用户可能出现的恶作剧。

确定全脚本可混淆语言的可疑用法的过程比简单地查看域名中标签的脚本要复杂得多。例如，SLD（二级域）中的脚本与TLD（顶级域）中的脚本不同是完全合法的，例如：

• 域名中TLD为.ru或.ruchф的西里尔文标签
• 域名中TLD为.com.au或.com的中文标签
• 西里尔文标签不会混淆的拉丁文，TLD为.com.au或.com

以下高级算法可用于确定包含可与字符串X混淆的整个脚本的所有脚本：

1. 考虑Q，所有字符串的集合都可以与X混淆。
2. 从Q中删除其解析脚本集为∅或所有（也就是说，只保留单脚本字符串加上那些仅在Common中包含字符的字符串）。
3. 取Q中剩余的所有字符串的已解析脚本集的并集。

与往常一样，该算法仅用于定义；实现应该使用产生相同结果的优化例程。

4.2混合脚本混淆

为了确定混合脚本是否存在混淆，可以使用类似的过程：

1. 考虑一下Q，它是所有可与X混淆的字符串的集合。
2. 从Q中删除其解析脚本集与解析脚本集X相交的所有字符串。
3. 如果Q为非空，则返回TRUE。
4. 否则，返回FALSE。

上面的逻辑描述可以用于测试的参考实现，但不是特别有效。只要产生相同的结果，就可以优化生产实现。

注意，由于可混淆数据提供的映射数，上述算法可能会将大量合法字符串标记为潜在的混合脚本可混淆。

5检测机制

5.1混合脚本检测

Unicode标准提供了可用于确定字符的脚本并检测混合脚本文本。脚本的确定根据UAX#24，Unicode脚本属性[UAX24型]，使用Unicode字符数据库中的数据[UCD公司].

定义角色的增强脚本集是角色的Script_Extensions，有以下两个修改。

1. 根据以下规则添加包含多个脚本的书写系统条目：Hanb（Han with Bopomofo）、Jpan（Japanese）和Kore（Kore）。
   1. 如果Script_Extensions包含Hani（Han），请添加Hanb、Jpan和Kore。
   2. 如果Script_Extensions包含Hira（平假名），请添加Jpan。
   3. 如果Script_Extensions包含假名（片假名），请添加Jpan。
   4. 如果Script_Extensions包含Hang（朝鲜文），请添加Kore。
   5. 如果Script_Extensions包含Bopo（Bopomofo），请添加Hanb。
2. 包含Zyy（Common）或Zinh（Inherited）的集合被视为所有，所有脚本值的集合。

Script_Extensions数据来自Unicode字符数据库[UCD公司]. 有关Script_Extensions属性和Jpan、Kore和Hanb的更多信息，请参阅UAX#24，Unicode脚本属性[UAX24型].

定义已解析的脚本集将字符串作为扩展脚本集在字符串中所有字符上的交集。

字符串定义为混合脚本如果其解析的脚本集为空并定义为单脚本如果其解析的脚本集为非空。

请注意，术语“单一的-脚本字符串”可能会令人困惑。这意味着有至少一个已解析脚本集中的脚本，而不是只有一个例如，字符串“切” 是单脚本，因为它有四脚本{已解析脚本集中的Hani、Hanb、Jpan、Kore}。

以及提供API来检测字符串有mixed-scripts对于提供返回这些脚本的API也很有用。看下面的例子。

表1a。混合脚本示例

一组脚本定义为盖如果该集合与字符串中所有字符的扩展脚本集的交集非空，则为字符串；换句话说，如果字符串中的每个字符都与封面集共享至少一个脚本。例如，{Latn，Cyrl}包含“Сirсlе”表1a.

封面集定义为最小值如果没有较小的覆盖集。例如，{Hira，Hani}涵盖“切“，中的第七个示例表1a，但它不是最小的，因为{Hira}也包含字符串，并且{Hiraneneneep小于{Hira，Hani}。请注意，最小覆盖集并不是唯一的：字符串可能具有不同的最小覆盖集。

通常，以字符串形式返回脚本的API将返回最小覆盖集之一。

为了提高计算效率，可以计算一组脚本集（SOSS），其中字符串中每个字符的扩展脚本集映射到SOSS中的一个条目。例如，{{Latn}、{Cyrl}}将是“Сirсlе”的SOSS。覆盖SOSS的一组脚本也覆盖输入字符串。同样，SOSS的所有条目的交集将是输入字符串的解析脚本集。

5.2限制级别检测

此处定义了限制级别1-5，以便在实施中使用。根据中规定的适当标识符配置文件第3节，标识符字符。推荐脚本列表如下取自表5、推荐脚本第页，共页[UAX31型]. 对于有关限制级别使用的更多信息，请参阅章节2.9、限制级别和警报英寸[UTR36标准].

对于每个限制级别1-6，标识符必须根据任何有效的通用语法约束（例如[UAX31型].

此外，应用程序可以提供标识符配置文件，例如标识符的通用安全配置文件，这进一步限制了允许的字符。对于每个限制级别1-5，字符串中的字符也必须位于标识符配置文件中。如果没有此类标识符配置文件，则第5级和第6级是相同的。

1. ASCII-仅限
   • 字符串中的所有字符都在ASCII范围内。
2. 单个脚本
   • 字符串仅符合ASCII-条件，或
   • 字符串是单脚本，根据第5.1节中的定义。
3. 高度限制
   • 字符串符合“单个脚本”的条件，或
   • 字符串是盖满根据第5.1节中的定义，通过以下任何一组脚本：
     • 拉丁语+汉语+平假名+片假名；或等效：Latn+Jpan
     • 拉丁语+汉语+汉语拼音；或同等名称：Latn+Hanb
     • 拉丁文+汉文+朝鲜文；或同等名称：Latn+Kore
4. 适度限制
   • 字符串符合高度限制条件，或
   • 字符串是盖满由拉丁语和任何其他推荐脚本编写，西里尔语、希腊语除外
5. 最小限制
   • 对以下脚本集没有限制：盖字符串。
   • 唯一的限制是标识符格式良好标准和标识符配置文件，允许任意混合脚本，如Ωmega、Teχ、，HλLF-LIFE，玩具-Я-我们。
6. 无限制
   • 字符串的脚本覆盖范围没有限制。
   • 唯一的限制是标识符格式良好的标准。字符可能位于标识符配置文件。
   • 此级别主要用于检测API，提供返回值，指示字符串与任何级别1-5都不匹配。

请注意，在除ASCII-Only之外的所有级别中，标识符中允许任何具有Script_Extensions{Common}或{Inherited}的字符，只要这些字符满足标识符配置文件的要求。

这些级别可以通过重用一些机制来检测第5.1节。对于给定的输入字符串，限制级别为由以下逻辑过程确定：

1. 如果字符串包含Identifer Profile，返回无限制.
2. 如果字符串中没有字符高于0x7F，则返回ASCII-仅限.
3. 根据第5.1节计算管柱的SOSS。
4. 如果SOSS为空或SOSS中所有条目的交集为非空，则返回单个脚本.
5. 从SOSS中删除包含拉丁文的所有条目。
6. 如果以下任何一组包含SOSS，请返回高度限制性的。
   • {科尔}
   • {汉布}
   • {日本}
7. 如果SOSS中所有条目的交集包含任何单个推荐脚本除外西里尔文 或希腊语，返回适度限制性的.
8. 否则，返回最小限制.

该算法的实际实现可以优化；与往常一样，规范只取决于结果。

5.3混合编号检测

Unicode中有三种不同类型的数字。只有数字General_Category=中应允许小数（Nd）标识符。但是，来自不同十进制数的字符系统很容易混淆。例如，U+0660号机组( ٠ )阿拉伯-印度数字零可能与U+06F0( ۰ )扩展阿拉伯-印度数字零点，以及U+09EA公司( ৪ )BENGALI DIGIT FOUR可能与U+0038号机组( 8 )数字八。不允许在标识符中使用混合数字系统还有其他原因，就像混合脚本一样。

对于不包含非十进制的给定输入字符串数字，检测混合数字的逻辑过程是以下内容：

对于字符串中的每个字符：

1. 查找该字符的十进制数值（如果有）。
2. 将值映射到该数字的唯一零字符系统。

如果有多个这样的零字符，那么字符串包含多个十进制数字系统。

该算法的实际实现可以优化；作为通常，规格仅取决于结果。以下内容Java示例使用[重症监护室]展示了如何做到这一点:

公共UnicodeSet getNumberRepresentatives（字符串标识符）{
整数cp；
UnicodeSet numerics=新UnicodeSet（）；
for（int i=0；i<identifier.length（）；i+=字符.charCount（i））{
cp=Character.codePointAt（标识符，i）；
//存储每种十进制数字的代表字符
开关（UCharacter.getType（cp））{
案例UCharacterCategory。小数位数：
//只需存储零字符作为比较的代表。
//Unicode保证它是cp-value。
numerics.add（cp-UCharacter.getNumericValue（cp））；
断裂；
案例UCharacterCategory。其他编号：
案例UCharacterCategory。字母编号：
抛出新的IllegalArgumentException（“不应在标识符中。”）；
}
}
返回数值；
}...UnicodeSet numerics=getMixedNumbers（字符串标识符）；如果（numerics.size（）>1）拒绝（identifier，numerics）；

5.4可选检测

还有一些额外的增强功能可能在恶搞中很有用检测，例如：

1. 检查所有字符是否位于Unicode Common中至少一种语言的示例字符区域设置数据存储库[CLDR公司].
2. 检查组合标记的不太可能顺序：
   1. 禁止相同非间隔标记的序列。
   2. 禁止4个以上非间隔标记的序列（gc=Mn或gc=Me）。
   3. 禁止基本字符+非空格标记的序列仅与基本字符看起来相同或令人困惑的相似（因为非空格标记覆盖了基本字符的一部分）。一个例子是上面的U+0069小写字母I+U+0307组合点。
3. 添加对检测两个不同的序列具有相同表示的。当前的数据文件只处理单个代码点与另一个代码点或序列混淆的情况。它不处理以下情况史瑞，如下所示。

字符U+0BB6 TAMIL LETTER SHA和U+0BB8 TAMIL LITTER SA通常非常明显。然而，它们都可以用于泰米尔语单词的表示史瑞。在一些非常常见的平台上，以下序列会产生完全相同的视觉外观：

= ஶ்ரீ

= ஸ்ரீ

6开发过程

如Unicode技术中所述报告#36，“Unicode安全注意事项”[UTR36标准]，字符之间不能混淆一门精确的科学。有许多因素使易混淆性成为程度问题：

• 字符的形状在用于代表他们。Unicode标准在代码图表，但字体设计者可以自由创建自己的符号。因为可以使用任意字形轻松创建字体表示任何Unicode代码点，字符混淆任意字体是不可避免的。例如，可以设计“a”看起来像“b”、“c”像“d”等的字体。
• 使用上下文塑造的书写系统（如阿拉伯语、，和许多南亚系统）引入了更多的文本变化渲染。字符在隔离并仅作为字符簇的一部分呈现造单词、表达和句子。这是相当常见的找到对应的相同可视文本表示不同的逻辑单词上下文，如果有的话。
• 字体样式变体（如斜体）可能会引入另一种风格中不存在的易混淆性。例如，在西里尔字母U+0442号机组( т )CYRILLIC小写字母TE在正常情况下看起来像一个小型大写拉丁字母“T”样式，而它看起来像一个斜体小拉丁'm'。

脚本的易混淆性与用户密切相关。例如，在拉丁字母、带重音符号或附录的字符可能看起来类似于某些用户的未修饰字符，特别是如果他们不熟悉它们在特定语言中的含义。然而，大多数用户对字符在自己的脚本中的范围，并且有单独的可用于处理其他脚本的机制，如中所述[UTR36标准].

如其他地方所述，在某些情况下，易混淆的数据可能与预期不同。有时这是因为两个字符或两个字符串在某些字体中可能会混淆。在其他情况下，这是因为及物性。例如，虚无缥缈的我被认为是等效的↔ i） ，因为当口音，如严重的应用于每个。然而，对于实际实现用法，及物性足够重要的是接受一些奇怪的事情。

此版本的未来版本可能会增强数据规范。有关处理数据更改的信息时间，请参阅2.10.1，向后兼容性第页，共页[UTR36标准].

6.1Confusables数据收集

可混淆性数据是通过收集预期的可混淆性，根据一组通用字体，并处理传递结果关闭。

主要目标是包含Identifier_Status=Allowed的字符如中所示表1，标识符状态和标识符类型.其他字符，如NFKC变量不是数据收集的主要焦点。然而，这样的数据中可能会包含变体，也可能会提交使用在线表单[反馈].

这些潜在的困惑来自于来源。Erik van der Poel提供了一个从运行在大量字体上编程以捕获共享的字符字体中的字形相同，马克·戴维斯也做了同样的事情最近用于Windows和Macintosh上的字体。志愿者来自谷歌、IBM、微软和其他公司收集了字符。其中包括母语为英语的人不同的书写系统。Unicode兼容性映射是也用作源。收集视觉混淆信息的过程是正在进行：Unicode联盟欢迎提交其他映射。南亚和东南亚的复杂脚本需要特别注意。重点是可以位于推荐的标识符配置文件，因为它们是担忧。

用于评估易混淆性的字体包括用户界面中的主要操作系统。此外Unicode标准中使用的代表性符号还有考虑过的。操作系统中用于用户界面的字体是一个重要的来源，因为它们通常是在易混淆性很重要的情况下被用户看到，例如，在使用IRIS（国际化资源标识符）时及其子元素（如域名）。这些字体具有其他相关特征的数量：

• 在操作系统和应用；系统升级带来的变化往往是渐进的以避免可用性中断。
• 因为用户界面元素需要在低处清晰可见屏幕分辨率（意味着每个EM的像素数较低）、字体在这些上下文中使用的往往是sans-serif样式，这有增加混淆可能性的趋势。然而，有些语言，如汉语，其中衬线风格是常用的。
• 严格的边界框要求创造了更多使用相对较大上升器和下降。这也限制了为重音或音调分配的空间标记，也可以创造更多的混淆机会。

如果一对潜在的混淆词总是在字体内部和跨字体的通用大小上，视觉上都是不同的。这个然后数据在传递性下是闭合的，所以如果XŞY和YŞZ，那么X≅Z。此外，数据是在子字符串操作下关闭的，因此如果X≅Y，那么AXB \8773»AYB。然后对其进行加工以生产脚本内和跨脚本数据，以便单个数据表可以用于将输入字符串映射到结果骨架.

计划使用骨架只有供内部测试使用字符串的易混淆性；结果文本不适合显示给用户，因为它看起来像是一个大杂烩不同的脚本。特别是，映射标识符的结果不必是标识符。因此，可混淆性映射可用于测试两个标识符是否可混淆（如果骨架是相同的），但绝对不能用作标识符的“规范化”。

6.2标识符修改数据收集

这个身份识别模块数据的收集方式如下。这个基本赋值基于UCD字符属性导出，中的信息[UAX31型]和一份精心策划的列表基于各种来源信息的例外情况，包括Unicode标准的核心规范，代码中的注释图表、有关CLDR示例字符的信息和外部反馈。

按从顶部开始的项目顺序匹配的第一个条件至底部表1。标识符状态和标识符类型使用，但有几个例外：

1. 当字符位于表3a，Medial的可选字符或表3b，用于Continue的可选字符英寸[UAX31型]，则给出Identifier_Type=Inclusion，无论其他属性如何。
2. 当字符的Script_Extensions属性值包含多个Script属性值，用于派生是下表中的第一个：
   1. 表5，推荐的脚本
   2. 表7，有限使用脚本
   3. 表4，排除的脚本

中的脚本信息表4,表5、和表7在CLDR中是机器可读的形式，如scriptMetadata.txt。

7数据文件

以下文件提供了用于实现本文档中的建议。未来可能会对数据进行改进本规范的版本。有关更多信息，看见2.10.1，向后兼容性第页，共页[UTR36标准].为了便于说明，此UTS显示了示例数据值，但对于当前Unicode版本的实际数据始终引用数据文件。

Unicode联盟欢迎反馈额外的混淆或标识符限制。有在线表单位于[反馈]你可以在哪里建议添加字符或更正。

文件在https://www.unicode.org/Public/security网站/.其中的目录包含与给定版本。的目录这版本为：

https://www.unicode.org/Public/security/15.0.0/

最新批准版本的数据文件也在目录：

https://www.unicode.org/Public/security/latest

IdentifierStatus.txt的格式遵循UCD数据文件，并在该文件的标题中进行了描述。文件中未列出的所有字符默认为Identifier_Type=Restricted。因此，该文件仅列出Identifier_Status=Allowed的字符。例如：

第002天。。002E；允许#1.1 HYPHEN-MINUS。。完全停止

IdentifierType.txt的格式遵循UCD的常规约定数据文件，并在该文件的标题中进行描述。该值为设置其元素由空格分隔。此格式与用于ScriptExtensions.txt的。这与以前的版本不同其中只列出了最强烈的排除理由。这个新的约定允许将值用于更精细的筛选。例如，如果实现想要允许Exclusion脚本，它仍然可以排除该脚本中的过时字符和弃用字符。文件中未列出的所有字符默认为Identifier_Type=Recommended。例如：

2460..24EA；技术编号_XID编号_NFKC#1.1圆圈数字一。。圆形数字零点

这两个文件都是机器可读的#@缺少线路默认属性值，如在许多UCD文件中。有关此语法的详细信息，请参阅第4.2.10节，@缺少约定英寸[UAX44型].

表2。数据文件列表

迁移

从版本6.3.0开始文档已更改，以指示数据基于。对于6.3.0及之前的版本下表显示了此版本之间的对应关系它们所基于的文档和UCD版本。

表3。版本通信

如果在以下期间需要更新本标准相关的UCD版本，版本编号将包括更新第3个字段中的编号。例如，如果UCD 6.3.0和UCD之间需要文档及其相关数据7.0.0，然后是6.3版。1可以使用。

正在迁移持久数据

实现必须迁移其持久数据存储（例如作为数据库索引）每当这些实现更新为使用本规范新版本中的数据文件。

版本之间的稳定性从来没有得到保证，尽管它是这样的在可行的情况下进行维护。特别是易混淆的映射数据可能使用特定字符的映射这与在早期版本。因此，可能存在X的情况→ 版本N中的Y，和X→ 版本N+1中的Z，其中Z可能映射到或可能没有映射到中的Y版本N。即使在逻辑数据没有更改的情况下在不同版本之间，数据文件中的行顺序可能是改变。

Identifier_Status没有稳定性保证（例如“一旦字符被允许，它在未来的版本中就不会变为受限”），因为随着我们对字符使用的了解，数据会随着时间的推移而变化。某些Identifier_Type值（如Not_XID）是向后兼容的，但大多数值可能会随着新数据的可用而更改。仅从脚本和一般类别的角度来看，标识符数据也可能看起来不完全一致。例如，脚本中一组非空格标记中的一个字符可能是受限的，而其他字符则不是。但这可能只是反映了这样一个事实，即这个角色是过时的，而其他角色则不是。

对于标识符查找，数据的目的更多是标记可能有问题的字符，从而作为确定是否应以某种方式通知用户的一个因素（可能包括许多因素，如使用“安全浏览”服务）。对于注册，标记的字符可能会导致“软拒绝”，即要求用户用更多信息对拒绝提出上诉。

为了处理状态更改为Restricted的字符，实现可以使用祖父机制来维护向后兼容性。

因此，实现应该有迁移策略使用任何容易混淆的映射数据或其他数据文件。

13.0版迁移

从Unicode 13.0开始，Identifier_Status和Identifier _Type始终使用底线书写。这可能会导致解析器出现故障，这些解析器不遵循Unicode约定来匹配属性名。

10.0版迁移

从Unicode 10.0开始，Identifier_Type=Aspirational现在为空；有关详细信息，请参阅[UAX31型].

版本9.0迁移

版本8.0和9.0之间有一个重要的数据格式更改。特别是，8.0版中的xidmodifications.txt文件已被拆分为9.0版的两个文件：IdentifierStatus.txt和Identifier Type.txt。

IdentifierType.txt的字段1中列出了多个值。要转换为旧格式的xidmodifications.txt，请使用最后的该字段的值。例如，以下值将对应：

版本8.0迁移

在V8.0中，对标识符状态和标识符类型：

• 更改为标准UCD格式。例如，有限使用→限制使用（_U）.
  • 通常这只是改变大小写和连字符，但非chars已更改为无字符（_C）.
• 将Identifier_Type与UAX 31和Unicode更好地对齐属性
  • 有历史意义的
    • → 排除，其中表4，标识符中排除的候选字符,
    • → 过时，否则
  • 有限使用
    • → Limited_Use，其中来自表7，有限使用脚本,
    • → 渴望，从哪里来表6，渴望式使用脚本（后来并入Limited_Use10.0版中）
    • → 不常见-使用，否则
  • 过时的
    • → 不推荐，其中匹配Unicode属性

版本7.0迁移

由于生产问题，可混淆映射的版本7.0之前的表格并没有在所有情况下保持幂等性，所以强烈建议更新到8.0版。

任何使用骨架映射的人都需要重建任何骨架的持久使用，例如在数据库索引中。

7.0中的SL、SA和ML映射发生了显著变化来解决幂等性问题。然而，表SL、SA和ML仍然存在问题，不鼓励在7.0中使用。他们是因此从版本8.0中删除。

实现重新创建删除的表在剩余数据（MA）和Unicode字符数据库属性（脚本、大小写等）。这样一个再创造将检查MA中的每个等价类数据，并筛选出不符合约束的实例（脚本或大小写）。对于目标角色，它将选择中性字符，通常是一个符号。然而反对意见仍然有效，因此不建议实现重新创建它们。

还要注意，随着Script_Extensions数据变得更加完整，它可能会导致全脚本可混淆数据文件中的字符不再匹配。有关更多信息，请参阅第4节，易混淆检测.

致谢

Mark Davis和Michel Suignard创作了文本，在Unicode技术委员会的指导下。史蒂文Loomis和ICU团队中的其他人在制定本技术报告的原始提案。Shane Carr分析了算法，并提供了重写版本10中第4节和第5节的源文本。

谢谢也向以下人员提供反馈或贡献此文档或其早期版本，或到的源数据易混淆或idmod：朱莉·艾伦（Julie Allen）、安德鲁·阿诺德（Andrew Arnold）、弗农·科尔（Vernon Cole）、大卫·科贝特（David Corbett）（特别感谢您的众多贡献），道格拉斯·戴维森（Douglas Davidson）、罗伯·道森（Rob Dawson）、亚历克斯·德贾纳特（Alex Dejarnatt）、克里斯·费恩（Chris Fynn）、马丁·德斯特（Martin Dürst）、阿斯穆斯·弗雷塔格（Asmus Freytag）、戈德史密斯（Goldsmith）、曼尼什·戈雷戈卡（Manish Goregaokar）、保罗·霍夫曼（Paul Hoffman）、丹尼斯·杰奎里（Denis Jacquerye）、西布·约翰尼（Cibu Johny）、帕特里克·L。Jones、Peter Karlsson、Robin Leroy、Mike Kaplinskiy、Gervase Markham、Eric Muller、，David Patterson、Erik van der Poel、Roozbeh Pournader、Michael van Riper、Marcos Sanz、，Alexander Savenkov、Dominikus Scherkl、Manuel Strehl、Chris Weber、Ken Whistler、，和瓦伊尔·叶海艾。感谢Peter Peng在字体方面的帮助令人困惑的。

工具书类

修改

以下总结了之前的修改本文档的发布版本。

第26次修订

• 重新发布对于Unicode 15.0
• 第3节标识符字符
  • 更改了中Uncommon_Use的描述表1。标识符状态和标识符类型更具包容性：“不常见的字符，或使用受限的字符（即使它们位于非“limited_use”的脚本中），或使用不确定的字符。”
  • 添加了关于ZWJ和ZWNJ的Identifier_Type和Identifier _Status更改的注释。
• 第3.1.1节连接控件
  • 更改了第一段，以与Identifier_Status的更改保持一致。
• 第7节数据文件
  • IdentifierStatus.txt和Identifier Type.txt现在包含机器可读#@缺少线路用于其各自属性的默认值。

先前版本的修改在相应版本中列出。

©2022 Unicode，Inc.保留所有权利。Unicode码联合体不做任何形式的明示或暗示保证，以及对错误或遗漏不承担任何责任。不承担任何责任与或相关的附带和间接损害赔偿因使用所包含的信息或程序而产生的，或随附本技术报告。Unicode码使用条款适用。

Unicode和Unicode徽标是商标Unicode，Inc.，并在某些司法管辖区注册。