mysql 乱码产生探讨

1、mysql 乱码产生探讨乱码的产生，是因为单字节向多字节扩展引起的。b0a2 假如作为单字节存储（虽然表示的是1个汉字，但是由于是latin1单字节，所以认为b0a2是不相关的两个字符），此时假如把character_set_results变成utf8多字节，那么数据库mysql 会试图把每个单字节扩展成近 的（不知道详细的算法）双字节。所以乱码 反之，多字节向单字节转换时，不会有变动，仅仅是本来2各字节表示的一个字符b0a2变成了表示两个字符而已。- 这个说法阅历证是错误的。 数据库存储的内容（磁盘上，内存里）不会受character_set_的影响，只是提交，查询的过程中，受到字符集转换的

2、影响。 试验二 1。 create table y ( int, name char(4) default charset gb2312； 2。在不转变默认character_set_ 是 latin1的状况下，假如插入一个汉字，则显示乱码 3。改成 set names gb2312，显示没问题(cmd窗口中，cmd窗口代码页936) 4。我原以为如上述试验1种的结论2，“多字节向单字节转换时，不会有变动”。所以我开头以为，set names gb2312 后，把 character_set_results 改成latin1，显示不会出问题。结果， 一个汉字，则显示一个问号；两个汉字，则显示两

3、个问号的乱码（估量一个问号代表一个字符）。也就是说，改成character_set_results = latin1后，多字节的数据存储，在向单字节表示转换时，mysql把提出的信息“缩水了”，把两个字节，换算成了一个字节。 。如何，不让mysql缩水呢，我想到了character_set_results = binary；结果，果真显示正常。 ps 开发的用法mysql的应用程序，是对应作为自立的用法自己的character_set_client的字符集的cmd 窗口登陆mysql，也是作为一个自立的，拥有自己character_set_client变量的应用同理，打开不同的cmd窗口，都拥

4、有独自的character_set_client变量 试验三 07/16/2010 1。建一个默认字符集utf8的表（用navi ，在utf8的界面下 代码页65001），并且插入utf8编码的汉字高校 2。切换到mysql console（代码页936） 3。set names gbk; 然后显示刚才所建立的表，能正确现实吗？ - 能！固然，只把character_set_results 成 gbk，也能正常显示 试验四 1。mysql console（代码页936）建立一个表x3 ( name char(32) )，默认字符集 default charset gbk; 2。默认环境变量 |

5、 character_set_client | latin1 | character_set_connection | latin1 | character_set_database | latin1 | character_set_filesystem | binary | character_set_results | latin1 | character_set_server | latin1 | character_set_system |utf8 /不知道对以下过程、分析是否有影响 character_set_client character_set_connection chara

6、cter_set_results 是latin1的状况下，插入数据：insert x3 values('大'); 显示：error 1406 (22001): data too long for umn 'name' at row 1 3。set character_set_client=gbk;然后 insert x3 values('大');插入没有问题，但明显，数据经过 （character_set_connection=latin1）的转换，已经是有损了 4。不管 character_set_results 设不设成 gbk，都不能正常显

7、示结果 5。set names gbk；则插入现实都没问题。并且此时，一个uf8字符集的表的显示也没问题（试验三）。而且举行衔接查询，亦没问题。 6。固然，set names utf8，假如在一个utf8的软件界面上，显示输出也没问题(navicat 验证了) 7。假如设成 set names binary。在936代码页的显示界面上，可以看到，x3依旧可以正常现实；但像试验三那样建的表就不能正常显示了。 - 分析第2点：data too long for column 'name' at row 1 我的char 够长，插入数据够短，所以不是数据太长了。也就是说这个提醒是错误

8、的。我知道，假如表x3 默认字符集 是latin1的话，插入是没问题的（向来以来都是这么玩的）；这是由于，虽然输入端mysql console 代码页是936，但由于三个主环境变量character_set_c%都是latin1，所以，mysql 认为insert x3 values('大') 输入的是2个字符(固然,假如从utf8界面输入，可能就认为是输入3个字符)。存储的自然也是2个字符。显示的时候也是显示的2个字符，只不过936代码页把这两个字符自然组合，显示成汉字了（早期dos环境常见现象）。当默认字符集变为gbk的时候，发生了什么？不知道。 试验五 一个很狗屎的问题浮

9、现了：936 mysql console 环境变量如 试验一.1。 mysql set names latin1; query ok, 0 rows affect (0.00 sec) mysql create table x4 ( - name char(32) primary key); query ok, 0 rows affected (0.09 sec) mysql drop table x4; query ok, 0 rows affected (0.06 sec) mysql create table x4 ( - name char(32) primary key) default charset utf8; query ok, 0 rows affected (0.10 sec) mysql insert x4 values('乃'); query ok, 1 row affected (0.04 sec) mysql create table x5 ( - name char(32) primary key) default charset gbk; query ok, 0 rows affected (0.09 sec) mysql insert x5 val