MySQL字符的编码转换问题详解

以下的文章主要讲述的是MySQL字符的编码转换问题(latin1->gbk)的详细解析，我们大家都知道容易过想搞好一个站的二次开发，可以用的原数据库的编码有两种，即gbk与lation1。而我用的是 gbk，就涉及到编码转换问题。

宁武ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：13518219792（备注：SSL证书合作）期待与您的合作！

这里在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都没有看到有这一行，估计是老版本才需要这么干吧？）

***找到一个工具，可以实现latin1<->gbk,gbk<->utf8,gbk<->big5,的编码的相互转换，程序可以进行多次转换即可以实现latin1->gbk->utf8等的转换，但是不能跳跃转换（例：latin1不能直接转换成utf8）。

还不错，转过来没有乱码，终于解决问题。

另外提一下备份数据库工具：帝国数据备份王(Empirebak)。一款开源免费、专门为MySQL大数据的备份与导入而设计的稳定高效软件,系统采用分卷备份与导入,理论上可备份任何大小的数据库。

【编辑推荐】

1. 实现Oracle 客户端配置的具体步骤
2. Oracle数据库的大恢复（误操作而引起）
3. Oracle sqlplus命令的详细解析
4. Oracle多表创建的视图insert的解决方法
5. Oracle分页语句中的实际应用代码有哪些？

名称栏目：MySQL字符的编码转换问题详解
网页路径：http://www.gawzjz.com/qtweb2/news39/9739.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联