深入理解Java和MySQL乱码问题

近期我们使用tomcat和MySQL搭建了一个Java Webserver，并将游戏的server逻辑部署在该server上。

游戏上线后不久，我们发现数据库中出现了大量的乱码。这是个很严重的问题，因此必须立即解决。可是问题出在什么地方呢，依据分析，乱码仅仅可能出如今两个时间点：

1.       将数据从client传送到server的时候。

2.       server将数据存储到数据库的时候。

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

既然是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：当MySQLserver接收到client发送过来的数据之后，会将这些数据转化成character_set_connection所指定的编码。

l   character_set_results：MySQLserver返回查询结果所使用的字符编码。

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

通过MySQLclient运行插入的步骤例如以下，MySQLclient将用户输入的数据编码成character_set_client，发送到server，server接收到之后，将其转化成character_set_connection，然后server再将这些数据存储成character_set_table（上面这些參数不包括这个，即假设建表时没有指定，该值即为character_set_database）。

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

为了证明这一点，我试着通过MySQLclient往表中插入中文，结果插入失败。因此我决定将表的字符编码改动成UTF-8，看看能否往表中插入中文，运行例如以下语句之后：

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

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

当时以为事情到这里就结束了，但是当我们启动tomcat进行測试之后，发现数据库中存入的依旧是乱码。既然MySQLclient都能插入中文，为啥使用JDBC就不能呢？非常有可能JDBC并不使用character_set_client来编码client数据。

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

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

&characterEncoding=UTF-8就可以，假设使用的是tomcat数据源，那么记得把’&’替换成’&’。

最后，当再次启动server时，发现数据库中最终出现了正确的字符。