4演示风格
4.1表情符号和文本呈现选择器
4.2表情符号区域扩展
4.3表情符号脚本代码
4.4 Emoji 呈现控制的其他方法
6输入
表：调色板输入
7搜索
附件 A：表情符号属性和数据文件
表：表情符号字符属性
A.1数据文件
表：数据文件
附件 B：有效的 Emoji 标志序列
B.1介绍
B.2订购
附件 C：有效的表情符号标签序列
有多种方法可以计算 Unicode 中的表情符号，特别是因为表情符号序列可能显示为单个表情符号图像。以下概述了计算表情符号的方法；它可以是（例如）：
可以在 emoji 中使用的代码点的数量，尽管这包括一些仅用作序列的一部分并且本身没有表情符号外观的代码点；
可以显示为单个字形的一个或多个字符的所有序列（这可能更接近用户认为的表情符号数量），尽管通常只有可能序列的子集在任何平台上显示为单个字形，并且一些序列可能是特定于平台的扩展。
建议任何旨在支持 Unicode 表情符号的字体或键盘都应支持 [emoji-data] 数据文件中列出的字符和序列。完整集的最佳定义在 emoji-test.txt 文件中。
Emoji Counts, v14.0图表提供了有关本规范当前版本的各种计数的更多详细信息。Emoji Counts Key中描述了各种列和行标题 。
图表中的“小计”行表示用户通常认为的表情符号的数量。例如，其中不包括 26 个区域指标 (RI) 代码点；即使它们具有 Emoji 状态，它们通常仅成对使用来表示标志。
典型的键盘通常会显示更少的表情符号，因为它们可能使用长按等机制来显示特定表情符号的修饰符序列，因此不会同时显示与图表行相关的所有图像，这些图表行计算带有显式肤色的表情符号。
单独的 [emoji-charts] 提供了有关其中许多子集和其他子集的更多信息，例如：
最近发布的表情符号字符列在 最近添加的表情符号中。
在Emoji Candidates中可以找到 Unicode 未来版本的 候选表情符号。
4演示风格
某些表情符号定义了变体序列，其中一个表情符号字符后面可以跟一个不可见的表情符号表示选择器或文本表示选择器。
此功能是在Unicode 6.1中添加的。一些系统还可以通过更高级别的标记而不是变化序列来提供这种区别。有关这些选择器的更多信息，请参阅Emoji Presentation Sequences [emoji-charts]。有关在表情符号序列中使用表情符号或文本呈现选择器的详细信息，请参阅第 2.7 节，表情符号实现说明。
如果可能的话，实现应该支持带有表情符号的字符和文本表示序列的两种表示方式。这些字符中的大多数是与先前存在的字符统一的表情符号。因为人们现在使用表情符号表示更广泛的字符集，Unicode 9.0 为所有表情符号添加了表情符号和文本表示序列，并具有默认文本表示（参见下面的讨论）。这些是标有“默认文本样式”的列中显示的字符；文本与表情符号图表 [emoji-charts] 中的 U8.0 中没有 VS。
然而，即使在表情符号和文本表示选择器可用的情况下，实施者也不清楚象形图的默认表示应该是表情符号还是文本。这意味着当跨平台共享时，一段文本可能会以不同于预期的样式显示。虽然这对于 Unicode 字符来说是完全合法的——永远无法保证呈现风格——但开发人员之间对何时使用表情符号呈现的共识很重要，这样可以减少意外或不和谐的呈现。实现需要知道通常预期的默认表示是什么，以促进跨平台和应用程序的互操作性。
对于实现者来说，三类 Unicode 字符之间没有明确的界限：
emoji-default：那些希望默认有表情符号演示的人，但也可以有文本演示
text-default：那些期望默认有文本显示，但也可以有表情符号显示的人
text-only：那些应该只有文本演示的
可以使用附件 A：表情符号属性和数据文件中列出的属性来区分这些类别。第一类是Emoji=Yes和Emoji_Presentation=Yes的字符。第二类是Emoji=Yes 和Emoji_Presentation=No的字符。第三类是Emoji=No的字符。
给定表情符号字符的呈现取决于环境、是否存在表情符号或文本呈现选择器以及默认呈现样式（表情符号与文本）。在短信和聊天等非正式环境中，大多数表情符号字符更适合以彩色表情符号呈现，并且仅获得带有文本呈现选择器的文本呈现。反之，在文字处理等正式环境中，一般情况下，emoji 字符最好以文本呈现形式出现，而仅通过 emoji 呈现选择器获得彩色 emoji 呈现。
基于这些因素，这里是典型的演示行为。但是，这些指南可能会随着用户期望的变化而变化。
td {white-space:pre-wrap;border:1px solid #dee0e3;}示例环境带有表情符号演示选择器带有文本演示选择器两者都没有
文本默认表情符号-默认
字处理
普通网页
发短信、聊天
4.1表情符号和文本呈现选择器
每个带有默认文本呈现的表情符号字符都允许使用表情符号或文本呈现选择器。因此，可以逐个字符地控制这些字符的显示。可以应用这些选择器的字符列在表情符号变化序列 [emoji-charts] 中。
此外，接下来的两节描述了用于全局控制表情符号呈现的另外两种机制：使用带有语言环境扩展的语言标签，或使用特殊的脚本代码。尽管这些是新机制，尚未得到广泛支持，但鼓励供应商支持大多数一般用途的语言环境扩展，例如在浏览器中；特殊脚本代码可能适用于更具体的用途，例如 OpenType 字体选择或 API。有关详细信息，请参阅 [CLDR]。
4.2表情符号区域扩展
区域设置扩展“-em”可用于为可能同时具有文本样式和表情符号样式演示的字符指定所需的演示。可以使用三个值，这里用“sr-Latn”说明：
td {white-space:pre-wrap;border:1px solid #dee0e3;}语言环境代码描述
sr-Latn-u-em-表情符号尽可能为表情符号字符使用表情符号演示
sr-Latn-u-em-文本尽可能为表情符号字符使用文本演示
sr-Latn-u-em-默认值使用默认表示（仅需要重置继承的 -em 设置）。
这可以在 HTML 中使用，例如，与<html lang="sr-Latn-u-em-emoji">. 请注意，这种方法没有下面列出的脚本标签方法的缺点。
4.3表情符号脚本代码
两个脚本子标签可用于控制演示风格。这些使用 ISO 15924 定义的脚本代码，但 CLDR 给出了更具体的语义，请参阅unicode_script_subtag：
Zsye—对于同时具有文本和表情符号样式的字符，首选表情符号样式。
Zsym——对于同时具有文本和表情符号样式的字符，首选文本样式。
这些脚本代码不适合在通用语言标签中使用：
它们不能与语言-文字组合一起使用；例如，如果语言是 sr-Latn（拉丁文中的塞尔维亚语），则不能使用 Zsye。
它们可能会混淆依赖于语言标签的进程，例如拼写检查器。
但是，它们本身在特定上下文中（例如 OpenType 字体选择）或在采用脚本代码的 API 中可能很有用。
4.4 Emoji 呈现控制的其他方法
其他控制表情符号呈现的方法也在使用中。例如，在某些 CSS 实现中，如果查找列表中的任何字体是 emoji 字体，则尽可能使用 emoji 表示。
Unicode 代码点顺序和 Unicode 排序算法 (DUCET) 提供的默认排序规则目前都不太适合表情符号，因为它们分隔了概念上相关的字符。从用户的角度来看，以下按 DUCET 排序的字符选择中的顺序显得非常随机，如下例所示：
表情符号排序 v14.0图表显示了表情符号字符 的 排序，以更自然的方式将它们组合在一起。该数据已纳入 [CLDR]。
这种排序为已排序的字符列表提供了更清晰和更符合预期的排序。分组包括：面孔、人物、身体部位、情感、服装、动物、植物、食物、地点、交通工具等。为了在输入调色板中进行选择，排序也更自然地分组。但是，对于排序，每个字符必须只出现在一个位置，这不是输入调色板的限制。请参阅第 6 节，输入。
6输入
表情符号通常不在键盘上键入。相反，它们通常是从调色板中挑选出来的，或者通过字典来识别。移动键盘通常有一个
按钮来选择表情符号的调色板，如下图左所示。单击该
按钮会显示一个调色板，如右图所示。
调色板需要以对用户有意义的方式进行组织。它们通常提供少量广泛的类别，例如人、自然等。这些类别通常有 100-200 个表情符号。
许多字符可以以多种方式分类：橙子既是植物又是食物。与排序顺序不同，输入调色板可以有单个字符的多个实例。因此，它可以扩展排序顺序，以便在人们可能会合理地寻找它们的任何分组中添加字符。
更高级的调色板将启用长按，以便人们可以按住表情符号并弹出一组相关的表情符号。这允许更快的导航，更少滚动调色板。
表情符号字符的注释是更精细的关键字。它们可用于搜索字符，并且通常比输入表情符号字符的调色板更容易。例如，当有人在手机上键入“沙漏”时，他们可以看到并从中选择匹配的表情符号字符
或
. 这通常比滚动调色板和目视检查屏幕要容易得多。输入机制也可以将表情符号映射到表情符号作为键盘快捷键：键入 :-) 可能会导致
.
在某些输入系统中，使用冒号括起来的单词或短语来明确选择表情符号字符。因此，输入“I saw an:ambulance:”会转换为“I saw an
”。为了完整起见，此类系统可能支持所有完整的 Unicode 名称，例如:first quarter moon with face:for
。短语中的空格可以用 _ 表示，如下所示：
“我的:alarm_clock: 没用”
→
“我
没有工作”。
然而，一般来说，完整的 Unicode 名称并不特别适合这种用途。它们被设计为唯一标识符，并且往往过于冗长或令人困惑。
对于具有性别和/或肤色变体的表情符号，输入系统应完全指定预期外观，而不是依赖特定系统的默认外观；参见例如第 2.3.2 节，在表情符号输入中标记性别。
7搜索
搜索包括在查询中搜索表情符号字符，以及在目标中查找表情符号字符。当它们将注释包含为同义词或提示时，这些是最有用的。例如，当有人
上搜索时，他们会看到“加油站”的匹配项。相反，在搜索引擎中搜索“gas pump”可以找到包含
. 同样，在电子邮件程序中搜索“gas pump”可以调出所有包含
.
调色板类别和注释都没有唯一性要求：表情符号应该出现在用户期望的任何地方。气泵
可能会出现在“物体”和“旅行”下；“ heart
”和“emotion”下的heart，
“animal”、“cat”和“heart”下的a。
注释是特定于语言的：在yelp.de
上搜索，有人会期望搜索
结果与“Tankstelle”匹配。因此，注释需要使用多种语言才能跨语言使用。它们还应该包括给定语言中的区域注释，例如“加油站”，人们希望
上进行搜索。英文注释不能简单地翻译成不同的语言，因为不同的单词在不同的语言中可能有不同的关联。表情符号
可能与美国的墨西哥或西南餐馆有关，但与希腊等地的餐馆无关。
如第 2.1 节Names中所述，还有另一种注释，称为 CLDR 短名称。这也称为TTS 名称，用于文本到语音处理，例如在阅读文本时提供简短的描述性表情符号名称以实现可访问性目的。在这种情况下，CLDR 名称比正式的 Unicode 字符名称提供了几个优点：
它们可以比正式名称更短且更简洁，后者对名称唯一性的要求通常会导致名称过长，例如BLACK RIGHT-POINTING TRIANGLE WITH DOUBLE VERTICAL BARfor
。
它们可以应用于由序列表示的表情符号以及由单个字符表示的表情符号。
它们可以更新以更好地反映当前的表情符号描述和使用。
TTS 名称也在本文档的当前范围之外。
除了表情符号字符之外，实现的长期目标应该是支持嵌入式图形。嵌入式图形允许任意表情符号，并且不依赖于额外的 Unicode 编码。这方面的一些例子可以在 Skype 和 LINE 中找到。
然而，要像表情符号一样有效且易于使用，完整的解决方案需要对基础设施进行重大更改，以允许在短信、聊天、手机、电子邮件程序、虚拟和移动键盘中简单、可靠地输入和传输图像（贴纸），等等。（即便如此，此类图像永远不会在仅支持纯文本的环境中交换，例如电子邮件地址。）在此之前，许多实现将需要使用 Unicode 表情符号。
例如，需要增强移动键盘。启用嵌入式图形将涉及添加额外的自定义机制，供用户添加自己的图形或购买额外的集合，例如
将图像添加到上面的调色板的标志。这将提示用户粘贴或以其他方式选择图形，并为字典选择添加注释。
使用这种增强的移动键盘，用户可以像选择 Unicode 表情符号一样选择这些图形。如果用户开始添加许多自定义图形，甚至可以增强移动键盘以允许对这些图形进行排序或组织，以便可以快速访问它们。如果移动键盘的目标（例如电子邮件标题行）只接受文本，则需要禁用额外的图形。
使嵌入式图形正常工作所需的其他功能包括图像随字体大小缩放的能力、在更多传输协议中包含嵌入式图像、切换服务和应用程序以使用允许包含嵌入式图像的协议（例如，MMS 与 SMS用于短信）。但是，总会有一些地方无法使用嵌入式图形，例如电子邮件标题、SMS 消息或文件名。嵌入式图形的实现也存在隐私方面的问题：如果图形本身没有与文本打包在一起，而只是对服务器上图像的引用，那么该服务器可以跟踪使用情况。
附件 A：表情符号属性和数据文件
以下二进制字符属性可用于表情符号字符。
td {white-space:pre-wrap;border:1px solid #dee0e3;}财产缩写属性值
表情符号表情符号=是表情符号字符
Emoji_PresentationEPRES=默认情况下具有表情符号的字符是
Emoji_Modifier模块=是表情符号修饰符的字符
Emoji_Modifier_BaseEBase=是的，对于可以作为表情符号修饰符基础的字符
Emoji_Component电子补偿=是的，用于表情符号序列中的字符通常不会作为单独的选项出现在表情符号键盘上，例如键帽基本字符或区域指示符字符。表情符号序列中的所有字符都是Emoji 或Emoji_Component。但是，实现不能假设所有Emoji_Component字符也是 Emoji。在各种表情符号序列中使用了一些非表情符号字符，例如标签字符和ZWJ。
扩展_象形外部图片=是的，用于面向未来的分割的字符。Extended_Pictographic字符包含除某些Emoji_Component字符之外的所有Emoji字符。
如果Emoji=No，则Emoji_Presentation=No、 Emoji_Modifier=No和Emoji_Modifier_Base=No。
A.1 数据文件
表情符号属性在表情符号数据文件中指定（参见 [emoji-data]）：
td {white-space:pre-wrap;border:1px solid #dee0e3;}表情符号数据.txt表情符号字符属性表中列出的属性的属性值
表情符号-变体-sequences.txt所有允许的表情符号呈现序列和文本呈现序列
emoji-zwj-sequences.txt用于表示 emoji 的 ZWJ 序列
表情符号-sequences.txt用于表示表情符号的其他序列
表情符号-test.txt表情符号字符和序列的测试文件
有关从表情符号数据文件和相关的 [ CLDR]表情符号数据（注释和排序）生成的图表集合， 请参阅 [emoji-charts ]。它们纯粹是说明性的；用于实现的数据在 [emoji-data] 中。
数据文件注释及其结构仅供参考，可能会在不同版本之间更改，恕不另行通知。有关数据文件中使用的版本约定，请参阅第 1.5.2 节，版本控制。
附件 B：有效的 Emoji 标志序列
虽然在ED-14中定义了格式良好的emoji 标志序列的语法，但只有有效的序列才会被一致的实现显示为标志，其中：
有效区域序列由[CLDR]中定义的Unicode 区域子标签指定，idStatus=regular、deprecated 或 macroregion。对于宏观区域，只有联合国和欧盟有效。
已弃用的区域包含在有效区域序列列表中，因此将来的弃用不会使以前有效的表情符号标志序列无效。建议支持带有已弃用区域的 RGI 表情符号标志序列。不应生成具有已弃用区域的非 RGI 表情符号标志序列。
Macroregion 区域序列通常没有官方标志，但UN和EU除外。
一些地区序列代表国家（例如联合国承认的）；其他代表与一个国家相关的领土。这些领土可能有自己的旗帜，也可能使用与它们相关的国家的旗帜。标志图像的描述可能会受到该地区管理部门的限制。
注意事项：
尽管一对 REGIONAL INDICATOR 符号被称为 emoji_flag_sequence，但它实际上代表了一个特定的区域，而不是该区域的特定标志。这对显示的实际旗帜在不同平台上可能不同，例如对于没有官方旗帜的地区。随着地区更改其标志和平台更新其软件，显示的标志可能会随着时间而变化。
对于某些地区（尤其是那些没有单独官方旗帜的地区），显示的旗帜可能与其相关国家的旗帜相同。有关字符具有相同外观的情况的更多信息，请参阅UTR #36：Unicode 安全注意事项[UTR36]。
有关更多信息，请参阅[Unicode] 的第 22.10 节，封闭式和正方形中的 区域指示符小节。
B.1 介绍
表情符号通常以正方形的纵横比呈现，这给标志带来了问题。卡塔尔的国旗比高度宽 150% 以上；瑞士是方形的；对于尼泊尔来说，它比宽度高 20% 以上。为了避免赎金效应，实现可能希望在所有标志中使用固定比率，例如 150%，顶部和底部有一个空白带。（旗帜的平均宽度在 150% 和 165% 之间。）作为挥舞旗帜或剪裁成圆形，可以帮助呈现统一的外观，从而掩盖外观差异。
标志应该有一个可见的边缘。一种选择是使用单像素灰线，以与相邻字段颜色形成对比。
有关一组开源标志图像（png 和 svg），请参阅region-flags
。
用于呈现系统没有特定标志或其他字形的 emoji_flag_sequence 的选项包括：
如 Unicode 图表中所示，将每个区域指标符号分别显示为虚线正方形中的一个字母。这提供了有关指定区域的信息，但可能会让某些用户感到困惑。
对于所有不受支持的 REGIONAL INDICATOR 对，显示相同的缺失标志字形，如下图所示。这将表明受支持的对旨在表示某个区域的标志，而不指出是哪一个。
B.2订购
标志的代码点顺序是按地区代码排列的，这对用户来说并不直观，因为这很少与用户语言中的国家/地区顺序相匹配。说英语的人对德国国旗出现在吉布提国旗之前感到惊讶。另一种方法是使用 [ CLDR]数据 根据本地化的国家名称呈现排序顺序。
附件 C：有效的表情符号标签序列
虽然ED-14a中定义了格式良好的表情符号标签序列的语法 ，但并非所有可能的标签序列都是有效的。此版本的 Unicode Emoji 中唯一有效的序列由本附件中的部分定义，这些部分指定了 字符和 序列的有效组合及其预期呈现方式。符合规范的实现仅将有效序列显示为表情符号，并显示无效序列并通过特殊表示来表明它们是无效的，例如在下面的示例中。
对有效的 emoji 标签序列有一个共同的限制：整个 emoji_tag_sequence，包括 tag_base 和 tag_end，不得超过 32 个代码点。这提供了许多渲染系统所需的实际限制，并且与UAX #15：Unicode 规范化表单[UAX15]中定义的流安全文本格式指定的 32 个代码点缓冲区限制一致 。
如果平台支持标签序列，但特定的表情符号标签序列无效或无法显示，则为了降低欺骗风险，应在可行的情况下使用缺失的表情符号字形显示表情符号标签序列。以下是示例，其中tag_base字符为黑旗。
td {white-space:pre-wrap;border:1px solid #dee0e3;}示例图像健康）状况
该实现支持标签序列，但此特定序列要么不受支持，要么根本无效。（如果字体技术允许，缺失的 emoji 字形可以覆盖在tag_base字符上，从而占据与支持序列相同的物理尺寸。）
该实现根本不支持标签序列。（标签字符通常是不可见的，因此只显示基本字符。）
在本节的示例中，带下划线的 ASCII 字符表示相应的标记字符，而✦表示tag_end.
一个有效的标志 emoji 标签序列必须满足以下约束：
和tag_base仅限tag_spec于以下情况：
td {white-space:pre-wrap;border:1px solid #dee0e3;}tag_baseU+1F3F4 黑旗
tag_spec(U+E0030 标记数字零 .. U+E0039 标记数字九，
U+E0061 标记拉丁文小写字母 A .. U+E007A 标记拉丁文小写字母 Z)+
令 SD 是tag_spec通过减去 0xE0000 将 中的每个字符映射到 [0-9a-z] 中的字符的结果。
SD 必须是根据 [CLDR] 的 Unicodesubdivision_id或 3 位unicode_region_subtag的规范，并且
SD 的 CLDR idStatus 必须等于“regular”或“deprecated”。
笔记：
已弃用的 SD 值包含在有效区域序列列表中，因此将来的弃用不会使以前有效的表情符号标签序列无效。建议支持具有已弃用 SD 值的 RGI 表情符号标签序列。不应生成具有已弃用 SD 值的非 RGI 表情符号标签序列。
中没有连字符，这tag_spec与“GB-SCT”等 ISO 细分不同。
这些标志表情符号标签序列用于为当前指定子区域的标志请求图像。与 emoji 标志序列一样，它们并非旨在为任何特定标志图像的版本化表示提供机制。
特定平台和程序决定它们将支持哪些表情符号扩展标志序列。不要求任何支持，也不期望供应商通常支持的数量超过少数。
请注意，SD 不能是两个字母的代码，如“US”或“us”。
