学步园

乱码问题简单说就是数据库写入读取，网页文件，网页显示时几个环节的编码不一致造成的。

乱码问题
写入时：页面提取写入数据编码和写入数据库时编码不一致
读取时：读取后所用编码与数据库写入时不一致
显示时：编码与数据库读取后的数据不一致

很显然只有三者都统一才行：（以utf-8为例）
1：页面提交数据编码 header('Content-type: text/html; charset=utf-8');），

2：数据库写入时编码：alter database db default character set ‘utf8’collate ‘utf8-general-ci’，
3：数据库读取时所用编码：mysql_query（“set names ‘utf8’”）；
4：显示页面编码：<meta http-equiv="Content-type"content=“text/html, charset=utf-8”>

5：转码函数：icovn('gbk','utf-8',"我是中国人")//从gbk转换成utf8

其实编码问题明白了原因，也就知道了解决办法。下面有些实例可以看一下！

一、实验：
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编码按页面字符集正常显示；

用示意图来表示就是：

1. 存入过程：
2. ----------------------
3. 页面    连接     存储
4. ----------------------
5. GBK =&gt; latin1 =&gt; utf-8
6. ---------------
7. ------------- |
8. |       +------- 该过程得到的utf-8是一串不知所云的乱码，但MySQL固执的认为这串码为UTF-8
9. |
10. +------ MySQL将GBK误认为是latin1
11. 读取过程：
12. ----------------------
13. 页面    连接     存储
14. ----------------------
15. GBK &lt;= latin1 &lt;= utf-8
16. ---------------
17. ------------- |
18. |       +------- 正是这串乱码经过逆过程转换回正确的GBK编码，只是MySQL认为是latin1而已
19. |
20. +------ MySQL将误认为是latin1的GBK编码传回了页面，刚好得到正确的编码。
21. 2、情况二
22. 数据库字段字符集：utf-8
23. 连接字符集：gbk
24. 页面字符集：gbk
25. 文字描述略。

示意图：

1. 存入过程：
2. ----------------------
3. 页面   连接   存储
4. ----------------------
5. GBK =&gt; GBK =&gt; utf-8
6. ------------
7. ------------- |
8. |       +------- 该过程得到的utf-8是由GBK转换而来的，是正确的utf-8编码
9. |
10. +------ 页面字符集等于连接字符集，MySQL认为页面传递给它的是GBK编码，它的想法正好符合事实。
11. 读取过程：
12. ----------------------
13. 页面   连接   存储
14. ----------------------
15. GBK &lt;= GBK &lt;= utf-8
16. ---------------
17. ------------- |
18. |       +------- 用“utf-8转GBK函数”将正确的utf-8编码转换回GBK
19. |
20. +------ 页面字符集等于连接字符集，显示没有任何问题。
21. 3、情况三
22. 数据库字段字符集：gbk
23. 连接字符集：没有显式设置，默认为latin1
24. 页面字符集：gbk

1. 存入过程：
2. ----------------------
3. 页面   连接   存储
4. ----------------------
5. GBK =&gt; latin1 =&gt; GBK
6. ------------
7. ------------- |
8. |       +------- 字符被“latin1转GBK函数”转换的成了乱码，但MySQL认为它是GBK，所以工具无法正常显示。
9. |
10. +------ MySQL认为页面传递给它的是latin1编码，它将在后续过程中画蛇添足地将正确的GBK转换为乱码。
11. 读取过程：
12. ----------------------
13. 页面   连接   存储
14. ----------------------
15. GBK &lt;= latin1 &lt;= GBK
16. ---------------
17. ------------- |
18. |       +------- “GBK转latin1函数”将乱码转换为GBK，但MySQL却认为它们是latin1
19. |
20. +------ 错误的latin1编码其实是正确的GBK编码，页面显示正常，但工具显示不正常。

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

1. $str = "中文测试";
2. $str_tran = iconv('latin1', 'utf-8', $str);
3. echo $str_tran; // 显示乱码，既不是GBK也不是utf-8和latin1
4. echo "&lt;br&gt;-----------&lt;br&gt;";
5. $str_re_tran = iconv('utf-8', 'latin1', $str_tran);
6. echo $str_re_tran;  // 显示 “中文测试”

而将GBK字符误当作utf-8转换为错误的GBK编码则出现错误

1. $str = "中文测试";
2. #$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）。