前言：今天有个项目需要合并（A合并到B），我所做的就是数据库的合并操作，其中出现的主要问题就是乱码的问题。乱码这个问题是很常见的问题，今天整理了下自己所理解的一点见解。
案例：
查看表的时候都是乱码，根本不能进行合并。当时就认为肯定是自己查看时候的字符集不对，试了“set names = gbk、utf8、latin1”，均显示乱码。再怀疑是不是表结构的问题（根本不可能啊，项目都跑了好几年了），不过表的编码确实的用charset latin1 来建立的。而用lantin1 建立表，在数据库层写入数据（中文）的话，肯定会报warning，不会存成功的而且存的都是？符号，但上面的结果却有 符号，所以是显示的问题，其实是正常的。经过排查确定是自己终端编码显示的问题，改成GBK，并且做默认的字符集连接下才能正常显示（latin1:set names latin1)，因为当时存数据就是做latin1的下面写入的。上面说明表中的文字是GBK编码。注意：latin1可以存储任何东西，包括汉字，二进制等。latin1是单字节的，存储都会用内部的编码去表示。只要输入流和输出流一致（怎么存就怎么取）就不会出现乱码情况。如： 表的编码是UTF8 ，那么在进入数据库后，需要在utf8的字符集下才能正常（set names utf8) 表的编码是GBK ，那么在进入数据库后，需要在gbk的字符集下才能正常（set names gbk) 首先看到表的字符集编码是什么，，才能相应的set names。要是输入结果像上面显示的这样，就和终端的编码有关系了，需要自己设置下。如何让表字符编码变成gbk呢？单单的alter 转换是不行的。之后就尝试用python来读取插入表。看看latin1编码如何存汉字：(Python)
#!/usr/bin/python#encoding: utf-8#——————————————————————————-# Name:latin_to_gbk_bak.py# Purpose:gbk 编码存到 latin1编码# Author:zhoujy# Created:2012-10-31# update:2012-10-31#——————————————————————————-import MySQLdba=u’zhoujy’b=u’中国’/*生成unicode */c=u’周金义’conn = MySQLdb.connect(host=’localhost’,user=’root’,passwd=’123456′,db=’test’)cursor = conn.cursor() /*编码成gbk存到latin1 的表中*/query = "insert into users_latin(username,user_company,user_realname) values(‘%s’,’%s’,’%s’)" %(a.encode(‘gbk’),b.encode(‘gbk’),c.encode(‘gbk’)) cursor.execute(query)conn.commit()print query
root@localhost : test 10:55:10>CREATE TABLE `users_latin` (-> `username` varchar(25) NOT NULL DEFAULT ”,-> `user_realname` varchar(50) NOT NULL DEFAULT ”,-> `user_company` varchar(100) NOT NULL DEFAULT ”-> ) ENGINE=MyISAM DEFAULT CHARSET=latin1 ;Query OK, 0 rows affected (0.07 sec)
zhoujy@zhoujy:~$ python latin_to_gbk_bak.py 1insert into users_latin(username,user_company,user_realname) values(‘zhoujy’,’й’,”)zhoujy@zhoujy:~$ python latin_to_gbk_bak.py 2insert into users_latin(username,user_company,user_realname) values(‘zhoujy’,’中国’,’周金义’)root@localhost : test 10:55:14>select * from users_latin; 1+———-+—————+————–+| username | user_realname | user_company |+———-+—————+————–+| zhoujy || й|+———-+—————+————–+1 row in set (0.00 sec)root@localhost : test 10:56:06>select * from users_latin; 2+———-+—————+————–+| username | user_realname | user_company |+———-+—————+————–+| zhoujy | 周金义| 中国|+———-+—————+————–+1 row in set (0.00 sec)
上面的信息说明：latin1确实可以存中文。(在set names latin1下面读的）<脚本>向latin1编码的表中插入数据，执行脚本，第一次显示乱码，第二次显示正常，他们的区别是 输出流是gbk，而 系统默认/终端默认 的是utf8，所以出现不同的结果。（第二次把 系统默认/终端默认 编码改成了gbk）<数据表>表的编码是latin1，并且当时的字符集是latin1（set names latin1，要和表编码一致）。第一次显示乱码，第二次显示正常，他们的区别是 输出流是gbk，而 系统默认/终端默认 的是utf8，所以出现不同的结果。（第二次把 系统默认/终端默认 编码改成了gbk）其实也可以把latin1存储汉字的表备份出来，文件中要是最新字符集都是有效的，可以用vi可以直接编辑查看。要是出现无效的编码则也可以用： iconv 来转码之后再还原。
cat users.sql | iconv -c -f gbk > users_qq.sql
当然，还原之后也是latin1 字符集下查看的。解析： 1，Mysql数据库乱码：这个可以做网上搜到很多信息，就不细说了。只要知道怎么存就怎么取。（有时候set names utf8并且终端也是utf8 可以直接对gbk编码的表进行读取） 2，Python 编码问题，涉及到Unicode 的 encode、decode 相互转换 。（可能做执行中出：“UnicodeEncodeError: ‘ascii’ codec can’t encode characters in position 0-1: ordinal not in range(128)” 的错误信息。）
天下爱情，大抵如斯。
