XMPP 服务器 Openfire 的 Emoji 支持问题（进行部分修改）

当前最新版3.9.3已经可以支持Emoji 

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

在为领航信息开发 eMessage 支持的时候，我们曾使用著名的开源 XMPP 服务器软件 Openfire。但在使用中遇到了几个问题，并通过修改源代码将这些问题解决掉了。接下来的几篇文章，我会介绍一下这些问题并讲述是如何解决掉的。

先介绍一下背景。XMPP 是一个开放的即时通讯协议，非常不错，有很多开源软件实现了 XMPP 协议，Openfire 算是实现得比较全的，而且安装配置比较容易。其他比较流行的开源 XMPP 服务器还有 Tigase 和 ejabberd。我们现在已经切换到了 ejabberd 上，毕竟 WhatsApp 最初也使用的是 ejabberd 嘛，呵呵。读者如果有兴趣，我也可以跟大家讲讲这几个 XMPP 服务器的区别和潜在问题。

问题描述

Emoji 现在基本已经成为一种工业事实标准，最早在日本流行，由日本的 DoKoMo 等运营商支持，后来苹果在 iOS 中支持了这一技术，最终变得全世界流行起来。Emoji 使用了一些 UNICODE 字符集中尚未定义的码位来表示一个个的表情图案。和一般的字体不同，应用程序在遇到这些字符的时候，需要使用位图来显示对应的表情图标，而不是直接使用字体中定义的字型来显示（当然，也可以用字体来显示 Emoji 字符，比如某些 Linux 控制台就可以显示部分 Emoji 字符）。前者可以是彩色的，而后者只能是某个特定的颜色。所以，要显示 Emoji 就要在应用程序中做扩展，在输出这些特定字符的时候做特殊处理，将其用对应的表情位图显示出来。让客户端应用支持 Emoji 并不是很难的工作，Android 的短信应用不支持 Emoji，但支持预先定义的特定字符序列来表示特定的表情，比如将“:)”显示成笑脸。处理这种字符序列的方法和处理 Emoji 表情的方法本质上一样的。

 

在使用 Openfire 作为 XMPP 服务器，将表示 Emoji 的 UNICODE 字符发送给其他用户的时候，就会出现问题。问题的原因在于 Emoji 使用的 UNICODE 字符集码位尚未被 UNICODE 标准化组织标准化，而 Openfire 会将 Emoji 字符看成是不符合标准的字符而直接忽略掉或者干脆断开客户端的连接。因此，要解决这个问题，其实相当容易，通过搜索引擎可以很快找到了解决方案。

解决方案

在 Openfire 3.8.2 版本源代码术中，修改 openfire_src/src/java/org/jivesoftware/openfire/net 目录下的 MXParser.java 文件的最后一个函数：

     /**
      * Makes sure that each individual character is a valid XML character.
      *
      * Note that when MXParser is being modified to handle multibyte chars correctly, this method needs to change (as
      * then, there are more codepoints to check).
      */
 @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) char
er!
             if ((codePoint == 0x0) ||  // 0x0 is not allowed, but flash clients insist on sending this as the very first
racter 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))) {
                      return codePoint;
             throw new XmlPullParserException("Illegal XML character: " + Integer.parseInt(codePoint+"", 16));
 }

先看看这个函数的作用。如注释所言，这个函数用来判定特定字符是否是一个合法的 XML 字符。XML 一般要求按照 UTF8 编码的方式存储和传输字符，在程序处理时，会直接转换成 UNICODE 的 UCS 形式，这样便于程序做处理。

 

在 Linux 控制台上运行 $ man utf8 命令，你可以迅速知悉 UNICODE 码位范围以及和 UTF-8 编码之间的对应关系：

The following byte sequences are used to represent a character.  The sequence to be used depends on the  UCS  code
number of the character:

0x00000000 - 0x0000007F:
    0xxxxxxx

0x00000080 - 0x000007FF:
    110xxxxx 10xxxxxx

0x00000800 - 0x0000FFFF:
    1110xxxx 10xxxxxx 10xxxxxx

0x00010000 - 0x001FFFFF:
    11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0x00200000 - 0x03FFFFFF:
    111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0x04000000 - 0x7FFFFFFF:
    1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

从上面的对应关系就可以知悉，UNICODE 可能的码位（code point 或者 code number）最大可以到 0x7FFFFFFF！而 Openfire 判断是否为合法 XML 字符的范围只到 0xFFFD！显然，不能显示正确处理 Emoji 字符的原因是 Openfire 将用来表示 Emoji 字符的那些码位范围给当成非法 XML 字符了。一种比较简单粗暴的修改办法是：

    /**
     * Makes sure that each individual character is a valid XML character.
     *
     * Note that when MXParser is being modified to handle multibyte chars correctly, this method needs to change (as
     * then, there are more codepoints to check).
     */
@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) char
r!
            if ((codePoint == 0x0) ||  // 0x0 is not allowed, but flash clients insist on sending this as the very first
acter 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 <= 0xFFFD)) ||
                            ((codePoint >= 0x10000) && (codePoint <= 0x10FFFF))) {
                    return codePoint;
            }

            throw new XmlPullParserException("Illegal XML character: " + Integer.parseInt(codePoint+"", 16));
}

但马上有高手指出，这个方法太粗暴了，可能带来一些安全隐患（参见： http://community.igniterealtime.org/thread/48846），所以更加正确的方法是：

 

 

 

 

@Override
    protected char more() throws IOException, XmlPullParserException {


        final char codePoint = super.more(); // note - this does NOT return a codepoint now, but simply a (double byte) character!


        boolean validCodepoint = false;


        boolean isLowSurrogate = Character.isLowSurrogate(codePoint);


        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))) {
            validCodepoint = true;
        }


        else if (highSurrogateSeen) {
            if (isLowSurrogate) {


                validCodepoint = true;
            } else {


                throw new XmlPullParserException(
                        "High surrogate followed by non low surrogate '0x"
                                + String.format("%x", (int) codePoint) + "'");


            }
        }


        else if (isLowSurrogate) {
            throw new XmlPullParserException("Low surrogate '0x "+ String.format("%x", (int) codePoint)+ " without preceeding high surrogate");
        }


        else if (Character.isHighSurrogate(codePoint)) {
            highSurrogateSeen = true;// Return here so that highSurrogateSeen is not reset
            return codePoint;
        }


        // Always reset high surrogate seen
        highSurrogateSeen = false;
        if (validCodepoint)
            return codePoint;


        throw new XmlPullParserException("Illegal XML character '0x"+ String.format("%x", (int) codePoint) + "'");


    }

 

 

 

有了上述修改，你的 Openfire 服务器就可以正确处理 Emoji 了。Openfire 最新的版本是 3.9.1，估计已经修改掉这个问题了吧，但本人未确认。

在 MySQL 中存储 Emoji 字符

没想到，为了在 MySQL 数据库中保存 Emoji 字符，需要使用 MySQL 5.5 以上版本引入的 utf8mb4 的字符集。原来 MySQL 的 utf8 字符集只支持编码为一个、两个字节或者三个字节的情形，也就是 UNICODE  UCS 编码范围为 0 到 0xFFFD 这种情形。要支持超过这个范围的 UTF8 编码字符，就需要使用 MySQL 5.5 中引入的 utf8mb4 字符集。从名字中可以看出，这个字符集专门用来支持单个 UNICODE 的 UTF8 编码长度达到四个字节的情形。当然，超过也许也是可以的。至于为什么不能直接用 utf8 编码来兼容这些字符，我就不知道了，也许是历史原因吧。

 

大家可以用“mysql utf8mb4”为关键词搜索一下就知道如何设置/配置 mysql 来支持这个字符集了。但是，要让 openfire 能够和 mysql 正确打交道，还需要升级一下 openfire 使用的 JAVA mysql 数据库连接器（connnector），要升级到最新的版本。否则，如果使用老的 mysql 数据库连接器，会出现无法理解 utf8mb4 字符集的情形。

 

吐槽一下，我实在是不能理解为什么 MySQL 要引入 utf8mb4 这个字符集，难不成将来还需要引入 utf8mb6、utf8mb8 这样的字符集不成？哪位大侠可以帮我解答这个疑惑？

后记

俺是不太喜欢 JAVA 语言的，至今未能使用 JAVA 语言完整编写过一个程序，这实在是本人二十多年码农生涯的一大遗憾，但打打补丁这事儿还是可以做做的。下一篇文章给大家介绍一个针对 Openfire 服务器在集群环境下处理 SOCKS5 代理的问题，就修改了几行代码，但解决了一个大问题。

 

http://blog.csdn.net/ldwtill/article/details/23210835