JAVA高级面试进阶训练营视频教程

admin

　　mysql中文乱码问题一直每次迁移一次数据库就要从头解决一遍，因为数据库建好以后就不会怎么动了，一直没当回事儿，反正就麻烦一次吗。最近服务器遇到了点问题，重装了几次，结果每次都要重新配置这个问题，索性就总结一下。

 

　　首先中文乱码的根本问题就是编码问题：我们把中文输入到数据库中再从数据库中取出来显式在浏览器上分为几个过程，这些过程中要求每一个处理过程的编码都是要支持中文的，而且如果前后两个过程如果编码方式不一样的话，必须要有转码的手段。比如说你用gbk的编码方式在本地写好了一段中文，或者说是.sql脚本，上传服务器后执行，如果你的mysql默认以utf8的编码读取你的sql语句的话，那么中文就是乱码了。（没有测试过，说不准gbk和utf8是兼容的或者是mysql默认会通过unicode转码。不过大致就是这个意思）。可以想象如果所有的过程之间都要检查编码问题是非常繁琐的，所以最好的解决方案，就是选择一种编码，然后在所有的过程中都使用这种编码，这样就不用担心编码转换问题了。

　　然后说一下mysql中关于编码的规则，mysql中对每个数据库，每个数据库中的每个表，每个表中的每个字段都有关于编码的设置变量，（记得好像是可以在mysql中用sql语句：show variables like “%char%”）查到。这些变量的优先级是从小到大排列的。也就是说如果你设置一个testdb数据库的默认编码是latin的，那么在你新建一个表（不声明编码方式）以后，这个表的所有字段的编码都是latin的，但是你可以新建一个其他编码方式（比如说utf8）的表，做法就是在建表的时候显式的声明用的是什么编码。这样就可以再一个数据库中同时存在latin编码的和utf8编码方式的表了。同样的规则也可以应用在表和表中的字段上。

　　最开始就是这里耽误了很长时间，因为自己明明已经把数据库的编码方式改为utf8的了，但还是显示乱码，一直以为是哪里编码不统一，检查了好几遍。问题是因为这个表是在修改数据库默认编码之前建立的，所以这个表的默认编码还是latin的，同样这个表中的字段也是默认为latin的。所以除了需要修改数据库的默认编码以外还需要修改表的默认编码，然后还需要修改字段的默认编码。当然如果你的数据库中只有一个表是需要中文的，那么你只要在建立表的时候修改它的默认编码就好了。但是如果你先建立的这个表再去修改表的默认编码是没有用的，因为表中的字段的编码是根据表建立的时候所确定的。所以说对于已经建立好的表，想要修改其中字段的编码不仅需要修改表的默认编码，还需要修改具体字段的编码。

　　这里我用phpmyadmin作为例子来说明一下对于已经建立好的表怎么让其支持中文：

在phpmyadmin中，“默认排序方式”就是默认编码的意思，我也不知道为什么这么说。。。

首先我们看到mysql的默认编码是什么，关于编码有好几个变量，每个变量负责的功能不一样，具体的介绍点击那个问号就可以有mysql的官方解释了，或者自己去查一下mysql的手册就好了

在这种默认编码的情况下我们新建一个数据库test：

我们这里不选择编码方式也就是“排序规则”

然后新建一个表：

同样也不选择编码方式

然后插入一条有中文的记录：

就会出现乱码了：

原因是默认情况下name字段的编码是这种：

我也不清楚为什么从latin1变成了cp1250_bin可能是mysql中其他的设置里有规定吧。。。。。。

我们改掉这个编码：

再插入一条中文的记录：

可以看到解决了。

现在我们换个思路：改掉test数据库的默认编码：

重新建立一个表testtable2：

可以看到这个testtable2的编码已经变成utf8的了。

同样插入一条中文记录，可以看到问题也解决了：

 

总结一下吧：虽然现在很多数据库管理工具都可以支持边开发，边修改数据库。但是在新建数据库的时候还是应该大致思考一下数据库的性质，表之间的依赖关系等等。否则以调试程序的方式来调试数据库效率太低。