以下的文章主要讲述的是mysql字符的编码转换问题(latin1-gbk)的详细解析，我们大家都知道容易过想搞好一个站的二次开发，可以用的原数据库的编码有两种，即gbk与lation1。而我用的是 gbk，就涉及到编码转换问题。 这里在lijun027s blog查到一个详细的编码比
以下的文章主要讲述的是mysql字符的编码转换问题(latin1->gbk)的详细解析，我们大家都知道容易过想搞好一个站的二次开发，可以用的原数据库的编码有两种，即gbk与lation1。而我用的是 gbk，就涉及到编码转换问题。
这里在lijun027’s blog查到一个详细的编码比较，几种情况如下：
一、实验：
1、情况一
数据库字段mysql字符集：utf-8
连接字符集：没有显式设置，默认为latin1
页面字符集：gbk
存入过程：
1)页面用gbk表示的sql向服务器提交存入请求；
2)默认情况下（不用set names ‘’）服务器用latin1打开连接；
3)服务器误认为当前的sql语句是用latin1表示的；
4)服务器将gbk字符当作latin1字符，错误的运用“latin1转utf-8函数”将mysql字符转换后存入utf-8字段中；
5)（ 错误的latin1(其实是gbk) => 错误的utf-8）
6)如果用phpmyadmin打开该表（用utf8连接）将会看到该字段为乱码；
读取过程：
1)默认情况下（不用set names ‘’）服务器用latin1打开连接；
2)服务器将utf-8字段中的值转换为latin1返回给客户端；
3)（错误的utf-8 => 错误的latin1(其实是gbk)）该过程为存入过程5的逆过程。（刚好错错得对了）
4)将服务器误认为是latin1的gbk编码按页面字符集正常显示；
用示意图来表示就是：
存入过程：
----------------------
页面 连接 存储
----------------------
gbk => latin1 => utf-8
---------------
------------- |
| +------- 该过程得到的utf-8是一串不知所云的乱码，但mysql固执的认为这串码为utf-8
|
+------ mysql将gbk误认为是latin1
读取过程：
----------------------
页面 连接 存储
----------------------
gbk <= latin1 <= utf-8
---------------
------------- |
| +------- 正是这串乱码经过逆过程转换回正确的gbk编码，只是mysql认为是latin1而已
|
+------ mysql将误认为是latin1的gbk编码传回了页面，刚好得到正确的编码。
2、情况二
数据库字段字符集：utf-8
连接mysql字符集：gbk
页面字符集：gbk
文字描述略。
示意图：
存入过程：
----------------------
页面 连接 存储
----------------------
gbk => gbk => utf-8
------------
------------- |
| +------- 该过程得到的utf-8是由gbk转换而来的，是正确的utf-8编码
|
+------ 页面字符集等于连接字符集，mysql认为页面传递给它的是gbk编码，它的想法正好符合事实。
读取过程：
----------------------
页面 连接 存储
----------------------
gbk <= gbk <= utf-8
---------------
------------- |
| +------- 用“utf-8转gbk函数”将正确的utf-8编码转换回gbk
|
页面字符集等于连接mysql字符集，显示没有任何问题。
3、情况三
数据库字段字符集：gbk
连接字符集：没有显式设置，默认为latin1
页面字符集：gbk
存入过程：
----------------------
页面 连接 存储
----------------------
gbk => latin1 => gbk
------------
------------- |
| +------- 字符被“latin1转gbk函数”转换的成了乱码，但mysql认为它是gbk，所以工具无法正常显示。
|
+------ mysql认为页面传递给它的是latin1编码，它将在后续过程中画蛇添足地将正确的gbk转换为乱码。
读取过程：
----------------------
页面 连接 存储
----------------------
gbk <= latin1 <= gbk
---------------
------------- |
| +------- “gbk转latin1函数”将乱码转换为gbk，但mysql却认为它们是latin1
|
+------ 错误的latin1编码其实是正确的gbk编码，页面显示正常，但工具显示不正常。
二、mysql字符集之间的转换
笔者试着将gbk字符误当作latin1转换为错误的utf-8能成功，逆过程中将乱码转换回latin1得到的刚好是正确的gbk。
$str = 中文测试;
$str_tran = iconv('latin1', 'utf-8', $str); echo $str_tran;
显示乱码，既不是gbk也不是utf-8和latin1
echo <br>-----------<br>;
$str_re_tran = iconv('utf-8', 'latin1', $str_tran); echo $str_re_tran;
显示 “中文测试”
而将gbk字符误当作utf-8转换为错误的gbk编码则出现错误
$str = 中文测试;
#$str_tran = iconv('utf-8', 'gbk', $str);
错误！！！
可见一种编码是否能被当作另一种编码被转换为第三种编码，取决于编码的固有属性，上面我们举的第一个例子只是碰巧gbk编码能被误当作latin1被转换为utf-8。如果是如下情况，则数据库肯定不能正常存取数据。
先说一下教训，建立数据库的时候，同一个应用，所有的编码一定要一致，不然就是自寻烦恼。
搞了半天用iconv转换后还是不行。（在windows下开启iconv只需要把php.ini里面的;extension=php_mbstring.dll前面的“;”去掉即可。网上查了下。很多都说要开启;extension=php_iconv.dll这个东东，但下了几个版本的php都没有看到有这一行，估计是老版本才需要这么干吧？）
最后找到一个工具，可以实现latin1gbk,gbkutf8,gbkbig5,的编码的相互转换，程序可以进行多次转换即可以实现latin1->gbk->utf8等的转换，但是不能跳跃转换（例：latin1不能直接转换成utf8）。
还不错，转过来没有乱码，终于解决问题。
另外提一下备份数据库工具：帝国数据备份王(empirebak)。一款开源免费、专门为mysql大数据的备份与导入而设计的稳定高效软件,系统采用分卷备份与导入,理论上可备份任何大小的数据库。