首先，mysql 数据库中的东西都是二进制存放的，支持任何数据，当然包括中文。你到命令行下
insert into testtable values ( @#中文@# );
select * from testtable;
全都显示正常。
但是，虽然存取中文没问题，但排序、匹配的时候有问题。所以如果你的数据库里有中文的话，记得在配置文件中，如 c:winntmy.ini 中的 [mysqld] 里添加一行：
default-character-set=gbk
然后重启 mysql server 。 注意 gbk 要小写，不然 mysqld 启动不了。
其次，数据库没问题，下面看看 java 程序。在程序里很无聊地加一句调试语句：
out.println("中文");
也显示正常，说明整个 java 环境没问题。
所以，当然是联系 java 和 mysql 的部分，mysql jdbc driver 出问题了。
分析一下，java 内部使用 unicode ，而 mysql 缺省使用 iso-8xxx（忘了），所以 jdbc driver 把查询字符串传给 mysql server 时，会做 unicode->iso-8xxx 的转换，从 mysql server 接受结果时，会做 iso-8xxx->unicode 的转换。（在屏幕上显示结果时会 unicode->GBK，不过不关这里的事。）
这就有问题了，我在命令行下插入数据库的中文字符串是 GBK （这是简体中文 windows 的默认），所以 jdbc driver 接受查询结果时，应该做 GBK->unicode 的转换才对。
验证一下，对从数据库中读出的中文字串 s ，
new String( s.getByte("iso-8xxx"), "gbk" )
将 s 先做一个 unicode->iso-8xxx 转换成它存放在数据库中的原始模样。我们知道它是 gbk ，所以手工来 gbk->unicode ，这样 java 程序就显式正常了。
类似，写入数据库的时候，我们期待 jdbc driver 会把 unicode->gbk ，结果却是 unicode->iso-8xxx ，当然是乱码了。
有很多文章，就到此为止，并告诉我们：要解决中文问题，自己手工转码吧。
这实在是不负责任。如果每一个字符串都要手工转码，说明程序设计出了问题。
想一想，写 mysql jdbc driver 的家伙会连转码都不知道？
所以我看看 connector-j-3.0.7 里面的 readme, 找到一个解决方案：
connection = DriverManager.getConnection( "jdbc:mysql://localhost/test?user=root&password=&useUnicode=true&characterEncoding=GBK" );
这是告诉 jdbc driver 强制按指定参数转码
其实还是有问题。如果 mysql server 一定得用 iso-8xxx ，那就只有用上一个办法了。但我记得我的 mysql 是 gbk ，不是都改过 my.ini 了吗？ jdbc driver 怎么都不自动探测 mysql server 的字符集呢？
这个时候就看到开放源码的好处了 :-) connector-j-3.0.7 源码中确实有代码读取 mysql server 的信息，包括字符集。从注释中知道，
作者为 unicode 转换到单字节字符集写了自己的转换函数，并号称比 jvm 的快百分之多少多少。所以代码中有一段，判段数据库如果使用的是单字节就调用自己的转换函数。但这段代码后面就忘了把多字节字符集交给 jvm 去转换了，所以变成了缺省的 iso-8xxx 转换。
我的修改方式： commysqljdbcConnecter.java 这个文件的 1969 行，
this.doUnicode = true; // force the issue
将之上移四行到 1964 行，放在下面这一行的前面：
try {
用这份代码重新编出来的 jdbc driver ，你的 java 访问数据库的程序不用做任何修改就可以正确读写中文了，不过要记得 mysql server 要 default-character-set=gbk
我使用它测试了几个小程序，中文都显示正常，而且都没死机、异常。呵呵，自我感觉很好。
文章来源于领测软件测试网 https://www.ltesting.net/
