症状：在数据库中输入查询语句select * from table where name='中文',有一条结果集。但是用java来查询同样一条语句结果集却为空。查来查去也就只能归结到字符集的问题了。

首先，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

我使用它测试了几个小程序，中文都显示正常，而且都没死机、异常。

分享到：

2010-09-28 16:04

浏览 2747

分类:数据库

评论