这个今天早上提供的一个生产问题。大体是说，改资料的时候，有个客户的名字有生僻字，叫”刘”,保存之后就乱码了，变成”刘?”
乱码需要确认数据传输过程中编码方式。
数据是通过jQuery的Ajax过来的，并且没有提前处理数据(只有组装了一个js对象)，所以是采用encodeURIComponent进行处理的，对于中文可以很粗糙的理解成UTF-8编码过。这一点通过抓包工具是可以确认的。到了服务端之后会通过getParameter获取参数，由于带charsetEncoding的过滤器，并且是采用UTF-8的，那么这里拿到的字符串应该也是不会乱码的。到了这里，代码并没有特别之处。按我的理解，只要字符集能够支持这个生僻字，就不会出现乱码。 难道保存到数据库的时候乱码了? 目前数据库是用GBK的，我去查了一下GBK的字符表，的确是有这么个字的。
我在本机上测了一下这个字的各种功能编码转换，都是正常的。 难道又是IBM的坑? 后来我又在服务器上测试了各种情况的输出，发现有另外一个字”䶮”,除了字体大小有点不一样之外，几乎一模一样的。
下面整理了一个简单的测试程序，来说明这个奇怪的问题。
首先要说明的是，这里有2个字,一小一大,还有它们对应的unicode和utf-8编码。 测试结果是采用secureCRT的GB18030编码显示。
有两个字: 小 大unicode /uE863 /u4dae浏览器(utf-8) %EE%A1%A3 %E4%B6%AE下面的测试代码，为了编译时不关心字符集，所以换成utf-8字节来生成字符串。
public class Test { public static void main(String[] args) throws java.io.UnsupportedEncodingException { new Test().test(); } public void test() throws java.io.UnsupportedEncodingException { byte[] bbs = {-18,-95,-93,-28,-74,-82}; String x = new String(bbs, "utf-8"); String utf8 = new String(x.getBytes("utf-8"), "iso-8859-1"); //byte[] bs = utf8.getBytes("iso-8859-1"); //test case 1 //byte[] bs = x.getBytes("GBK"); //test case 2 for(byte b : bs){ System.out.PRintln(b); } System.out.println(x); }}对于Test Case 1, 测试一下字符串是不是本来就乱了。测试结果显示，2个字都正常，要输出成GB18030才是可以的(secureCRT设置GB18030编码)。
>/tools/jdk1.6.0_20/bin/java -Dfile.encoding=GBK Test-18-95-93-28-74-82䶮?>/opt/IBM/WebSphere/AppServer/java/bin/java -Dfile.encoding=GBK Test-18-95-93-28-74-82?䶮>/opt/IBM/WebSphere/AppServer/java/bin/java -Dfile.encoding=GB18030 Test-18-95-93-28-74-82䶮>/tools/jdk1.6.0_20/bin/java -Dfile.encoding=GB18030 Test-18-95-93-28-74-82䶮对于Test Case 2，主要测试一下转换成GBK字节的情况,因为这是保存到数据库的必要转换。 测试结果显示，ibm的jdk下，第一个字会编程乱码(对应的是63)。
>/tools/jdk1.6.0_20/bin/java -Ddefault.client.encoding=GBK -Dfile.encoding=GBK Test-2-9763?>/opt/IBM/WebSphere/AppServer/java/bin/java -Ddefault.client.encoding=GBK -Dfile.encoding=GBK Test63-2-97?
规避方法，选择输入第二个字(大字，截图中的第二个字，应该看不出有什么区别)。话说回来，感觉这是ibm的jdk的bug，字符对应错了。
新闻热点
疑难解答
