首页 > 代码库 > 深入理解Java和MySQL乱码问题

深入理解Java和MySQL乱码问题

最近我们使用tomcat和MySQL搭建了一个Java Web服务器,并将游戏的服务器逻辑部署在该服务器上。

 

游戏上线后不久,我们发现数据库中出现了大量的乱码。这是个非常严重的问题,因此必须马上解决。但是问题出在什么地方呢,根据分析,乱码只可能出现在两个时间点:

1.       将数据从客户端传送到服务器的时候。

2.       服务器将数据存储到数据库的时候。

 

经过调试之后,我们发现服务器输出的数据是正常的,因此乱码问题只能发生在存储入库的时候。

 

既然是MySQL数据库编码的问题,那事情就相对好办了,首先,输入命令:

mysql>show variables like ‘%char%‘;

+--------------------------+----------------+

|Variable_name              | Value            |

+--------------------------+----------------+

|character_set_client      | utf8              |

| character_set_connection| utf8             |

|character_set_database   | latin1            |

|character_set_filesystem | binary           |

|character_set_results     | utf8             |

|character_set_server      | latin1          |

|character_set_system      | utf8              |

+--------------------------+----------------+

上述命令用于显示当前MySQL用到的数据库编码。当看到这么多项数据编码之后,脑袋都有点大,没办法,只能硬着头皮一个一个地把这些参数搞明白。

l   character_set_server:创建数据库时,如果没有指定字符编码,那么系统将使用character_set_server的值作为默认值。

l   character_set_database:创建表时,如果没有指定字符编码,那么系统将使用character_set_database的值作为默认值。

l   character_set_client:定义了MySQL客户端所发送数据的编码。

l   character_set_connection:当MySQL服务器接收到客户端发送过来的数据之后,会将这些数据转化成character_set_connection所指定的编码。

l   character_set_results:MySQL服务器返回查询结果所使用的字符编码。

 

知道这些参数的含义之后,就没有那么茫然无助了,因此脑海中回顾下数据存储入库的过程。

 

通过MySQL客户端执行插入的过程如下,MySQL客户端将用户输入的数据编码成character_set_client,发送到服务器,服务器接收到之后,将其转化成character_set_connection,然后服务器再将这些数据存储成character_set_table(上面这些参数不包含这个,即如果建表时没有指定,该值即为character_set_database)。

 

回忆一下,发现当时建表的时候并没有主动在建表语句后面指定字符编码,那么根据上面的描述,数据库的表就会使用character_set_database所指定的字符编码,即latin1。由于UTF-8编码的中文无法存储成latin1,因此在往latin1编码的表中存储UTF-8编码的中文时,数据库会将无法识别的字符变成?,并且这个过程是不可逆的。

 

为了证明这一点,我试着通过MySQL客户端往表中插入中文,结果插入失败。因此我决定将表的字符编码修改成UTF-8,看看是否能往表中插入中文,执行如下语句之后:

mysql> ALTER TABLE `tableName` DEFAULTCHARACTER SET utf8 COLLATE utf8_general_ci

表的字符编码被修改成了UTF-8,这时候发现也能往表中插入中文了。

 

当时以为事情到这里就结束了,可是当我们启动tomcat进行测试之后,发现数据库中存入的依然是乱码。既然MySQL客户端都能插入中文,为啥使用JDBC就不能呢?很有可能JDBC并不使用character_set_client来编码客户端数据。

 

翻阅了无数文档之后,发现如果不在JDBC URL中通过characterEncoding属性指定连接编码,JDBC Driver会使用character_set_server作为连接的编码,在本案例中,即使用latin1。既然原因找到了,那问题就比较好解决了。

 

将JDBC URL修改成jdbc:mysql://localhost/some_db?useUnicode=yes

&characterEncoding=UTF-8即可,如果使用的是tomcat数据源,那么记得把’&’替换成’&’。

 

最后,当再次启动服务器时,发现数据库中终于出现了正确的字符。