公众号回复表情
这个问题的本质是，APP内用的UTF8编码方式，所以我们发送过去显示的内容也要是UTF8编码才能被APP显示出来。
每个emoji表情都有一个与之对应的Unicode编码（例如：\ue415，其中\u表示十六进制，e415是笑脸emoji表情在Unicode字符集中的编码），我们可以从百度轻易查到每个表情对应的Unicode编码，然后从Unicode编码转成UTF8编码，再返回给前端（微信），这时候就能显示emoji表情了。
php 没有提供Unicode直接转UTF8的方法，可以使用 json_decode 来间接转换。
mysql 的字段可以选择utf8编码方式，但是mysql中该编码方式只支持最大3个字节，而emoji表情在Unicode里面排名比较后，需要4个字节才能保存一个emoji表情，所以在建表的时候如果需要考虑保存表情，应该设置字段字符集为utf8mb4，utf8mb4表示用utf8编码方式同时mysql最大分配4个字节的存储空间。
关于字符集 和 字符编码
参考：https://blog.csdn.net/guxiaonuan/article/details/78678043
先讲概念：字符集是字符和二进制码的对应关系，字符编码是规定字符怎么存储到内存中。
字符集
比较常见的两种字符集是 ASCII 和 Unicode。
ASCII字符集
ASCII比较简单，内含128个字符，128=27，即使用 7 bit 的存储空间就能表示ASCII中的一个字符。但是考虑计算机一般使用 1 byte 作为基本单位，所以一般使用 1 byte 来表示ASCII中的一个字符。虽然浪费了 1 bit，但是读写效率更高了，利用空间来换效率。
例如：
'A'在ASCII中用065（十进制）或者0x41（十六进制）来表示，转换成二进制就是：1000001，二进制占用了 7bit。
Unicode字符集
Unicode包含上百万的字符，要表示上百万的字符使用的字节数肯定随之增加，所以Unicode的复杂度远远增大。虽然Unicode字符集中包含的字符很多，但是字符的对应关系还是从最小的0开始排列。排列在前面的字符使用 1byte 就可以表示，位置靠后的可能需要 3byte 才能表示。这就关系到怎么分配字节数来存储的问题。
假如一个字符串包含 1个位置靠前字符、1个位置靠后字符，即可能第一个字符用 1byte ，第二个字符用 3byte，这个字符串拼接在一起后一共使用 4byte。这看上去没有问题，但是系统在拿这个字符串的时候，怎么知道这 4byte 是怎么分配的(1+3=4,2+2=4,3+1=4)。这就涉及到下面说道的字符编码的问题，字符编码方式决定怎么去存储这些内容。
字符编码
UTF-8、UTF-16、UTF-32指的就是字符编码，即表示用什么方式去表示（存储）字符集中的二进制。
UTF-8
UTF-8 的编码规则很简单：如果只有一个字节，那么最高的比特位为 0；如果有多个字节，那么第一个字节从最高位开始，连续有几个比特位的值为 1，就使用几个字节编码，剩下的字节均以 10 开头。
具体的表现形式为：
- 0xxxxxxx：单字节编码形式，这和 ASCII 编码完全一样，因此 **UTF-8 是兼容 ASCII 的**；
- 110xxxxx 10xxxxxx：双字节编码形式；
- 1110xxxx 10xxxxxx 10xxxxxx：三字节编码形式；
- 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx：四字节编码形式。
xxx 就用来存储 Unicode 中的字符编号。
例如字母'N'，Unicode编码为：01001110(0x4E)，用UTF8编码的话同样表示为：01001110(0x4E)
例如中文'⻬'，Unicode编码为：00101110 11101100(0x2EEC)，用UTF8编码表示的话为：11100010 10111011 10101100(0xE2BBAC)
UTF-32
UTF-32 是固定长度的编码，始终占用 4 个字节，足以容纳所有的 Unicode 字符，所以直接存储 Unicode 编号即可，不需要任何编码转换。浪费了空间，提高了效率。
