前段时间,在项目中遇到一个很奇怪的问题,服务器端接收中文参数为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就好了。