Emoji小结

Emoji问题由来

这里推荐周俊杰知乎上的的回答：Android 微信对 emoji 的支持是不是很差？为何这样设计？

Emoji从最早开始到现在，比较通用的是两种编码方案，分别是Softbank和Unicode，android版微信早期也是使用Softbank编码，然后客户端根据表情对应的Softbank编码使用SpannableString在TextView, EditText中显示成对应的表情，此时Emoji表情的集合还不是很多，微信只打包进去了大概400多个左右，在早期可以满足大部分Emoji表情的显示需求但是，随着Unicode 6.0以及Unicode 7.0的发布，越来越Emoji表情被加入到这个标准当中，iOS系统自行扩展OpenType标准，通过Apple Color Emoji.ttf这个字体来讲Emoji表情直接显示出来（OSX下也有这个字体，在/System/Library/Fonts/Apple Color Emoji.ttf），当时国外也有对这个问题进行过讨论：Color bitmapfonts… thanks to Apple?! ，但是，由于新加进来的表情都没有对应的Softbank编码，无法转码成Softbank，并且客户端在打包的时候只放进了400多个Emoji表情，所以在显示的时候，只能转换成”..”来显示

Emoji的过滤方式

网上文章也有很多：Android 准确过滤(禁止) Emoji表情

链接1：Emoji列表过滤，但是直接从 Emoji Unicode Tables 网站获取的列表 4. Enclosed characters ( 24C2 - 1F251 ) 区间会和汉字冲突，实际范围是 24C2 和(1F170 - 1F251)，标题错了，作者没有修改直接把汉字内容(例如：我，们，有 ……)也过滤了，并且没有过滤 5. Uncategorized 忽略了许多表情。列表过滤相对准确，但是需要先加载列，虽然使用了静态方法但是首次使用要较长加载时间，过滤时匹配也相对耗时。

链接2：过滤区间，但是只过滤了双字节的Emoji表情，忽略了单字节的表情，并且区间也不合理（判断得很复杂，结果等同于直接过滤了 utf8
Surrogates，这样如果有其他的 Surrogates 区的编码字符也会被过滤掉）。相对列表过滤速度快，但存在多过滤和少过滤的较多。

综合两种情况考虑，既要保证速度又要保证过滤的准确性。Android EditView 以 UTF-16 为编码16位为一个单位。由于两字节以上的Unicode 编码基本上没用到，直接过滤掉 Surrogates 区(0xD800-0xDFFF)；再过滤掉单字节的Emoji表情列表。
当然为了确保绝对只过滤Emoji表情，这里使用1的方法，修改了 4. Enclosed characters ( 24C2 - 1F251 )，添加了 5. Uncategorized ，毕竟现在Android的处理器性能都很高，效率可以不用考虑了。当然也可以使用区间过滤，添加个 Scrope ，再修改下filter()方法。

-Emoji在不同版本的android手机上适配问题

Android开发中，低版本Android系统和高版本Android系统分别怎么处理emoji?

个人建议：关于Emoji兼容性，最好还是利用网上现有的Emoji相关库，毕竟人多力量大，使用人数多肯定是有原因的。