tomcat接收多字节参数为null问题分析

重温战场

前段时间，在项目中遇到一个很奇怪的问题，服务器端接收中文参数为null，接收单字节字符能正常获取。一开始我以为是项目中某个过滤器做了一些多字节字符过滤，对系统接收参数的环节debug跟踪了好多遍，没发现有过滤多字节参数的地方。
我以前碰到过很多编码问题或者中文等多字节乱码问题，但是服务器得不到参数还是头一次情况，以前是不管编码怎样转换，总还有点东西吧，不至于为null，但是这个所谓的经验误导了我。跟踪服务端没有头绪，于是，我分析客户端提交请求的环节。客户端用ajax提交数据，提交前，UED同事对数据用js的escape函数encode了。
js的escape函数会将多字节数据转换为unicode格式，比如“阿里”会转换成” %u963F%u91CC”。转换就转换了吧，为什么服务端会认为它是null呢？服务器用的jboss，于是我就去查tomcat的源代码，发现tomcat在解析客户端提交的参数时，如果某个参数的值里有%，那么它会跳过两个字符往后寻找匹配的%。如果找不到就会抛出异常，并且该参数被忽略掉，通过request.getParameter得到的就是null。Tomcat接收请求后，会解析请求里的参数，具体类是org.apache.tomcat.util.http. Parameters，里面有一个方法public void processParameters( byte bytes[], int start, int len, String enc )。这个方法有这么一部分
           try {
                addParam( urlDecode(tmpName, enc), urlDecode(tmpValue, enc) );
            } catch (IOException e) {
//此处省略异常处理部分
}
urlDecode函数调用了org.apache.tomcat.util.buf. UDecoder的public void convert( ByteChunk mb, boolean query )函数。遇到参数值有%时，有这么一段代码：
                // read next 2 digits
                if( j+2 >= end ) {
                    throw new CharConversionException("EOF");
                }
                byte b1= buff[j+1];
                byte b2=buff[j+2];
                if( !isHexDigit( b1 ) || ! isHexDigit(b2 ))
                    throw new CharConversionException( "isHexDigit");
                j+=2;
                int res=x2c( b1, b2 );
它认为如果一个参数值含有%，那么从这个%开始，后面应该是两个数字,如%aa%bb%%cc%，否则就会抛出异常，忽略此参数。
但是看看js的escape函数encode出来的值，以“阿里”为例，escape值是” %u963F%u91CC”，encodeURI的值是%E9%98%BF%E9%87%8C。显然escape的值是不合法的，服务器会丢弃这个参数，escape会将数据编码成unicode码，encodeURI将数据编码成utf-8编码，unicode码和utf-8编码存在着一个对应关系，并且utf-8编码是unicode的子集，是可变的多字节编码，服务器收到%E9%98%BF%E9%87%8C，会将它转成unicode码，然后从unicode码转成对应的编码，如果服务器没有设置编码则默认用ISO-8859-1。客户端数据编码的函数有escape,encodeURI,encodeUriComponent。这三个函数是有区别的，最后的解决是如此简单，在ajax提交时，将escape换成encodeURI就好了。