PHP连接MySQL出现乱码的一些个人看法（转載）

 

PHP连接MySQL出现乱码的一些个人看法

作者：不祥


PHP连接MySQL的过程中如果出现乱码很多人会说，用"Set names '??'"就能解决问题，但很多时候还是会出现各种怪现象，比如说页面能正常存取，但是phpmyadmin不能正常存取等现象。小弟经过验证，产生了一些个人看法，欢迎大家讨论和指正。

MySQL数据库操作过程中出现了三种字符集：
1、页面字符集（也就是 content="TEXT/HTML; CHARSET=GBK"）
2、连接字符集（也就是 "Set names 'GBK'"）
3、字段字符集（无论是库还是表的字符集，将最终反映到字段上）
一、实验：
1、情况一
数据库字段字符集：utf-8
连接字符集：没有显式设置，默认为latin1
页面字符集：gbk

存入过程：
1)页面用GBK表示的SQL向服务器提交存入请求；
2)默认情况下（不用Set Names '??'）服务器用latin1打开连接；
3)服务器误认为当前的SQL语句是用latin1表示的；
4)服务器将GBK字符当作latin1字符，错误的运用“latin1转UTF-8函数”将字符转换后存入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编码按页面字符集正常显示；

用示意图来表示就是：

CODE

   存入过程：
   ----------------------
   页面    连接     存储
   ----------------------
   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
连接字符集：gbk
页面字符集：gbk

文字描述略。


示意图:

CODE

   存入过程：
   ----------------------
   页面   连接   存储
   ----------------------
   GBK => GBK => utf-8
          ------------
   ------------- |
         |       +------- 该过程得到的utf-8是由GBK转换而来的，是正确的utf-8编码
         |
         +------ 页面字符集等于连接字符集，MySQL认为页面传递给它的是GBK编码，它的想法正好符合事实。


   读取过程：
   ----------------------
   页面   连接   存储
   ----------------------
   GBK <= GBK <= utf-8
              ---------------
   ------------- |
         |       +------- 用“utf-8转GBK函数”将正确的utf-8编码转换回GBK
         |
         +------ 页面字符集等于连接字符集，显示没有任何问题。

3、情况三
数据库字段字符集：gbk
连接字符集：没有显式设置，默认为latin1
页面字符集：gbk

CODE

   存入过程：
   ----------------------
   页面   连接   存储
   ----------------------
   GBK => latin1 => GBK
          ------------
   ------------- |
         |       +------- 字符被“latin1转GBK函数”转换的成了乱码，但MySQL认为它是GBK，所以工具无法正常显示。
         |
         +------ MySQL认为页面传递给它的是latin1编码，它将在后续过程中画蛇添足地将正确的GBK转换为乱码。


   读取过程：
   ----------------------
   页面   连接   存储
   ----------------------
   GBK <= latin1 <= GBK
          ---------------
   ------------- |
         |       +------- “GBK转latin1函数”将乱码转换为GBK，但MySQL却认为它们是latin1
         |
         +------ 错误的latin1编码其实是正确的GBK编码，页面显示正常，但工具显示不正常。

二、字符集之间的转换
笔者试着将GBK字符误当作latin1转换为错误的utf-8能成功，逆过程中将乱码转换回latin1得到的刚好是正确的GBK

CODE

   $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编码则出现错误

CODE

   $str = "中文测试";
   #$str_tran = iconv('utf-8', 'gbk', $str);    // 错误！！！

可见一种编码是否能被当作另一种编码被转换为第三种编码，取决于编码的固有属性，上面我们举的第一个例子只是碰巧GBK编码能被误当作latin1被转换为utf-8。如果是如下情况，则数据库肯定不能正常存取数据。
GBK => utf-8 => GBK（未实验）
三、结论
页面能正常存取但phpmyadmin不能正常存取，从严格意义上来说应该是一种错误，页面是否能正常存取取决于连接字符集是否能正常的被转换为存储字符集。
要保证页面能正常存取，并且工具也能正常使用，一般保持页面字符集等于或兼容连接字符集就可以了。