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
- protected char more() throws IOException, XmlPullParserException {
- final char codePoint = super.more(); // note - this does NOT return a codepoint now, but simply a (single byte) character!
- 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.
- (codePoint == 0x9) ||
- (codePoint == 0xA) ||
- (codePoint == 0xD) ||
- ((codePoint >= 0x20) && (codePoint <= 0xD7FF)) ||
- ((codePoint >= 0xE000) && (codePoint <= 0xFFFD)) ||
- ((codePoint >= 0x10000) && (codePoint <= 0x10FFFF))) {
- return codePoint;
- }
- throw new XmlPullParserException("Illegal XML character: " + Integer.parseInt(codePoint+"", 16));
- }
由于在这里把特殊的字符当成了一个异常,所以openfire会断开连接。
解决方法:
- @Override
- protected char more() throws IOException, XmlPullParserException {
- final char codePoint = super.more(); // note - this does NOT return a codepoint now, but simply a (single byte) character!
- 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.
- (codePoint == 0x9) ||
- (codePoint == 0xA) ||
- (codePoint == 0xD) ||
- //fix some emotion
- ((codePoint >= 0x20) && (codePoint <= 0xFFFD)) ||
- ((codePoint >= 0x10000) && (codePoint <= 0x10FFFF))) {
- return codePoint;
- }
- throw new XmlPullParserException("Illegal XML character: " + Integer.parseInt(codePoint+"", 16));
- }