沉于思考,默默学习!

你不能预知明天,但你可以利用今天。你不能样样顺利,但你可以事事尽力!

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

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

 

一、文本文件编码是什么?

 

A、文本文件编码存在哪里了呢?

 

我们知道,计算机存储文件,最终都是以二进制保存的,通过流方式读取任何文件,得到是8位的字节流。一个文件生成了,同时也确定了它的编码了。 以下通过软件:winhex比较说明:

通过使用记事本:输入“中”,另存为时候,分别选择:utf-8,unicode,ansi编码。我们通过winhex打开比较下。

image

utf-8:EF BB BF E4 B8 AD 6字节

unicode:FF FE 2D 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、怎么样获得文件编码呢?

上个例子中,我们知道,文本文件编码不可能都保存在文件字节码中。 那么,应用程序读取文件怎么样判断编码呢?

image

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

我用windows 记事本打开:2个文件看一下:

image

怎么我文件内容是:”中“,用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 抓包图:

image

我们只抓取了:Stream这个选项卡,可以通过这里看到,右下返回内容是乱码,其实这些就是服务器返回字节流。 再往上看:image 这里有个:charset。 哈哈,它就是服务端返回给浏览器的一个编码。浏览器通过这个编码就能够知道用什么编码类解析该字节流了。 注意,返回charset编码,一定要与该文件流保存编码一致。否则一样乱码!

B、通过html源码,meta头告知

并不是所有服务器端程序都会,都是很么按章出牌,告知自己流编码。很多时候,php开发人员没有加入:

header("Content-type:text/xml;charset=字符编码"); 那么浏览器还有其它方法处理吗?

image

如果meta头指定了,浏览器也一样知道编码是什么了。

C、有一些问题:

如果header,meta两个个都指定了以那个为准呢?

测试表明,以http 协议中,response 头里面的charset为主。 会忽视掉,meta指定。

 

如果header,meta两个都没有指定,会出现什么情况呢?

这个时候,就像上面例子里面的记事本了。 会怎么出现依据浏览器自己本身设置默认编码。如果你文件刚好是:gb2312编写,查看浏览器默认编码刚好也是:gb2312,那么你的中文字符显示正常。如果换上一个默认字符不一样,就会出现乱码情况。 这种情况,估计做web开发同人经常会遇到吧!

 

这篇文章,只是我charset字符集中一部分。比较基础,以后我会写写其它字符集相关的。欢迎朋友点评!

posted on 2010-10-18 18:23  程默  阅读(2339)  评论(0编辑  收藏  举报