mysql 在doc窗口下中文乱码问题

mysql 在doc窗口下中文乱码问题

新建一个表

create table student(
    id int,
    name varchar(20),
    chinese float,
    english float,
    math float
);

向表中插入数据（包含中文）

insert into student (id,name,chinese,english,math) values (1,'李狗蛋',88,93.5,78);

结果如下：

报了一个Data too long for column 'name' at row 1的错误，，，为什么呢？我的那么字段是20个字符的啊，，，李狗蛋三个字肯定够啊，，，为什么还提示太长了呢！！！！其实呢，，这种情况下就算你只有一个汉字，也会报这个错。。。。原因何在？----->中文乱码问题！！！

跟servlet中乱码产生的原因一样，还是在与提交与接受二者之间的编码方式不一样。。。。

我们知道，在中文版win7下 dos命令行的默认编码方式都是gbk的，而我们装的mysql服务器的默认编码方式确实utf8，，这样，，两个编码方式不一样。。。通过dos窗口向mysql服务器提交中文数据，一个以gbk编码提交，一个以utf8解码接收，可不就产生了乱码了嘛。

不信我们看看mysql的默认编码----在dos窗口输入

show variables like 'character%';

 查看mysql服务器的编码各种编码状态，如下：

但其实这些编码格式只是mysql认为的你的系统的编码模式，但实际情况并非如此。表现在：客户端编码-->mysql认为utf8，但其实你的dos命令行是在我天朝的win7下，那么你就是gbk的编码格式，而不是utf8；其他的都是默认的utf8。到这里就可以看到，客户端为gbk，连接方式为utf8，服务器存储方式为utf8，结果返回方式是utf8，那么，，乱码的出现原因就呼之欲出了--->两方编码不一样，以gbk敲代码，结果以u8编码，然后以utf8发送，以utf8接收。所以怎么解决呢？

　　两种办法解决乱码问题：临时方法和彻底方法。

临时方法：在dos行下输入“set names gbk;”然后再查看一下编码方式，如下：

　　明确告诉客户端，我的dos行是以gbk敲进去的，你得用gbk给我编码；告诉连接桥，我数据是gbk的，你得用gbk给我传输；告诉服务端，我的dos行是gbk的，你得用gbk把我存的数据返回给我。现在我们再插入有之前有中文的那行数据，

可以看到，乱码问题已经不存在了。。。。但是呢，开头都说了，这中方法是临时型的，，为何？来，打开另一个dos窗口，查看下所有的编码方式：

这个时候，你再插入带有中文的数据，保证还是刚才的错误。。。为啥呢？因为"set names gbk;"只针对当前客户端（就是那个dos窗口）起作用。。打开另一个窗口就不行了，所以这种方法治标不治本。如果每次都这样，那不得累死了！！（不要跟我说你用可视化的mysql操作软件，，我们现在的语境是你根本不知道可视化，，，），那么怎么一劳永逸的解决这个问题呢？

彻底解决：修改mysql配置文件--->my.ini

找到你的mysql安装目录下的my.ini文件，记事本打开，找到-----default-character-set=utf8 这句话，修改utf8为gbk

然后重启mysql，，好了，乱码被干掉了。Oh YEAH!!

 

多说一下，为什么改成gbk之后就搞定了乱码。。这中间涉及到了三个数据转换过程：编码，解码，转码。

所谓编码，就是将字符编成二进制数据的过程；

所谓解码，就是将二进制数据解析为字符的过程；

所谓转码，就是将一个字符从a字符集表示的二进制数据转换成b字符集表示的二进制数据的过程。

在客户端通过连接桥将gbk的数据发送给服务器的时候，两方的编码集其实是不一样的，数据库接收到的是gbk，服务器要以utf8存储，在这个过程中，如果不做些什么，乱码是解决不掉的。。其实在这个过程中，服务器自己做了一个转码的操作：将接收到的gbk数据转换成utf8存储到数据库中，然后你查询的时候它自动将utf8的数据转换成gbk返回给你看。所以，乱码没了。