Unicode®技术报告#23
Unicode字符属性模型
总结
本文档提供了字符属性的概念模型在Unicode标准中定义。该模型还涵盖了枚举字符序列以及字符串函数的属性。
状态
此文档已由Unicode成员审阅和其他感兴趣的并已由Unicode联盟批准发布。这是一份稳定的文件，可以用作参考材料或作为其他规范的标准参考。
Unicode技术报告（UTR）包含信息材料。符合Unicode标准暗示符合任何UTR。然而，其他规范包括可以自由地对UTR进行规范性引用。
请随在线报告提交更正和其他评论形式[反馈]. 有助于理解本文档的相关信息见工具书类。有关Unicode标准的最新版本，请参阅[Unicode码]. 有关当前Unicode技术报告的列表，请参阅[报告]. 有关Unicode标准版本的更多信息，请参阅[版本].
目录
- 范围
- 概述
- 定义
- 合规性相关注意事项
- 更新字符属性并扩展标准
- 特殊属性值
本报告概述了字符属性和属性值的类型，以及枚举字符序列和字符串函数的属性。此Unicode字符属性模型的描述并不是为了取代Unicode中有关属性的规范信息标准[Unicode码]，也不是现有机构Unicode字符的技术报告和文档文件数据库[UCDDoc公司]提供详细描述特定字符属性或枚举字符序列的属性，以及字符串函数。相反，它侧重于背后的整体模型和常见方面所有这些。
本报告专门涵盖正式字符属性，其中这些字符属性是根据本报告中规定的定义。这种形式字符属性只是一个子集一般意义上的字符属性，它们进一步细分为这些属性在Unicode标准或Unicode字符数据库中定义，以及由相关标准。范围中还包括正式的枚举的属性字符序列和字符串函数。
最基本的是一个角色属性将字符与值相关联。因此，可以考虑属性从代码点映射到特定属性值。这些概念可以很容易地扩展到映射特定序列将字符转换为属性值，或转换为算法上通用的字符串函数将任意字符串或子字符串映射到属性值。为了使讨论保持简单，在单个字符属性的上下文中介绍了基本概念或代码点。
Unicode标准将字符语义视为字符的定义和一致性过程需要采用这些在解释字符时要考虑到。
D3字符语义：字符的语义是由其特性、规范属性和行为决定。
注：引用Unicode标准核心规范为清晰起见，以这种缩进的盒式样式引用。定义编号或一致性这些引文中的条款编号与核心规范中的相同。
Unicode标准中字符语义的赋值基于角色行为。其他字符集标准将其留给实现者或无关的二级标准来指定字符字符的语义。相反，Unicode标准提供了每个字符的丰富字符属性集，称为属性包含在其中。指定了与解释它们的过程或算法，以便实现角色行为。有一些特定于特定的文本过程，并且在Unicode标准。实现通常提供以下内容的内部定义字符属性以实现所需的行为。实施者可能会发现这里讨论的许多概念适用于此类情况。
某些属性的解释（例如字符是否为数字或非数字）是在很大程度上独立于上下文，而对其他内容（如方向性）适用于整个字符序列，而不是到组成序列的单个字符。
其他需要上下文的示例包括标题大小写和分类标点符号或符号脚本分配。换行规则属于UAX公司 #14 Unicode换行算法
[换行符] 包括字符对和三元组，在某些情况下，还包括更长的序列。由组合字符序列定义的glyph是显示成形引擎中的上下文分析。独立字符属性通常只讲述故事的一部分。组成字符枚举字符序列列表的元素显然存在于上下文中这样的序列。但是，为特定的枚举列表定义的属性下面讨论的序列与讨论的算法上下文类型不同在这里。事实上，定义算法不仅可以评估周围的上下文单个字符或代码点，以及围绕特定枚举字符序列。
在某些情况下，预期的角色行为取决于外部环境，例如文档的类型和性质、文本的语言或用户的文化期望。为此类行为建模的属性可在单独的标准中规定，如这个UTS#10 Unicode排序算法[加利福尼亚大学]. 如果一组合理通用的财产价值可以分配，例如[换行符]，此类属性可以被定义为[Unicode码]. 这些属性和与之相关的任何算法定义了有用的默认值行为，可以进一步定制或定制以满足更具体的要求要求。
使用计算机过程建模角色行为时，形式化角色分配属性以实现预期结果。这样的建模在很大程度上依赖于用于生成这些结果的算法。在某些情况下，给定字符属性与算法。在其他情况下，算法是隐含的，但没有指定，或者有几种算法可以利用相同的通用字符属性，例如按General_Category或Indic_Syllabic_Type。此类一般属性可以需要偶尔对字符属性进行特定于实现的调整赋值以使所有算法正确工作。这通常可以实现通过覆盖特定算法的特定属性。（另请参见第4.3节“通过更高级别覆盖属性协议”）
当分配字符属性以与给定算法一起使用时，它可能尝试为某些字符分配一些任意值，只要该算法恰好产生了预期的结果。继续这种方式隐藏了字符的本质并限制了字符的重复使用相关过程的属性。因此，不要调整属性为了简化特定算法，Unicode标准支付了仔细关注基本的潜在语言身份字符。然而，并非角色身份的所有方面都与所有情况下，一些字符可以用多种不同的方式使用，取决于上下文或环境。这意味着形式特征单独的性质不足以描述理想的或可接受的性格行为。
注：在某些情况下，相关算法未在Unicode标准。例如，将数字串转换为Unicode标准中没有定义数值，但然而，实现将引用numericvalue属性。
代码点属性是代码点本身的属性：in一种字符编码标准，与实际的任何赋值无关将字符抽象到那些代码点。在大多数字符编码标准中，这些是这是微不足道的，但在Unicode标准中并非如此。
代码点属性的示例包括：
- 代码点XXX是代理代码点。
- 代码点XXX是私用代码点。
- 代码点XXX是保留的代码点。
- 代码点XXX保留用于编码格式控制字符。
- 代码点XXX指定用于编码RTL脚本。
- 代码点XXX是Pattern_Syntax代码点。
- 代码点XXX是Pattern_Whitespace代码点。
- 代码点XXX位于平面1上。
无论是否存在指定给它们的特定抽象字符。例如，它们跟踪代码点的状态：是否为其指定了任何抽象字符，或者是否可以为其指定抽象字符，等等。本质上，无论何时指定代码点或在以某种方式，代码点属性被赋值。
字符属性是那些抽象的属性字符与编码无关。
字符属性的示例（不限于形式属性）包括：
- G是一个字母字符。
- G是拉丁字母。
- G是大写字母。
- G不用于十六进制表达式。
- 在英语字母表中，G排在F之后。
- G被认为是由约300年的斯普里乌斯·卡维卢斯·鲁加发明的。
- 在拼字法中，G通常代表音塞。
- G不是标点符号。
- G表示SI命名系统中的giga。
- G没有变音符号。
- G是一个基本字符。
- G不是组合字符。
通过对抽象字符拉丁大写字母G进行编码在代码点U+0047，这个字符属性的宇宙，一些已知的很明显，其他晦涩甚至未被发现的代码点都与该代码点有关。
其中一些字符属性是通用的和系统的在实现通用文本处理算法时足够有用甚至必要-这些是Unicode标准在Unicode字符数据库。
通用文本处理算法和访问它们的编程API必须做好处理使用任何代码点，即使是未分配给创建实现的时间。因此，他们几乎总是需要正确处理任何字符属性的每个代码点，即使它们仅将属性值“unknown”或“inapplicable”与未分配的关联或不支持的代码点。
这一要求导致了统一概念的使用属于编码字符属性在Unicode字符属性模型中。一个编码字符属性结合了代码点属性的概念将代码点的范围与特性的默认值相关联将特定值关联到分配的字符。这个统一的模型与基于Unicode的实现，必须为每个和每个代码点。此外，这个统一的概念简化了大多数建立在其之上的定义，因为不再需要分别说明适用于字符属性和代码的定义点属性。
定义字符和代码点属性，以便所有分配的字符和所有代码点都有一个定义的属性值，即使该值为“N/a”（“不适用”）。分配的字符和代码点各自形成一个有限集。对于字符串来说，这通常是不正确的。因为没有固有的固定限制字符串的长度，可能的序列数原则上是没有界限的。一些字符串的属性可以通过字符串函数等算法进行描述属性可以说适用于每个可能的字符串。其他属性仅适用于明确列出的一组特定字符串。在后一种情况下，属性被称为枚举字符串集.这些下面详细介绍了这些概念第3.6节，串、和第3.7节，字符串的属性。
在第3章中，合规性、Unicode标准[Unicode码] 定义了规范属性as“中使用的Unicode字符属性标准规范”（定义第33页)并提供以下解释：
字符属性是规范性的表示声明符合特定版本的实现并且使用该特定属性的用户必须遵循该属性的标准规范实现一致。例如，无论何时，Bidi_Class属性都是一致性所必需的呈现需要双向布局的文本，例如阿拉伯语或希伯来语。
当规范过程依赖于属性，该属性被指定为规范。
给定的Unicode字符属性是规范性的吗不意味着财产的价值将永远不要因为特定的字符而改变。更正和扩展未来标准可能需要对规范进行细微的更改值，尽管Unicode技术委员会努力最小化此类更改。。。
一些标准的Unicode算法取决于关键在于其行为的特定属性值。例如，规范化定义了文本的一个方面许多应用程序绝对依赖的互操作性稳定。因此，一些规范属性不允许任何被更高级别的协议覆盖。因此Unicode字符的分解既规范又不是可重写的; 没有更高级别的协议可以覆盖这些值，因为这样做会导致对Unicode文本的规范化。其他规范属性，例如案例映射，是可重写的通过更高级别的协议，因为他们的意图是为行为提供一个共同的基础。然而，他们可能需要为特定的当地文化习俗量身定做或特定的实现方式。
通过使属性规范化且不可重写，Unicode标准保证一致性实现可以依赖于其他一致性实现以相同的方式解释字符。这是最适用于Unicode标准提供精确规则的属性用于根据字符的属性解释字符，例如归一化形式的分解及其使用[正常].
注释：一个平凡但重要的一致性示例实现是在运行时访问Unicode字符数据库中的信息[UCD公司]. 对于一致性实现公开的规范性属性，一致性要求返回的值与Unicode联盟。
对于某些字符属性，例如常规类别，Unicode标准没有定义处理属性的模型支持，也没有具体说明角色存在所需的后果定义为例如，“字母其他”与“符号其他”相反。在没有这样的定义，一致性的唯一影响是经过严格测试是字符属性的一致实现函数返回正确的值。然而，许多实现使用这样的规范用于自身目的的属性，并保证访问此信息有助于实现互操作性。
有关哪些属性的信息规范，请参阅文档Unicode字符数据库的文件[UCDDoc公司].
有关替代规范属性的详细信息，请参见第4.3节通过覆盖属性高级协议。
Unicode标准[Unicode码] 定义信息属性作为“Unicode字符属性提供的值仅供参考”（定义第35天)和提供了以下解释：
一致性实现可以自由使用或更改信息性属性值可能需要，同时保持符合标准。实施者可以选择建立传达特定信息的协议属性正在以不同的方式使用。
信息性属性捕获专家的实施经验。当信息属性为在Unicode字符数据库中明确指定，其使用非常广泛推荐实现以鼓励实现。请注意，可以在一个Unicode标准的版本，以成为标准的后续版本（如果其使用开始获得一致性）标准某些部分的含义。[重点补充]。
属性可以提供信息，主要有两个原因：
- 财产的确切性质或适用性可能尚不清楚。在某些情况下应用程序也可能不确定。
- 现有实现显示了一系列相同的行为字符，其中许多或全部可能对他们的设计师。
在某些情况下，属性过于暂定，无法发布为信息属性。在这种情况下，它们可以明确指定为临时的。
属性别名[别名]和属性值别名[值别名]定义一组名称和缩写，称为别名，用于引用属性和属性值。这些名称可用于中的XML数据格式这个Unicode码字符数据库[UCD公司]，用于正则表达式属性测试和其他Unicode数据的编程文本描述。这些名称本身并不规范，除非它们对应于UCD中的标准属性。然而，其他标准可能会成为规范性标准对规范性别名和信息性别名的引用。有关更多信息，请参阅UTS公司#18:Unicode正则表达式[RegEx公司].
有一个缩写名称和一个长名称大多数属性的名称。可以在添加其他别名任何时候。财产价值名称是不跨属性唯一。对于例子，美国铝业公司表示Bidi_Class属性的阿拉伯字母，以及美国铝业公司表示Combing_Class属性的Alpha_Left，以及美国铝业公司手段Line_Break属性的字母。此外，某些属性名称可能与某些属性值名称相同。例如，复写的副本手段Combing_Class属性，以及复写的副本表示General_Category属性值控制。属性值和属性名称的组合是，然而，这是独一无二的。
别名可以在适当的环境中转换可以使用别名。中的大小写区别、空白和“_”属性名称不规范。除非在在特定应用中，所有形式都是等效的。有关更多信息，请参见第5.9节匹配规则在里面UAX#44 Unicode字符数据库[UCDDoc公司].
[Unicode码]第3.1节给出了引用属性的处方：
对Unicode字符属性的引用
属性和属性值具有定义的名称和缩写，例如
属性：General_Category（gc）
属性值：大写字母（Lu）
引用给定属性和属性值，则使用这些别名，如本例所示：
属性值General_Category属性中的Uppercase_Letter，作为在Unicode标准14.0.0版中指定。
然后引用该版本标准，使用为每个版本提供的标准引文格式Unicode标准。
附加参考示例在线提供。
Unicode字符数据库[UCD公司]是主要的机器可读字符属性的存储库。它由一个包含属性数据的文件数量，以及解释数据库组织以及数据库的格式和含义的文档文件属性数据。主文件“Unicode字符数据库“[UCDDoc公司]解释当前的总体组织UCD的版本，并告知哪些文件包含哪些属性。
当Unicode联盟努力将更改字符属性数据，有时更改的字符属性已经编码的字符必须是已更新。当这种情况发生时，Unicode的相关数据文件修改了字符数据库。修改后的数据文件发布在Unicode上网站作为标准的更新版本。
字符代码点、字符名称和参考字形，以及一些字符的摘录属性并通过附加注释进行扩展，可以在字符中找到代码[图表].
- 以下给出了与字符属性。在可能的情况下，这些定义与形式第3章中的定义，合规性，在[Unicode码]. 在这些情况下，定义的原始编号在每个定义的末尾用方括号括起来。尽可能地本文件中的定义编号将作为新定义保留补充。当在其他上下文中，通常在定义的术语前面加上术语“Unicode”指示上下文。例如，“字符属性”变为“Unicode字符属性”等。
- PD1.属性
- Unicode标准中实体的命名属性，与定义的一组值。【D19】
- PD2.代码点属性
- 代码点的属性。【D20】
- 代码点属性定义一组值和每个值的映射Unicode代码指向集合中的一个值。
- PD3.抽象字符属性
- 抽象字符的属性。[第21页]
- PD4.编码字符属性。
- Unicode标准中编码字符的属性。[第22页]
编码字符属性定义一组值和每个值的映射Unicode代码指向该集合的一个值。
- 编码字符属性通常将默认值映射到任何代码点分配给一个角色。
在本文档的其余部分中，与Unicode标准中一样，术语“字符属性”或不带限定符的术语“属性”包括这两者字符和码位属性及其组合形式，编码字符属性。
- PD5.属性值
- 与属性关联的一组值之一。[D23-但在那里限制为“编码字符属性”]
例如，东亚宽度[EAW公司] 属性的可能值为“Narrow”、“Neutral”、，“宽”、“模糊”和“未分配”。请参见[别名] 和[值别名]有关的标签列表属性及其值。
- PD6.显式属性值
- 编码字符属性的值与Unicode数据文件之一中的代码点关联字符数据库。[第24页]
- PD7.隐式属性值
- 编码字符属性的值，由通用规则或Unicode字符数据库中某个数据文件中的“otherwise”子句给定。[第25页]
- PD8.默认属性值
- 属性的值（在某些情况下是一组较小的值）与未分配的代码点或编码字符关联属性无关。[第26页]
- 注：每个属性可能有多个默认值不同范围的不同值，如Bidi属性中的值。
- PD9.枚举属性
- 拥有一小套命名值。[D27]
- 当字符添加到Unicode标准中时，值集可能未来需要扩展，但是枚举属性（例如LineBreak属性）具有一组相对固定的可能值。
- PD10.闭合枚举
- 一个枚举属性，其值集已关闭，并且不会扩展到未来版本的Unicode标准。[第28页]
- 注释：目前，General_Category和Bidi_Class属性是唯一关闭的枚举，布尔属性除外。
- PD11.布尔属性
- 一个封闭枚举属性，其值集限制为“true”和“false”。[第29页]
- 财产的存在与否至关重要信息。
布尔属性有时称为“单值”属性，因为“false”通常具有“此属性不适用”的含义。
- PD12.数字属性
- 数字属性是一种属性其值是可以接受任何整数或实数的数字。[第30天]
- 例如，Numeric_Value属性。没有财产可能不同值数量的隐含限制，除了表示整数或实数的限制在计算机中。
- PD13.字符串值属性
- 值为字符串的属性。[D31]
- 字符串值属性是指共域或一组值，由字符串组成。（参见PD32。）
- 正则分解属性是一个字符串值属性。
注：分类属性[UCDDoc公司]类型为“字符串值”是字符串值属性。然而，一些属性被归类为“杂项”也是字符串值属性。
- PD13a：标识符属性
- 一个字符串值属性，表示命名空间的成员定义标识符格式良好性、唯一性和比较的规则。
- 例如，Unicode字符名是命名空间的一部分，其中还包括名称别名和命名序列。定义了用于比较名称和确定唯一性的特殊规则，以及允许哪些字符。参见第4.8节名称[Unicode码].
- PD14.Catalog属性
- 属于枚举属性，通常与一种可以扩展的算法在Unicode的每个后续版本中标准。[第32天]
例如“年龄”、“块”和“脚本”属性。可以向集合中添加其他新值每次修订标准时的枚举值。每个新的Unicode版本都会为Age添加一个新值。将新块添加到标准中时，会添加相应的新值到Block属性。同样，当添加新脚本时，对应的还添加了Script属性的新值。
- PD15.其他属性
- 不是Boolean、Enumerated、Numeric、，字符串值、标识符或目录。
- Script_Extensions属性是一个杂项属性。
注：事实上，有些属性属于[UCDDoc公司]作为“其他”类型也可以被视为字符串值属性。这个Jamo_Short_姓名property就是这样一个例子。区别在于，大多数当前指定为类型的属性“字符串值”被认为是来自某些Unicode的映射字符转换为其他Unicode字符（或字符序列）作为大小写映射、大小写折叠或字符串规范化的操作，而的字符串值杂项属性往往只是任意的字符串。
- PD16.规范性属性
- Unicode规范中使用的[Unicode字符]属性标准。[第33天]
- 注释：依赖于规范和可测试的方式通常是指定属性的充分理由作为规范。对于示例，解释双向类确实如此定义于[比迪].
- 如果进程没有解释给定的字符，它可能仍然不知道它的属性。但是，建议进程对不处理的字符使用精心选择的默认值。
- 另见第2.6节，规范性属性。
- PD17.可撤销财产
- 一种规范性属性，其值可以被一致的高级协议覆盖。[第34天]
- 见第4.3节通过覆盖属性高级协议。
- PD18.信息属性
- 为信息提供值的[Unicode字符]属性只有。[第35天]
- 注释：信息属性捕获专家实施联合体强烈推荐经验及其使用，但对Unicode的实现没有要求标准。
- 另见第2.7节，信息属性。
- PD19。临时财产
- 一个[Unicode字符]属性，其值是未经批准的暂定值，并且可能不完整或不处于可用状态。[第36页]
临时属性可能会从标准的未来版本中删除，无需事先通知。
- 另见第5.4节，临时财产。
以下定义不定义字符或代码点属性，而是定义这些属性。在本节的定义中术语“代码点”包括用于表示代码点属性的代码点和字符属性。
- PD20.上下文相关属性
- 应用于较长代码点序列上下文中的代码点的属性。[第37页]
例如，希腊sigma的小写映射取决于周围的字符。另请参见PD33：C类依赖于上下文字符串函数。
- PD21.上下文无关属性
- 不依赖于上下文的属性：它单独应用于代码点。[第38天]
- PD22.稳定转换
- 转变T型在财产上P（P）相对于算法A类，如果算法对转换的属性的结果A类(T型(P（P）))与原始结果相同A类(P（P）)用于所有代码点。[第39天]
- PD23.稳定性能
- 属性相对于特定算法或进程是稳定的，只要对属性值赋值的更改进行限制属性上的算法继续与所有属性的原始结果相同以前分配的代码点。【D40】
- 例如，当正则组合的绝对值类是不保证Unicode的不同版本之间相同标准，将保持其相对值。因此规范组合类虽然不是一成不变的，但却是稳定的中定义的规范化表单的属性[正常].
- 注：由于新字符被分配给以前未分配的代码点，将这些代码点的任何默认值替换为实际值属性值必须保持稳定。
- PD24.固定资产
- 其值（默认值除外）一旦关联的属性带有字符或其他指定代码点，是固定的并且不会被更改，除非是为了纠正明显的或笔误。【D41】
- 对于固定属性，可以替换任何默认值，而无需由于分配了新字符，因此受到实际属性值的限制以前未分配的代码点。固定属性的示例有Age或Hangul音节Type。
- 注：将属性指定为固定并不意味着稳定性或不变性，请参见下文。例如，字符的年龄是由Unicode版本确定的添加该属性的标准，属性值的已发布列表中的错误可以是已更正。对于其他人属性，则有明确的稳定性保证，禁止甚至纠正这些错误。参见第节5.2稳定性保证。
- PD25.不可变属性
- 也受到稳定性保证的固定财产预防任何已发布的特性值列表中的更改而不是将新值分配给以前未分配的代码点。【D42】
- 不可变属性相对于全部的算法。Unicode字符是不可变属性的一个示例名称。见第5.2节稳定性保证。
- 注：因为字符名是不可变属性的值，所以拼写错误不正确的名字会从未得到纠正。任何勘误表都将在在姓名列表中添加注释，并在需要时添加信息字符名称别名将为提供了。
- PD26.稳定属性
- 既不扩展到新字符，也不维护的属性以任何其他方式，但保留在Unicode字符中数据库。【D43】
- 稳定属性也是固定资产。
- PD27.不推荐的属性
- 不鼓励实现使用的属性。【D44】
属性可能被弃用的原因之一是属性的组合可以更好地表达预期的语义。
- 在哪里？已弃用的属性有足够广泛的遗留支持，并非所有实现都能够停止使用不推荐使用的属性。在这种情况下，不推荐使用的属性可以扩展为新的字符，以使其保持可用和一致的状态。
- PD28.简单属性
- 其值直接在Unicode字符中指定的属性数据库（或Unicode标准中的其他地方），其值不能从其他简单属性派生而来。【D45】
- PD29.派生属性
- 一种属性，其值通过算法从某些简单属性的组合。【D46】
- PD30.属性别名
- 特定[Unicode字符]属性的唯一标识符。【D47】
- 属性别名集形成一个名称空间。参见第2.8节参考属性。
- PD31.属性值别名
- 特定枚举值的唯一标识符[Unicode字符]属性。[第48页]
每个属性的属性值别名集形成一个单独的命名空间。来自不同属性的值可能具有非唯一的名称。作为一个例如，所有布尔属性的属性值别名为“true”和“false”。
另见第2.8节参考属性。
3.6串
本节介绍字符串的定义字符串的属性和字符串函数在字符属性模型。
- PD32.字符串
- 零个或多个代码点的有序序列。
- 在最一般的情况下，字符串是任何编码字符序列但扩展概念以涵盖空序列。字符映射很常见值为的属性示例串但是不一定Unicode字符串。
- 中的所有代码点一串来自相同的字符编码。
- PD32a。空字符串
- 由零个代码点组成的字符串。
- 注意，原则上任何空字符串都等同于任何其他空字符串，因此在许多上下文中，空字符串的实例简称为这个空字符串。
以下三个与字符串相关的定义是Unicode标准第3章一致性中规定[Unicode码].
- PD32b。代码单元顺序
- 一个或多个代码单元的有序序列。【D78】
- 代码单元序列可以由单个代码单元组成。
- PD32c。Unicode字符串
- 包含特定Unicode编码形式的代码单元的代码单元序列。[D80]
- 单个Unicode字符串只能包含来自单个Unicode的代码单元编码形式。不允许在字符串中混合形式。
- PD32天。编码字符序列
- 一个或多个代码点的有序序列[D12]。
- 编码字符序列也称为编码字符表示。
- 通常，编码字符序列由编码字符序列组成，但也可以包括非字符或保留的代码点。
这些定义最初是为了关注身份已编码的字符和，共个编码字符序列，在指定Unicode编码形式和Unicode标准的其他概念。因此，正式定义不包括零长度序列作为其定义的一部分。第3章中使用了这些定义，这个缺席角色的通常与解释无关。
然而，在编程上下文中，字符串几乎总是定义为包括空字符串作为类或类型定义的一部分。这对于字符串的实现和基于字符串的API的设计来说更加优雅，包括那些支持字符属性实现的。这种区别很重要用于讨论Unicode字符属性模型。当字符属性被扩展以处理Unicode字符串的属性，除了单个字符外，实现还需要使用将字符串清空到帐户中。
在Unicode字符属性模型中，主要关注点是具有字符（或代码点）的属性，而不是非常有限的概念可能直接应用于代码单元的属性。为了避免术语，而不是使用正式定义“编码字符序列”学期Unicode字符串在这种情况下，简单地规定也指一种编码字符序列，而不仅仅是编码单元序列。
此外，在随后的讨论字符串的属性，以简化表示，任何提及Unicode字符串还规定扩展至包括这个空字符串。
以下定义均未在Unicode标准中找到这一点；它们扩展了现有的定义，以涵盖字符序列的属性。
- PD32e。枚举字符串集
- 由显式有限成员列表枚举的一组Unicode字符串。
- 此定义被指定为集合而不是列表，因为通常它对于的实现没有意义相同的要包括的序列多次。
- 注意，空字符串可以显式地列为集合的成员，适用于某些边缘情况。
- 此定义与规则或定义，例如组合字符序列[D56]。
- PD32f.字符串的属性
- 一种字符属性，其域扩展到Unicode字符串，而不是单个字符串代码点。
- 属性类型、值和状态的分类与编码字符属性。
- PD32g.字符串的显式属性
- 显式指定每个值的字符串属性对于特定枚举字符串集的每个成员。
- 字符串的显式属性的一个示例是RGI_Emoji_Flag_序列。这是一个简单的布尔属性，但其域是表情符号序列集在数据文件emoji-sequences.txt中明确列出。如果特定序列是在该文件中列出，然后该文件的RGI_Emoji_Flag_Sequence属性的值序列为True。否则，任何其他Unicode字符串都为False，包括空字符串。
- RGI_Emoji_Flag_Sequence也是字符串规范属性的一个示例：它在Unicode规范中正式定义，并在更新的数据文件中维护在每个版本中，并对emoji的实现具有一致性影响。
- 通常，字符串的显式属性的类型为Boolean：给定的序列是否是集合的成员。然而，原则上还可以定义更复杂的类型以应用于枚举集的成员字符串的数量。
- PD32h.字符串的算法性质
- 值由应用的字符串函数确定的字符串的属性到整个字符串（偏移量0和n）。
- 字符串的算法属性的一个示例是是小写.那个属性在第3.13节，Unicode标准的默认情况算法中定义[Unicode码]. 它具有布尔类型，并且为True或False对于任何Unicode字符串，但其值由以下算法确定：包括设置Unicode字符串的大小写并检查该操作的结果。
- 字符串的算法属性的另一个示例是是表情符号序列。该属性未在Unicode中正式定义技术标准#51，Unicode Emoji[UTS51标准]，但确实如此根据该规范中ED-14的定义表情符号序列。定义表情符号序列的BNF可以在算法上应用于任何给定的Unicode字符串以确定该序列是否符合形式语法定义与否。该决定不需要对照显式枚举字符序列集。事实上相比之下，字符串的显式属性RGI_Emoji_Flag_Sequence，允许从所有可能的语法正确的表情符号域中挑选出来标记序列，仅emoji-sequences.txt中列出的精确集合建议用于通用互通式立交。RGI状态不是算法状态可派生，并且只能通过提供枚举要测试的字符串集。
以下定义均未在Unicode标准中找到然而，这一点在讨论Unicode时非常有用算法及其与属性的关系。
- PD33.偏移
- 字符串中的偏移量是从0到n个哪里n个是字符串的长度（以代码点为单位）。它指示代码点之间的逻辑位置。偏移量为0表示字符串中第一个代码点之前的位置，以及偏移量n个指示字符串中最后一个代码点之后的位置。
在代码单元级别处理偏移量是较低级别关注的问题实现过程，必须处理字符编码形式的细节。对于字符属性模型的目的是在编码字符序列和代码点的术语。
- PD34.[删除定义]
-
- PD35.字符串函数
- 字符串函数是其输入为字符串的函数S公司和两个偏移一和b条，带有一≤b条。
- PD36.文本边界属性
- 为定义值的字符串函数特定偏移量。
文本边界函数也称为分段函数，因为它们通常用于返回边界之间的文本段。简单的文本边界函数，如IsBreak（S，a，b）最小限度地返回布尔值。但是，其他文本边界函数可能会返回其他信息。例如，单词选择边界函数可以返回前一段包含字母，或linebreak函数可能返回有关中断相对优先级的信息。
- PD37.上下文相关字符串函数
- 给定一个字符串S公司、和偏移一和b条，上下文相关字符串函数是任何字符串函数F类对于其中F类(S、 a、b) 独立于的内容S公司之前一以及之后b条。
换句话说，上下文相关函数的输入是完全的由给定偏移之间的代码点定义。
- PD38。上下文相关字符串功能
- 上下文相关字符串函数是不依赖于上下文的字符串函数。
换句话说，上下文相关字符串函数的输入需要其他信息，例如关于围绕定义的代码点范围的代码点的信息偏移量以及代码点在范围内。表单的任何文本边界函数B类(S、 x，x) 根据定义，它依赖于上下文。
- PD39.字符串转换
- 字符串值字符串函数。
- PD40.幂等字符串函数（折叠）
- 字符串转换F类，具有重复的属性相同功能的应用F类产生相同的输出：F类(F类(S公司)) =F类(S公司) 对于所有输入字符串S公司。
- 这样的字符串函数也称为折叠。
- 折叠建立了等价关系，其中X≡Y当且仅当F（X）=F（Y）。这个等价关系将所有字符串集划分为的等价类集关系。相反，字符串的任何分区都可以用于生成折叠，通过选择每个分区的一个元素作为“目标成员”分区的成员映射到的。
符号toX可用于折叠，以及对应二进制函数的isX（s），定义为isX当且仅当toX（s）=s。例如，toNFC（）是转换为NFC格式，而isNFC（）是测试字符串是否在这种格式。
- 一个众所周知的例子折叠功能是箱子折叠。对于案例折叠，等价类由所有大小写变体组成，包括大写、小写、标题大小写和混合情况。在Unicode案例折叠的情况下，选择目标成员为小写字符。
- 折叠功能可能是上下文依赖。规范化是一种上下文相关折叠的示例。
- PD41.代码点计数保留字符串函数
- 一种字符串函数，其结果是包含相同数量的代码点因为它的输入是一个保持计数的字符串功能。
- PD42.缓冲区长度保留字符串函数
- 一个字符串函数，其结果是包含相同数量的代码单位因为它的输入是一个保留缓冲区长度的字符串函数。
- PD43.高级协议
- 任何关于扩展Unicode字符解释的协议超出了Unicode标准的范围。【D16】
本技术报告未定义一致性要求，但以下小节讨论并总结一致性要求与Unicode标准中规定的字符属性相关。在适用的情况下，相应的一致性条款或定义的编号用方括号括起来。
在第3章，一致性，Unicode标准[Unicode码]状态 那个“过程应根据角色 该标准建立的语义，如果该过程确实解释了编码的字符序列。"[C4]通过采用字符的编码表示来建立字符的语义，上下文中的字符名和代表符号由其规范属性和行为。既不是字符名也不是具有代表性的象形文字是绝对可靠的；字符可以有使用范围比其性质的字面解释更广名称，并且代表性符号仅表示一个范围代表相同字符的典型符号。
指定了Unicode算法作为对字符输入执行的一系列理想化步骤（规则）代码及其相关属性。[Unicode码]状态：
- 声明符合Unicode算法的实现只需要担保它生成的结果与逻辑的描述过程；不需要遵循实际描述详细程序。这个允许在中使用替代策略和优化实施。参见[C18]。
只要结果相同实现时，实现也不需要使用实际在中发布的属性[UCD公司].覆盖因此，属性值不一定意味着属性赋值，仅仅是算法现在产生的结果与属性值理想算法的描述发生了变化。
在讨论中字符语义，Unicode标准[Unicode码] 使此语句关于重写属性和角色行为：
一些规范行为是默认行为；这种行为可以是被更高级别的协议覆盖。然而，如果没有协议，必须遵守行为以遵循角色语义。见[D3]。
被更高级别覆盖协议在概念上可以有多种形式，包括但不限于：
- 为算法提供人工上下文定义了上下文相关字符串函数
- 在子串上应用该算法
- 模拟的效果标记中的格式控制字符
- 重新分配不同的处理或呈现期间字符的属性值
- 更改的结果特定输入的字符串函数
覆盖涉及规范属性，适用特定限制，例如：
•字符组合属性和规范排序行为不能被更高级别的协议覆盖。见[D3]。
有关高级协议的其他示例及其限制，请参阅中的第4.3节UAX#9：Unicode双向算法[比迪]. 例如，有些规范属性是完全可重写的一般类别。
另一方面，任何和所有信息属性都可能被覆盖。然而，如果这样做会更改Unicode算法的结果，则任何希望符合该算法的实现必须指示已应用覆盖。
需要更新Unicode字符数据库的属性有三个原因：
- 涵盖添加到Unicode标准中的新字符
- 添加新特性
- 为某些字符更改特性的指定值
Unicode联盟努力保持所有字符的值属性尽可能稳定，可能会出现一些情况需要更改它们。更改角色的属性指定可能会现有影响实现，因此要明智地使用非常小心，只有在没有更好的选择时。
特别是，由于Unicode编码的脚本文档较少，例如那些是针对少数民族语言的当脚本首先进行编码。这些字符的属性是预计将随着信息的可用而更改。
作为随着实现经验的增长，可能需要重新调整属性值。这些调整尽可能兼容按照既定惯例。有时，字符属性是更改以防止基于字符的标称属性值对字符的使用进行不正确的概括。例如，U+200B零宽度空格最初被归类为空格字符（通用类别=Z），但现在被归类为正式控制（gc=Cf）将此换行符控件与空格字符区分开来。
在其他情况下需要更正的原始信息。
[联合技术公司] 仔细权衡改变的成本与纠正的好处。在此外，所有属性更新受下一节所述稳定性保证的约束。
Unicode保证字符分配的稳定性；也就是说身份在给定位置编码的字符将保持不变。一旦对字符进行编码，其属性可能仍然被更改，但不以这样一种方式改变角色的基本身份。
例如，的代表性字形U+0041“A”无法更改为“B”；将军U+0041“A”的类别无法更改为Ll（小写字母）；而U+00C1（á）的分解映射不能为更改为<U+0042，U+0301>（B，´）。
此外，对于某些属性，以下一个或多个方面是保证不变：
- 赋值稳定性
- 应用该属性时结果的稳定性
- 属性值集的稳定性
- 与另一属性关系的稳定性
- 文件格式的稳定性
对于最新的所有有效稳定性保证的规范参见Unicode字符编码稳定性政策[稳定性]. 请注意，属性的状态作为规范并不意味着稳定性保证。
赋值稳定性是不可变的属性。对于例如，一旦对字符进行编码，其代码点和名称为不可变属性。不可变属性允许软件和文档引用其值而无需跟踪标准的未来更新。不可变属性的一个副作用是属性值中的错误无法修复。例如，命名错误如下在中添加注释注释中或使用别名，但正式名称保持不变，即使在明文规定的情况下印刷错误。
因为Code_Point是一个不可变属性被认为是不必要的，或者是现有的字符，它将不会被删除。相反，可以给它额外的属性，已弃用，强烈反对使用。然而，所有现有文件的解释角色保持不变。
结果的稳定性是稳定的属性。对于例如，一旦对字符进行编码，它的规范组合类和分解（规范或兼容性）相对于标准化。归一化稳定性定义如下如果字符串只包含给定版本的Unicode标准（比如Unicode 3.2），并将其转换为规范化形式根据该版本的Unicode，那么它将被规范化根据任何未来版本的Unicode进行规范化时的格式。
然而，与字符代码和字符名称，一些保证稳定的属性可以在中进行更正例外Unicode明确定义的情况字符编码稳定性策略[稳定性]. 除其他外要求，更正必须是明显的错误，例如印刷错误，任何替代方案都必须破坏相关角色的身份。允许这种严格限制的例外情况，就不需要对重复字符进行简单编码，以纠正书写或其他明显的错误属性分配中的错误。
对于大多数特性，可以创建其他特性值并将其分配给新字符和现有字符。例如，其他换行类如果发现字符需要换行，则将分配无法用现有类集表示的行为。对于其他属性的值集保证是固定的，或者它们的范围是有限。例如，General_Category或Bidirectional_Class是固定的，而组合类的值限制在0到254之间。
在许多情况下，一旦一个字符的某个属性具有特定值，它就是可能对给定的其他属性具有特定的值。这些关系Unicode Consortium在为新字符分配属性时使用，以及评估属性的内部一致性。在某些情况下，例如依赖关系是明确保证和稳定的。例如，除一般类别M*以外的所有字符都具有组合类0。
原则上，属性信息以Unicode表示的方式字符数据库独立于此信息的定义方式。然而，随着Unicode标准的更新实现在文件格式保持不变时跟踪更新数据组织方式的各个方面可以保持稳定。对于大多数人对于房地产而言，这种稳定性是开发过程的非正式目标，但在少数情况下，数据组织的某些方面由正式的稳定性保证。
例如，规范映射和兼容性映射始终按规范顺序进行，由此产生的递归分解也将是规范的订单。规范映射也总是限制为单个值或一双。这对字符中的第二个字符本身不能有规范映射。
作为分号分隔文本文件的传统约定的替代方法，Unicode字符数据库现在也可以作为单个XML文件使用。请参见UAX#42 Unicode字符数据库XML格式[XML格式].
在理想情况下，所有角色属性都是完美的自我一致性，相关属性将与在代码点的整个范围内相互作用。然而，Unicode标准是许多妥协的产物。它必须在相似性状处理的一致性，以及与现有性状的兼容性从传统编码继承的字符的实践。因为这个平衡行为，可以预期性格中会有一定数量的异常属性。
有时，实现有目的地覆盖某些异常属性值，增加算法的效率和一致性产品与本标准。见第4章，字符属性在[Unicode码]对一些人来说示例。
分配给新的属性值添加到Unicode标准中的字符通常定义为字符被赋予一致的值，除非有故意的例外需要。对于某些属性，该属性与定义了一个或多个其他属性。例如，对于LineBreak属性，许多换行类是相对于“常规类别”定义的值。
有一些相互关联的属性或由其他属性的组合派生而来，无论是否具有显式异常列表。当属性分配给新分配的字符，或在调整属性时，有必要考虑所有现有的相关属性，任何推导与派生属性的关系，以及所有属性稳定性保证。
提供的有关Unicode字符中字符的一些信息数据库构成临时数据。临时财产数据可能会被捕获部分或初步信息。此类数据可能包含错误或遗漏，或未准备好系统使用；然而，临时财产数据包含在数据文件中进行分发，部分是为了鼓励审查和改进信息。例如，许多标记Unihan数据库中提供了各种临时属性值关于汉字。
偶尔，作为标准成熟，并且定义了新的字符、属性或算法现有属性中显示的信息可以通过其他属性，或者将属性扩展到新字符可能不再有意义。这样，在未来版本的Unicode标准。在这种情况下，它将被指定为稳定的。对于向后兼容，稳定的属性仍将是Unicode的一部分字符数据库，但不会更新或更正。
稳定特性的一个示例是连字符。
有限的属性仅适用于字符的子集。这些在哪里属性被实现为Unicode代码空间的一个分区，该属性不适用的字符将被赋予一个特殊值，表示该属性不适用。“不适用”值可能是显式的值“NA”，或者对于某些属性，采用其他值，例如“XX”。
实现通常需要特定的属性全部的代码点，包括那些未分配的。为了满足这一需求，Unicode标准将默认属性分配给未分配的代码点范围。
Unicode标准的所有实现都应该努力处理优雅地添加到角色剧目中。在某些情况下，这可能要求实现尝试“预测”可能的属性值对于尚未定义字符的代码点，但其中周围字符的存在使得类似字符很可能将分配给有问题的代码点。
有三种策略：
- 依靠Unicode联盟的建议。例如，对于Unicode联盟发布了推荐的双向类所有代码点的默认值。有关这些建议的详细信息有关各种属性，请参阅[UCDDoc公司].
- 将给定字符块的未分配区域视为块的其他字符通用的属性值。的变体该方案通过使用包围孔的字符的属性值。
- 给一个未分配的代码点实现定义的默认属性这将导致优雅的行为，如果不是完全正确的行为随后在该编码点分配一个编码字符。
每种策略都有优点和缺点，没有一种可以确保实现的行为符合先前的Unicode标准版本将支持在以后的Unicode标准的版本，与实现方式完全相同这与后来的版本一致。最有希望的是早期的实现在这种情况下会表现得更优雅。
原则上，默认值是临时的：它们被最终赋值所取代一旦将字符分配给给定的代码点。
对于非字符代码点，字符属性函数将返回相同的值作为未分配字符的默认值。
有时，可以确定和分配财产价值，但它所依据的信息可能是不完整的或初步的。在在这种情况下，当更好的信息变为可用。目前，没有机器可读的方式来提供信息财产转让的可信度；然而定义属性的标准或技术报告可提供通用信息显示财产转让的初步状态已知。
这与临时财产, 其中整个财产是初步的。
Asmus Freytag是本报告的最初作者内容由Ken Whistler提供。
编辑们想感谢马克·戴维斯（Mark Davis）贡献和洞察力评论和朱莉·艾伦博士的广泛文案编辑。伊万·潘琴科提供了一份仔细的副本编辑和排版列表，以修复第15版。
以下总结对本文档先前版本的修改。
修订版15[AF，KW]
可以通过标题中的“上一版本”链接访问上一版本。
©2022 Unicode，Inc.保留所有权利。Unicode Consortium不做任何形式的明示或暗示担保，并不对错误或遗漏承担任何责任。不承担任何责任与之相关或由此产生的附带和间接损害包含或附带的信息或程序的使用技术报告。Unicode码使用条款适用。
Unicode和Unicode徽标是Unicode，Inc.的商标在某些司法管辖区注册。
![[统一码]](https://www.unicode.org/webscripts/logo60s2.gif){kind=small}