Home >Database >Mysql Tutorial >MySQL字符的编码转换问题详解
以下的文章主要讲述的是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 = "中文测试";
<ol class="dp-xml"><li class="alt"><span><span>$</span><span class="attribute">str_tran</span><span> = </span><span class="attribute-value">iconv</span><span>('latin1', 'utf-8', $str); </span></span></li><li><span>echo $str_tran; </span></li></ol>
显示乱码,既不是GBK也不是utf-8和latin1
<ol class="dp-xml"><li class="alt"><span><span>echo "</span><span class="tag"><</span><span class="tag-name">br</span><span class="tag">><span>-----------</span><span class="tag"><</span><span class="tag-name">br</span><span class="tag">></span><span>"; </span></p> <li> <span>$</span><span class="attribute">str_re_tran</span><span> = </span><span class="attribute-value">iconv</span><span>('utf-8', 'latin1', $str_tran); </span> </li> <li class="alt"><span>echo $str_re_tran; </span></li> <p></p> <p>显示 “中文测试”</p> <p></p> <p>而将GBK字符误当作utf-8转换为错误的GBK编码则出现错误</p> <p></p> <p>$str = "中文测试";</p> <p></p> <pre class="brush:php;toolbar:false"><ol class="dp-xml"><li class="alt"><span><span>#$</span><span class="attribute">str_tran</span><span> = </span><span class="attribute-value">iconv</span><span>('utf-8', 'gbk', $str); </span></span></li></ol>
错误!!!
可见一种编码是否能被当作另一种编码被转换为第三种编码,取决于编码的固有属性,上面我们举的第一个例子只是碰巧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大数据的备份与导入而设计的稳定高效软件,系统采用分卷备份与导入,理论上可备份任何大小的数据库。