web程序乱码深入分析【基础原理篇】--php为例

佘小宝的爹

http://www.cnblogs.com/chengmo/archive/2010/10/18/1854755.html





web程序乱码深入分析【基础原理篇】--php为例
　　做web应用程序开发也有很多年了，前后涉及有，asp,asp.net,jsp,php 。尽管语言都不相同，在日常开发中，无论那门语言都出现过，浏览器端的乱码问题。 出现了，都会手忙脚乱一阵，上网查资料，一页一页看。 还有些紧张，因为boss可能还等着解决问题呢。 想必这些情况，做web开发的同人也是经常遇到的。 下面要讲的是比较原理性的，我想如果对于乱码产生原因找到了，以后出现类似问题。按照原理推论，一定也会很快解决。 （以下说明文件，都是以文本文件说明）
　　一、文本文件编码是什么？

　　 
　　A、文本文件编码存在哪里了呢？
　　我们知道，计算机存储文件，最终都是以二进制保存的，通过流方式读取任何文件，得到是8位的字节流。一个文件生成了，同时也确定了它的编码了。 以下通过软件：winhex比较说明：
　　通过使用记事本：输入“中”，另存为时候，分别选择：utf-8,unicode,ansi编码。我们通过winhex打开比较下。

　　utf-8:EF BB BFE4 B8 AD 6字节
　　unicode:FF FE2D 4E 4字节
　　ansi(gb2312):D6 D0  2字节
　　同一个汉字中，保存为文件后，实质存储的字节码各不相同。
　　这里我们一定想到一个问题，读取该文件的软件打开这个文件，怎么都可以显示出：“中”呢？ 
　　如果我们继续思考下就会想到： 这个文本文件的编码是不是存在文件属性中了呢？
　　答案是：查看属性没有任何不同
　　那文件编码存在：文件的字节码里面了？
　　哈哈，我也是这么想的，通过查阅资料知道，unicode码可以指定一个bom(顺序头），unicode常见表现形式有：utf-8,utf-16 顺序头不一样，因此很多软件可以通过这个标记来区分文件是什么编码了。 上面例子，utf-8头是：EFBBBF,unicode LE是：FFFE.
　　是不是所有文件编码都会写入到文件字节码里面呢？
　　如果真的这样的话，那么问题就简单了。所有应用程序读文本文件时候，读一下标记，那么就知道它是什么编码。 其实，除了unicode有bom这个特殊头外，其它编码可没有呢。 看到刚才那个：ansi(gb2312)编码了吗，值是：D6D0 刚才是“中” 在gb2312编码表中的代号。
　　 
　　B、怎么样获得文件编码呢？
　　上个例子中，我们知道，文本文件编码不可能都保存在文件字节码中。 那么，应用程序读取文件怎么样判断编码呢？

　　我们用：zend 工具，以EUC-JP生成一个文件，内容是：”中” ，通过：winHEX查看该文件，它的字节码是：C3 E6 。可以看到同样都是："中” gb2312保存文件，得到字节码是：D6 D0 .
　　我用windows 记事本打开：2个文件看一下：

　　怎么我文件内容是：”中“，用euc_jp编码保存后，用记事本打开，看到是：”面“ 了呢？ 是不是windows 记事本有问题呢？
　　记事本没有任何问题，windows 记事本在打开文本文件时候，会先判断bom类标记，如果发现文本文件存在该标记。那么，就能够知道它对应的编码了。然后，将字节流转换为对应编码字符串。 这样显示正常保存时候内容。
　　如果，没有bom头标记的文本，记事本程序，就默认当：ANSI编码处理了（在简体中文系统下，ANSI编码代表GB2312编码，在日文操作系统下，ANSI编码代表JIS编码），在简体中文下，ANSI对应是：gb2312。因此，记事本把”C3E6”当作gb2312处理。 C3E6在gb2312编码表中对应是汉字：“面” 了。
　　文本文件，保存时候存储编码，与读出时候设置编码，如果不统一，就会造成乱码！

　　二、php引擎怎么样获得我的文件编码

　　其实，这里说php引擎处理编码，与记事本识别编码基本是相同的。发现能够识别编码就识别，不能识别编码就按照：
　　php.in 中
　　default_charset = "iso-8859-1"
　　default_charset 指定编码处理了,默认是：iso-8859-1。
　　这里啰嗦一下，现在很多应用程序都会用："iso-8859-1" 作为默认编码，jsp也是这样的。它的优点大家应该可以理解：iso-8859-1(EASCII 扩展ASCII编码)以ASCII为基础，在空置的0xA0-0xFF的范围内，加入96个字母及符号，藉以供使用附加符号的拉丁字母语言使用。用一个8位字符可以表示任意字符集。在程序开发中，我们常用的变量，都会是英文字符空格之类，这些都会在解析时候保持原来不变。而对于的中文字符，都会是多字节的。iso-8859-1解析后，会变成一些西欧字符。 但是实际上，并不会影响程序任何逻辑。 因为那些乱七八糟的西欧字符，只是一些注释，或者值而已。 程序语法完全没有破坏！！
　　处理完的结果它还是字节流，准备发送给浏览器。

　　三、浏览器怎么样获得服务端的编码

　　这里我们知道，浏览器得到web服务端返回的文件流，默认是：iso-8859-1 字节码。其实可以看作是与原始存文件流的字节码是相同的。
　　浏览器也是一个软件，它获得了字节流，它从那里知道字节流是什么编码呢？
　　这里有几种形式：
　　A、HTTP resposne头告知编码
　　以下是：访问:baidu.com httpwatch 抓包图：

　　我们只抓取了：Stream这个选项卡，可以通过这里看到，右下返回内容是乱码，其实这些就是服务器返回字节流。 再往上看： 这里有个：charset。 哈哈，它就是服务端返回给浏览器的一个编码。浏览器通过这个编码就能够知道用什么编码类解析该字节流了。 注意，返回charset编码，一定要与该文件流保存编码一致。否则一样乱码！
　　B、通过html源码，meta头告知
　　并不是所有服务器端程序都会，都是很么按章出牌，告知自己流编码。很多时候，php开发人员没有加入：
　　header("Content-type:text/xml;charset=字符编码"); 那么浏览器还有其它方法处理吗？

　　如果meta头指定了，浏览器也一样知道编码是什么了。
　　C、有一些问题：
　　如果header,meta两个个都指定了以那个为准呢？
　　测试表明，以http 协议中，response 头里面的charset为主。 会忽视掉，meta指定。
　　如果header,meta两个都没有指定，会出现什么情况呢？
　　这个时候，就像上面例子里面的记事本了。 会怎么出现依据浏览器自己本身设置默认编码。如果你文件刚好是：gb2312编写，查看浏览器默认编码刚好也是：gb2312，那么你的中文字符显示正常。如果换上一个默认字符不一样，就会出现乱码情况。 这种情况，估计做web开发同人经常会遇到吧！