mysql中文乱码问题解决方法总结

mysql中文乱码是各种初学这类的常见问题,下面我来给各位同学详细介绍关于在mysql中文乱码时的一些解决方法,有需要了解的朋友不防参考.

原因是很多时候,为了安全,不允许mysql管理工具连接线上的正式环境,这样的情况下,就不能依靠mysql管理工具来转换编码来解决中文乱码的问题.

这样的情况下只能通过putty或者secureCRT远程连接mysql server,然后通过mysql命令界面来对mysql数据库导出,再做其他的编码转换操作,我现在面临的环境就是这样。

现在,描述一下我的数据情况,我需要导出中文乱码的数据表account.user,代码如下:

1. mysql> show create database account; 
2. +———-+——————————————————————————————+ 
3. | Database | Create Database | 
4. +———-+——————————————————————————————+ 
5. | account | CREATE DATABASE `account` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci */ | 
6. +———-+——————————————————————————————+ 
7. 1 row in set (0.00 sec) 
8. mysql> show create table user; 
9. +———————+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+ 
10. | Table | Create Table | 
11. +———————+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+ 
12. | user_agreement_info | CREATE TABLE `user` ( 
13. `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
14. `uid` bigint(21) unsigned NOT NULL, 
15. `realname` char(32) NOT NULL, 
16. `id_type` smallint(11) unsigned NOT NULL, 
17. `id_num` char(32) DEFAULT NULL, 
18. `create_time` int(10) unsigned DEFAULT NULL, 
19. PRIMARY KEY (`id`), 
20. KEY `uid` (`uid`) 
21. ) ENGINE=MyISAM AUTO_INCREMENT=129287 DEFAULT CHARSET=utf8 | 
22. +———————+———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————–+ 
23. 1 row in set (0.02 sec) 
24. #查询数据乱码，看下面： 
25. mysql> select * from user limit 10; 
26. +—-+————+—————————+———+——————–+————-+ 
27. | id | uid | realname | id_type | id_num | create_time | 
28. +—-+————+—————————+———+——————–+————-+ 
29. | 23 | 1000001229 | è€é™ˆ | 1 | 410101234567891234 | 1272619237 | 
30. | 2 | 1000001207 | çŽ‹æ–‡é‰´ | 1 | 320211198511261933 | 1272546559 | 
31. | 3 | 1000001208 | è’‹å®¶é”‹ | 1 | 513023198808294915 | 1272547009 | 
32. | 4 | 1000001209 | zhaojing | 1 | 320822198704286120 | 1272550654 | 
33. | 5 | 1000001210 | é˜®å°æ­¦ | 1 | 31020619840214283X | 1272562857 | 
34. | 6 | 1000001211 | é»‘夜精灵 | 1 | 412723798204103835 | 1272588671 | 
35. | 7 | 1000001212 | è°¢å‹‡ | 1 | 330722198408168210 | 1272591799 | 
36. | 8 | 1000001213 | é‚µæ˜ŽèŠ³ | 3 | 0621316 | 1272592840 | 
37. | 9 | 1000001215 | çŽ‹ç»´çºª | 1 | 330382198611030393 | 1272592959 | 
38. | 10 | 1000001216 | è°ˆå® | 1 | 430721198309272802 | 1272595142 | 
39. +—-+————+—————————+———+——————–+————-+ 
40. 10 rows in set (0.00 sec) 
41. #数据库编码设置情况： 
42. mysql> show variables like ‘%char%’; 
43. +————————–+—————————————-+ 
44. | Variable_name | Value | 
45. +————————–+—————————————-+ 
46. | character_set_client | utf8 | 
47. | character_set_connection | utf8 | 
48. | character_set_database | utf8 | 
49. | character_set_filesystem | binary | 
50. | character_set_results | utf8 | 
51. | character_set_server | utf8 | 
52. | character_set_system | utf8 | 
53. | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ | 
54. +————————–+—————————————-+ 
55. 8 rows in set (0.02 sec) 

这是什么问题呢？首先我们来看下数据是什么编码,代码如下:

1. mysql> set names latin1; 
2. Query OK, 0 rows affected (0.02 sec) 
3. mysql> select * from user_agreement_info limit 10; 
4. +—-+————+————–+———+——————–+————-+ 
5. | id | uid | realname | id_type | id_num | create_time | 
6. +—-+————+————–+———+——————–+————-+ 
7. | 23 | 1000001229 | 陈 | 1 | 410101234567891234 | 1272619237 | 
8. | 2 | 1000001207 | 王嘉文 | 1 | 320211198511261933 | 1272546559 | 
9. | 3 | 1000001208 | 网家锋 | 1 | 513023198808294915 | 1272547009 | 
10. | 4 | 1000001209 | zaojing | 1 | 320822198704286120 | 1272550654 | 
11. | 5 | 1000001210 | 小林 | 1 | 31020619840214283X | 1272562857 | 
12. | 6 | 1000001211 | 黑夜精灵 | 1 | 412723798204103835 | 1272588671 | 
13. | 7 | 1000001212 | 凤舞 | 1 | 330722198408168210 | 1272591799 | 
14. | 8 | 1000001213 | 邵明芳 | 3 | 0621316 | 1272592840 | 
15. | 9 | 1000001215 | 王维纪 | 1 | 330382198611030393 | 1272592959 | 
16. | 10 | 1000001216 | 谈宏 | 1 | 430721198309272802 | 1272595142 | 
17. +—-+————+————–+———+——————–+————-+ 
18. 10 rows in set (0.01 sec)  --Vevb.com 

现在可以确定了,这个表里的数据时latin1编码的,我们知道如果要mysql中,中文正常显示,必须要保持编码一致,我们看到在数据库里执行set names latin1之后,中文就能正常显示,那么我们就按照这样的方式导出数据,代码如下:

[root@sh-db1 tmp]# /usr/local/mysql/bin/mysqldump -uroot –opt –default-character-set=latin1  -p654321  account user >/tmp/user.sql

注意这里的导出参数–default-character-set=latin1，也就是相当于我们在数据导出之前在数据库里执行set names latin1;

这样数据就以sql脚本的方式存在于server上,使用vim查看文件/tmp/user.sql时发现还是乱码,这是为什么呢？下面就是原因,代码如下:

1. [root@sh-db1 tmp]# locale 
2. LANG=en_US.UTF-8 
3. LC_CTYPE=”en_US.UTF-8″ 
4. LC_NUMERIC=”en_US.UTF-8″ 
5. LC_TIME=”en_US.UTF-8″ 
6. LC_COLLATE=”en_US.UTF-8″ 
7. LC_MONETARY=”en_US.UTF-8″ 
8. LC_MESSAGES=”en_US.UTF-8″ 
9. LC_PAPER=”en_US.UTF-8″ 
10. LC_NAME=”en_US.UTF-8″ 
11. LC_ADDRESS=”en_US.UTF-8″ 
12. LC_TELEPHONE=”en_US.UTF-8″ 
13. LC_MEASUREMENT=”en_US.UTF-8″ 
14. LC_IDENTIFICATION=”en_US.UTF-8″ 
15. LC_ALL= 

还有跟你的连接工具的编码有关系，去查看一下你的putty或者secureCRT连接使用的是什么编码，这些不同的编码就是造成你使用vim查看中文显示乱码的原因。

没有关系，我们使用sz命令把/tmp/user.sql下载到本地，也就是你的windows主机上。

然后使用emedtor或者uedtor，notepad++，vim都可以，打开，发现中文已经可以正常显示，如果不正常显示，那就往前看看是不是哪里做错了，修改user.sql里面的内容，set names latin1;修改为set names utf8;然后另存为utf8的编码形式。

再使用rz上传到mysql server上,再次使用vim打开,发现中文正常显示,代码如下:

[root@sh-db1 tmp]# /usr/local/mysql/bin/mysql -uroot -S /tmp/mysql3306.sock -p654321 account < user.sql

登录mysql查看,中文显示正常,后来又总结出一个更简单办法.

登陆mysql --->进入相应数据库--->代码如下:

输入命令:show variables like '%char%';得到:

1. +--------------------------+--------------------------+ 
2. | Variable_name　　　　　　| 　　　　 Value　　　　　   | 
3. +--------------------------+--------------------------+ 
4. | character_set_client　　　　　　  utf8 　　　　　　  
5. | character_set_connection　　　  utf8  
6. | character_set_database　　　　  latin1  
7. | character_set_filesystem　　　　 binary  
8. | character_set_results 　　　　　 utf8  
9. | character_set_server　　　　　　utf8  
10. | character_set_system　　　　　  utf8 
11. | character_sets_dir　　　　　　　D:MySQLsharecharsets  
12. +--------------------------+--------------------------+ 

如果出现上述情况则需要更改数据库编码:两种方法,第一种是一次搞定,第二种只对当前连接有效,断开连接,恢复更改前状态.

方法1:alter database 数据库名 charset utf8;

方法2:set character_set_database = utf8;

再用命令,代码如下:

1. show variables like '%char%';  --Vevb.com 
2. +--------------------------+--------------------------+ 
3. | Variable_name　　　　　　| 　　　　 Value　　　　　   | 
4. +--------------------------+--------------------------+ 
5. | character_set_client　　　　　　  utf8 　　　　　　  
6. | character_set_connection　　　  utf8  
7. | character_set_database　　　　  utf8  
8. | character_set_filesystem　　　　 binary  
9. | character_set_results 　　　　　 utf8  
10. | character_set_server　　　　　　utf8  
11. | character_set_system　　　　　  utf8 
12. | character_sets_dir　　　　　　　D:MySQLsharecharsets  
13. +--------------------------+--------------------------+ 

此时编码已经一致,但是,对数据库中的表进行插入中文字符操作,仍然会报:ERROR 1366 (HY000),代码如下:

---> set character_set_client = gbk;设置插入时接收的编码为GBK,这样就可以插入中文了.

此时中文字符已经可以插入,但查询结果却还是乱码,再更改一处即可:

---> set character_set_results = gbk; 设置输出结果的编码为GBK

注:这样的设置只对当前连接有关,连接断开,这些设置恢复数据库默认设置状态,因此,如果需要,每次连接都得设置.

另外:ERROR 1366 (HY000)错误主要出现于控制台(cmd/黑窗口) 执行SQL语句插入中文时弹出,用mysql-front 软件插入时不会报字符问题,java通过JDBC连接数据库执行executeUpdate("insert 语句") 中文也能成功插入数据且不会报错.

PHP解决乱码问题只需在连接后加入mysql_query("set names 'gbk'") 就OK,代码如下:

$conn = mysql_connect("localhost","root",""); mysql_query("set names 'gbk'");