深入理解Java和MySQL乱码问题

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

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数据源，那么记得把’&’替换成’&’。

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