最近因为业务需求，看了一下Unicode字符集里的东西，有一些小的知识点在这里记录一下。
在正式阅读之前，不妨先思考几个问题：
- 一个 emoji 一定是一个字符吗？
- 一个 emoji 的不同肤色版本是怎么编码的？
- 过滤用户输入的文本时，能否过滤掉所有的格式字符（format character）？
- 格式字符是否都不可见？
- 如果用户名里含有带样式的字符，比如𝔸，如何不使用简单的映射的情况下将它们转换成A？
读完之后，应该就都有答案了。
建议先阅读我之前写的博客：
（受限于你的设备的字体，本文内容中的某些字符可能在你的设备上无法正常展示。实际发现 Mac Chrome、 Mac Safari、iPhone Safari 看到的都略有不同。由于 Medium 对表格的支持不好，本文中的表格均为 Mac Chrome 中浏览语雀中表格的截图）
变体形式 / Variant form
一个字符的不同字形被称为变体形式，Unicode 中通过变体序列（variation squences）来编码一个字符的变体形式。变体序列由基本字符（base character）和一个变体选择符（variation selector）组成。
emoji变体
emoji样式的变体
我们最常见到的变体形式就是 emoji。
部分emoji拥有两种表现形式：文本样式（text presentation）和 emoji 样式（emoji presentation）。
指定表现形式的方式是在基础 emoji 字符的后面跟一个变体选择符，如果后面跟的是 U+FE0E （VARIATION SELECTOR-15, 后面简称VS-15），则指定为文本样式；如果后面跟的是 U+FE0F（VARIATION SELECTOR-16, 后面简称VS-16），则指定为emoji样式。
基础 emoji 字符渲染出来的样式可能是文本样式，也可能是 emoji 样式，取决于你的设备。如果其没有对应的变体形式，则依旧展示为基础字符的样式。下表列出了几个 emoji 作为示例。
注意不同的设备看到的结果可能不同。
一般比较新的 emoji 都没有文本样式，但你的设备有可能会单独支持它的文本样式。
emoji肤色的变体
还有一种常见的变体体现在不同肤色的 emoji 上。
比如 U+1F385（🎅）圣诞老人除了基础的黄色版本，还有其他五种不同肤色的版本：🎅🏻🎅🏼🎅🏽🎅🏾🎅🏿。
人类肤色，可以根据菲茨帕特里克度量（Fitzpatrick scale）分为从浅色到深色的六类。Unicode 中定义了与之相关的五个变体选择符，正式名称叫 EMOJI MODIFIER FITZPATRICK TYPE ，如下表所示：
所以不同肤色的 emoji ，其实就是基础 emoji 字符后面跟一个 EMOJI MODIFIER FITZPATRICK TYPE 字符。
由于不同设备的字体支持不同，可能你看到的表格里，会展示成一个 base emoji 加一个 肤色色块 的形式，这是正常现象，代表你的字体不支持该 emoji 的不同肤色的变体。
全角字符变体
全角（fullwidth）字符中的东亚标点符号有两种形式的变体：角对齐（corner-justified）与居中（centered）。当基础字符后面跟一个 U+FE00（VARIATION SELECTOR-1，简称VS-1）时，代表角对齐；当基础字符后面跟一个 U+FE01（VARIATION SELECTOR-2，简称VS-2）时，代表角居中。
这里说的是全角符号中符号在字符方块中的位置，之所以叫角对齐，是因为当文字横向排版时，符号居左；当文字纵向排版时，符号居右。
由于我的电脑没办法很好的渲染这种变体，这里就不举例子了。
蒙古语变体
蒙古语一个字符有多种变体形式，每个变体在词首、词中、词尾以及独立时又有特殊的外观。
Unicode 中定义了四个自由变体选择符来选择不同的变体。
U+180B（MONGOLIAN FREE VARIATION SELECOTR ONE，简称FVS1）
U+180C（MONGOLIAN FREE VARIATION SELECOTR TWO，简称FVS2）
U+180D（MONGOLIAN FREE VARIATION SELECOTR THREE，简称FVS3）
U+180F（MONGOLIAN FREE VARIATION SELECOTR FOUR，简称FVS4）
FVS 格式符对蒙古语来说是必须的，如果要过滤用户的蒙古语输入，不能过滤掉 FVS。
Emoji序列 / Emoji Sequences
前面介绍的 emoji 变体其实也是 emoji 序列的一种，这里再介绍两种。
键帽 / keycaps
0到9、#、* 这些中任意一个字符，后面跟一个 U+20E3（Combining Enclosing Keycap）就可以组成一个 emoji，比如 U+0039（9）后面跟 U+20E3 可以得到 9️⃣ 。
旗帜 / flags
emoji 中有许多国家和地区的旗帜，比如新加坡国旗 🇸🇬，这个 emoji 其实是 Unicode 中 Enclosed Alphanumeric Supplement 区中的区域指示符号（Regional indicator symbols）组合成的。这些符号和26个英文字母是一一对应的，比如 U+1F1E6（🇦）对应的是 U+0041（A）。
根据 ISO 3166–1 alpha-2 可知新加坡的国家码为 SG，将区域指示符号中的 U+1F1F8（🇸，对应S）和 U+1F1EC（🇬，对应G）连在一起，就会变成 🇸🇬。
零宽连字 / Zero-width joiner
U+200D（Zero-width joiner，ZWJ）是一个不可打印的格式字符（format character），当 ZWJ 被放置在两个原本不会连接在一起的字符中间时，这两个字符会被以连接的形式渲染出来。
ZWJ 具体的表现取决于被连接的字符。某些语言下，可能是将字符渲染成连词（conjunct consonant）或连字（ligature），当 ZWJ 被放置在某些 emoji 符号之间时，会将这些 emoji 合成一个 emoji 展示（需要序列合法且字体支持）。
Emoji ZWJ序列 / Emoji ZWJ Sequences
Emoji ZWJ 序列也是 Emoji 序列的一种，通过 ZWJ 将两个或多个 emoji 连接起来，最终展示成一个合并了它们各自特点的 emoji。
比如这个序列：
👩（U+1F469）
ZWJ（U+200D）
❤（U+2764）
VS-16（U+FE0F）注意这个是变体选择符，和前面的❤组合在一起，为❤️，不需要ZWJ连接
ZWJ（U+200D）
💋（U+1F48B）
ZWJ（U+200D）
👨（U+1F468）
最终展示出来是 👩❤️💋👨 （不同设备看到的可能略微有点不同，比如男女左右位置互换）（最近发现这个emoji在Chrome上渲染有点奇怪）
再举个例子：
👩（U+1F469）
🏿（U+1F3FF）注意这个是肤色的变体选择符，与前面的👩组合在一起，为👩🏿，不需要ZWJ连接
ZWJ（U+200D）
🦳（U+1F9B3）
最终展示出来是 👩🏿🦳
需要注意的是，这种序列并不是可以随意组合的，序列是固定的。
等价性问题
我在Unicode等价性与正规化中介绍过 Unicode 等价性，上文提到的很多也是一串 Unicode 码点组合成一个字形，即变体序列，那变体序列是否存在兼容等价呢？比如 emoji 变体和 emoji 是兼容等价的吗？并不是。
emoji 变体其实只是字形上的改变，并没有一个新的码点与其对应，所以也就不存在等价性。
等价性主要是处理搜索和文本处理的问题。变体序列的搜索，最简单的就是忽略变体选择符。
零宽不连字 / Zero-width non-joiner
U+200C（Zero-width non-joiner，ZWNJ）也是不可打印的格式符，和 ZWJ 相反，它的作用就是插到字符中间防止字符连在一块，避免连字的出现。
对于波斯语、马来语、德语、尼泊尔语等语言，ZWNJ 是必要的，如果漏掉 ZWNJ，可能导致含义不同、或违背语法。
比如尼泊尔语 श्रीमान्को 中有一个 ZWNJ （श्रीमान् [ZWNJ] को），如果去掉它，则文本会变成 श्रीमान्को，注意看两个文本长得不一样，如果让 Google 翻译，意思也完全不同。
蒙古语元音分隔符 / Mongolian vowel separator
前面说到蒙古语的时候提到，蒙古语一个字符有多种变体形式，每个变体在词首、词中、词尾以及独立时又有特殊的外观，为了避免歧义，Unicode 中还有一个蒙古语元音分隔符 U+180E（MONGOLIAN VOWEL SEPARATOR，简称MVS）用于分隔元音。
MVS 是对蒙古语的正确显示非常重要的格式符，如果需要对用户的蒙古语内容做过滤，不能过滤掉这个格式符。
可见的格式符
前面看到的格式符本身都是不可见的，只是影响其他字符的字形，其实格式符也有可见的，比如叙利亚语缩写标记 U+070F（Syriac Abbreviation Mark，SAM）。在使用时，SAM 会在文本上方显示出一条横线。
私人使用区 / Private Use Areas
Unicode 中私人使用区域（Private Use Areas, PUA）一共有三处：
Private Use Area（U+E000..U+F8FF）
Supplementary Private Use Area-A（U+F0000..U+FFFFF）
Supplementary Private Use Area-B（U+100000..U+10FFFF）
由于 Supplementary Private Use Area-A 和 Supplementary Private Use Area-B 的存在，根据 Unicode 的代理区的规则， High Private Use Surrogates（U+DB80..U+DBFF）区域也属于 PUA。（参考基础字符编码知识）
Unicode 并不会在这些区域分配字符，但第三方可以自行在这片区域分配字符。尽管名字叫私人使用区，但第三方可以公开自己分配的方案。
由于是第三方私自分配的，所以如果你使用这片区域里的码点编码的字符，这些字符一般只在你当前使用的平台上可见，如果你需要其他人也能看到和你一样的文本，其他人需要和你使用相同的字体。
比如 Apple 将 U+F8FF 分配给了 Apple 的 logo（），只有使用 Apple 设备访问这个页面的时候，才能看到这个字符，非 Apple 设备一般无法渲染这个字符，或者渲染出来是其他私有字符。
双向文本 / Bidirectional text
（本节内容主要为翻译）
一般语言的排版方向都是固定的，比如中文、英文都是从左向右排版（LTR），但阿拉伯语、希伯来语则是从右向左排版（RTL），如果文本里所有的字符都是一个排版方向的，那没什么问题，如果存在排版方向不同的文本混排，则称之为双向文本。
Unicode 标准中有一个非常繁琐的 Unicode 双向算法（Unicode Bidirectional Algorithm，UBA）来规范这种双向文本的排版。
但 UBA 也有犯错误的时候，偶尔也需要开发者给 UBA 提供一些指引，让其正确排版。
Unicode 标准要求字符必须以逻辑顺序存储，逻辑顺序即解析文本的顺序，以区别视觉顺序。UBA 即描述了如何将逻辑顺序转换为视觉顺序。为此 Unicode 将字符分成了几种类型。
强字符 / Strong characters
带有明确排版方向的文本，要么是LTR，要么是RTL。比如 大部分的字母字符，音节字符，汉表意文字，非欧洲或非阿拉伯数字，以及专属于这些文字的标点符号。
弱字符 / Weak characters
弱字符的排版方向不明。包括欧洲数字、阿拉伯数字、算术符号和货币符号。
中性字符 / Neutral characters
中性字符的方向必须根据上下文确定。 包括段落分隔符、制表符和大多数其他空白字符。 许多脚本中常见的标点符号，例如冒号、逗号、句号和不换行空格（non-breaking space）。
定向格式符 / Directional formatting characters
特殊的 Unicode 序列，可指导 UBA 修改其默认行为。 这些字符被细分为“marks”、“embeddings”、“isolates”和“overrides”。 它们的效果一直持续到出现段落分隔符或“pop”字符。
Marks
如果一个弱字符和另一个弱字符连在一起，UBA 会查看第一个相邻的强字符。有时这会导致无意的显示错误，使用“伪强”字符可以纠正或者避免这些错误，这些 Unicode 控制符被称为 marks。U+200E (LEFT-TO-RIGHT MARK, LRM) 或 U+200F (RIGHT-TO-LEFT MARK, RLM) 可以被插入到某些位置，使其封闭的弱字符继承其排版方向。
例如，在阿拉伯语(RTL)文章中，需要正确显示英文品牌名称（LTR）旁边的商标符号 U+2122 (™)，如果商标符号后面没有跟一个 LTR 文本（比如我想要展示成这样 “ قرأ Wikipedia™ طوال اليوم. “），由于 ™ 前面是 LTR 强字符，后面是 RTL 强字符，但它在阿拉伯语文章中，所以将变为 RTL 排版，因此一个 LRM 需要被插在商标符号后面，保证它被两个 LTR 强字符包裹，采用 LTR 排版。
如果没有插入的话，最终显示出来是这样的 “قرأ ™Wikipedia طوال اليوم.”（这里故意写错，以模拟阿拉伯语环境下查看的样子，没插入 LRM 的写法在英文/中文的环境下展示的是正确的，只在阿拉伯语环境下展示错误）
+-----+--------------------+--------+
| LRM | LEFT-TO-RIGHT MARK | U+200E |
+-----+--------------------+--------+
| RLM | RIGHT-TO-LEFT MARK | U+200F |
+-----+--------------------+--------+Embeddings
embedding定向格式符是Unicode以前使用的显式格式符，从Unicode 6.3开始，由于有了 isolates，不再鼓励使用 embeddings 。一个 embedding 表示一段文本的排版方向是不同的。emebding 格式符内部的文本并不独立于周围的文本存在。此外，emebdding 中的字符会影响到外部字符的顺序，反之亦然，整体表现类似一个强字符。Unicode 6.3 意识到 embedding 定向格式符对周围文本的影响太大，没必要且难以使用。
+-----+-------------------------+--------+
| LRE | LEFT-TO-RIGHT EMBEDDING | U+202A |
+-----+-------------------------+--------+
| RLE | RIGHT-TO-LEFT EMBEDDING | U+202B |
+-----+-------------------------+--------+Isolates
isolate 方向格式符表示一段文本将被视为与其周围文本在排版方向上隔离。从 Unicode 6.3 开始，如果平台支持，则更鼓励使用它们。与早先的 emebdding 方向格式符不同，isolate 格式符对周围文本的顺序没有影响，isolates 可以嵌套，可以出现在 embeddings 和 overrides 里面。
+-----+-----------------------+--------+
| LRI | LEFT-TO-RIGHT ISOLATE | U+2066 |
+-----+-----------------------+--------+
| RLI | RIGHT-TO-LEFT ISOLATE | U+2067 |
| FSI | FIRST-STRONG ISOLATE | U+2068 |
+-----+-----------------------+--------+Overrides
override 方向格式符是为特殊情况准备的，比如产品型号（比如，强制混合了英语、数字、希伯来字符的产品型号从右往左书写），建议尽可能避免使用它。和其他方向格式符一样，overrides 可以嵌套，可以出现在 embeddings 和 isolates 中。
+-----+------------------------+--------+
| LRO | LEFT-TO-RIGHT OVERRIDE | U+202D |
+-----+------------------------+--------+
| RLO | RIGHT-TO-LEFT OVERRIDE | U+202E |
+-----+------------------------+--------+Pops
用于停止embeding、override 或 isolate 的作用范围。
Runs
在 UBA 中，一串连续的strong字符被称为一个run，一个处于两个strong字符间的weak字符，会继承他们的方向，如果他们方向不同，就会继承主上下文的书写方向。（LTR文档中时LTR，RTL文档中是RTL）
过滤用户输入
上面的定向格式符可以影响到外部文本，所以我们需要特别小心的处理用户输入的文本，比如用户名。
用户一般可以自定义自己的用户名，如果用户名会参与排版，特别是插入到一段文本中，则用户可以通过插入 RLO 之类的控制符，以使得带有他名字的文本内容排版异常。
如果要过滤定向控制符，我个人认为，除了marks，其他的都应该过滤掉，避免其干预外部排版。
当然如果面向的市场语言大家都熟悉，比如中文、英文市场，则使用白名单的方式过滤字符是最安全的。如果面向的市场语言很多，则只能用黑名单模式，发现一例，禁掉一例。毕竟我们不是 Unicode 专家，不知道哪些格式符对哪些语言是必须的。
如何将带样式文本的样式去掉
这里的样式特指 Mathematical Alphanumeric Symbols 区中的字符，比如 U+1D538（𝔸）。以及 Halfwidth and Fullwidth Forms 区中的部分全角字符，比如 U+FF21（Ａ）。如果我们需要将用户输入的 U+1D538（𝔸） 或 U+FF21（Ａ）转换成 U+0041（A），以此类推，如果我不想代码里手动写一堆映射，如何转换？
首先我们要明确范围，只转换 Mathematical Alphanumeric Symbols 以及我们了解的全角字符。
参考 Unicode等价性与正规化，这些字符基本上都是和对应的基础字符是兼容等价的，所以对这些文本做一次 NFKD ，仅获取基础字符，用基础字符替换原字符即可。
注意不能对全部文本做这种操作，因为像 U+00C3（Ã）如果被这样操作之后，会变成U+0041（A），这和我们说的将带样式的文本的样式去掉，是不符的。