首先要先说明的是：mysql中有3个属性：
character_set_client : 告诉服务器，我这边使用的是什么编码集
character_set_results ： 查询结果使用什么编码集
character_set_connection ：转换器中使用的是什么编码集
可通过 show variables like ‘character_set_%' 来查询以上3个变量设置的编码集是什么;
如果，你查阅得到的编码不是utf8，那么你可通过sql语句 set names utf8 来让他临时的变成utf8 ，这样就顺利的解决了乱码问题；
那么如何让他永久的解决乱码问题？
可通过查阅你的my.int (此为mysql的配置文件) ； 找到character-set-server= (没改动mysql的话，这边默认的是latin1 ,也就是说乱码的根源就是这里了，将此改为utf8，ok一切问题解决)
那么好，我们来分析一下，为什么会出现乱码问题；
一般的编码的转化需要分3个步骤来进行：
客户端--》转换器---》服务器
有以下几个原因：
1.客户端声明与事实不符：
例如：你客户端明明使用的是gbk，但是你声明的确是utf8；然后你转换器的字符集是utf8，服务器也是utf8 ；查询的结果集是gbk， 那么他会把这个当成utf8字符集，然后再去查阅gbk的编码表，也就是说，他会以3个字节的长度先去utf8编码表查阅是什么字符，然后在将这个字符转换成gbk，好那么问题和明显了，客户端的字符集明明使用的是gbk，也就是说1个字符是2个字节，现在你硬生生的用3个字节去翻译，那么就出现乱码了。
2.result 与客户端事实不符。
例如:你客户端使用gbk，查询结果使用utf8，输出以utf8为准，那你肯定乱码
比乱码更严重的是数据的丢失：数据的丢失发生的情况如下
connection 和服务器 的字符集 比 client 小。
假设 client 为 utf8 , connection 为gbk , 服务器为 gbk ,查询结果为utf8；
那么过程是这样的：
utf8一个字符是3个字节，gbk是2个字节，发现connection字符集是gbk，那么从client流经过 connection, 需进行字符集的转换，即将utf8转换成gbk（其实这里，就出现了数据的丢失了，每一个字符，丢失了一个1个字节） ,发现服务器需要的也是gbk，那么直接给服务器了，
好，接下去，服务器需要将数据回送给客户端，这时经过connection，发现客户端要的是utf8，那么好，你现在的是一个字符是2个字节，utf8 需要的是3个字节，你去哪里凑1个字节