app应用中文字夹带表情是个很常见的现象。甚至一些40多岁的大叔级用户，也喜欢在自己的昵称中夹带表情，在产品运营后发现这个现象，彻底颠覆了我的世界观。

在后台处理表情的时间，我遇到过下面3个问题：

1.表情在mysql的存储

表情的utf8编码，有时是有4个字节的，所以在一般的utf编码是没法存储的。

在网上看到一个常用的解决方案，是把mysql升级到5.5,然后把字符编码改为utf8mb4_general_ci。

但实际情况是，有可能在以前的app版本中不需要支持表情，这时系统已经运营了一段时间了，这时才把mysql升级并迁移数据，需要很高的运维成本，同时具备一定的风险，例如，迁移前的不同mysql版本间需要数据同步，保证数据的一致性；迁移过程中可能出现意想不到的事情，造成服务停止。

但在实践中，我发现了还有一个方法，适用于mysql 5.1,就是把含有表情的那个字段的类型变为blob, 没错，就是用二进制存储，这样就能比较少的改动mysql。

2.当文字中夹带表情的处理

很多时候，如果文字中夹带表情，那么这些文字的处理就会出现问题，例如，如果一个用户的昵称带有表情，那么我怎么把这个昵称转换为拼音呢？在推送apns过程中，如果推送的文字中夹带表情，推送到app端后也会显示乱码。

在app后端，存在着大量要处理文字中夹带表情的需求。我遇到了这个问题，先是找到了 https://github.com/iamcal/php-emoji这个转换表情的类库，但发现这个类库不支持ios6后新增的表情，最后没办法了，我写了个抓取程序，把 http://punchdrunker.github.io/iOSEmoji/table_html/ios6/index.html中ios6后新增的表情抓取出来，并写了个新的类库并开源了 https://github.com/newjueqi/converemojitostr，这个类库的作用就是把文字中夹带的表情替换为一个特殊的字符(默认是"#")。

3.openfire中发送表情引起断开连接的问题

openfire中，如果发送某些特殊的字符（例如一些表情符合），会断开xmpp的连接，经查，是由以下的代码问题引起的：

src\java\org\jivesoftware\openfire\net\MXParser.java

[java] view plaincopy

1. protected char more() throws IOException, XmlPullParserException {
2. final char codePoint  = super.more(); // note - this does NOT return a codepoint now, but simply a (single byte) character!
3. if ((codePoint == 0x0) ||  // 0x0 is not allowed, but flash clients insist on sending this as the very first character of a stream. We should stop allowing this codepoint after the first byte has been parsed.
4. (codePoint == 0x9) ||
5. (codePoint == 0xA) ||
6. (codePoint == 0xD) ||
7. ((codePoint >= 0x20) && (codePoint <= 0xD7FF)) ||
8. ((codePoint >= 0xE000) && (codePoint <= 0xFFFD)) ||
9. ((codePoint >= 0x10000) && (codePoint <= 0x10FFFF))) {
10. return codePoint;
11. }
12. throw new XmlPullParserException("Illegal XML character: " + Integer.parseInt(codePoint+"", 16));
13. }

由于在这里把特殊的字符当成了一个异常，所以openfire会断开连接。

解决方法：

[java] view plaincopy

1. @Override
2. protected char more() throws IOException, XmlPullParserException {
3. final char codePoint  = super.more(); // note - this does NOT return a codepoint now, but simply a (single byte) character!
4. if ((codePoint == 0x0) ||  // 0x0 is not allowed, but flash clients insist on sending this as the very first character of a stream. We should stop allowing this codepoint after the first byte has been parsed.
5. (codePoint == 0x9) ||
6. (codePoint == 0xA) ||
7. (codePoint == 0xD) ||
8. //fix some emotion
9. ((codePoint >= 0x20) && (codePoint <= 0xFFFD)) ||
10. ((codePoint >= 0x10000) && (codePoint <= 0x10FFFF))) {
11. return codePoint;
12. }
13. throw new XmlPullParserException("Illegal XML character: " + Integer.parseInt(codePoint+"", 16));
14. }