设为首页 收藏本站
查看: 409|回复: 0

[经验分享] PHP连接MySQL出现乱码的一些个人看法(转載)

[复制链接]

尚未签到

发表于 2016-10-20 08:25:36 | 显示全部楼层 |阅读模式
  
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不能正常存取,从严格意义上来说应该是一种错误,页面是否能正常存取取决于连接字符集是否能正常的被转换为存储字符集。
要保证页面能正常存取,并且工具也能正常使用,一般保持页面字符集等于或兼容连接字符集就可以了。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-288629-1-1.html 上篇帖子: Win2003(包括XP) IIS+PHP+Mysql+Zend+phpmyadmin环境组建教程 下篇帖子: MySQL 分页查询: To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS?
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表