php+MySQL+Apache网页乱码问题收集
php echo 后输出的JS弹出消息窗口时显示的是乱码，google后收集总结如下： 
编码和字符的详细探讨
June 15th, 2008 Posted in PHP笔记
好久就想对字符和编码的问题研究一下了，一直没抽出闲时间来，今天周末，给自己放个假，于是就有了如下关于字符和编码的问题。希望能对大家关于乱码的问题有点用处。
一：首先我们先一起来了解下基础知：
- bit（比特或位）：计算机内存由数以亿万计的bit组成，每个位可以容纳值0或1；
- 字节：计算机中存储数据的单元，一个8位的二进制数（8个bit），是一个很具体的存储空间；
- 字符：通俗一点讲就是“记号”的意思，一个符号而已，比如我们天天用到的阿拉伯数字，或者英文字母，都是字符；
- 字符集：“字符”的集合就叫做“字符集”；
- 编码：规定每个字符用哪一个或哪几个字节来存储的规则叫做编码。
二：字符与编码的发展
- 阶段一 ASCII 计算机刚开始只支持英语，其它语言不能够在计算机上存储和显示。
单字节字符串使用一个字节存放一个字符（SBCS）。比如，”Bob123″ 在内存中为：
42 6F 62 31 32 33 00
B o b 1 2 3 \0
- 阶段二 ANSI编码
（本地化） 为使计算机支持更多语言，通常使用 0×80~0xFF 范围的 2 个字节来表示 1 个字符。比如：汉字 ‘中’ 在中文操作系统中，使用 [0xD6,0xD0] 这两个字节存储。
不同的国家和地区制定了不同的标准，由此产生了 GB2312, BIG5, JIS 等各自的编码标准。这些使用 2 个字节来代表一个字符的各种汉字延伸编码方式，称为 ANSI 编码。在简体中文系统下，ANSI 编码代表 GB2312 编码，在日文操作系统下，ANSI 编码代表 JIS 编码。
不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中。
在使用 ANSI 编码支持多种语言阶段，每个字符使用一个字节或多个字节来表示（MBCS），因此，这种方式存放的字符也被称作多字节字符。比如，”中文123″ 在中文 Windows 95 内存中为7个字节，每个汉字占2个字节，每个英文和数字字符占1个字节：
D6 D0 CE C4 31 32 33 00
中 文 1 2 3 \0
- 阶段三 UNICODE
（国际化） 为了使国际间信息交流更加方便，国际组织制定了 UNICODE 字符集，为各种语言中的每一个字符设定了统一并且唯一的数字编号，以满足跨语言、跨平台进行文本转换、处理的要求。 UNICODE 被采用之后，计算机存放字符串时，改为存放每个字符在 UNICODE 字符集中的序号。目前计算机一般使用 2 个字节（16 位）来存放一个序号（DBCS），因此，这种方式存放的字符也被称作宽字节字符。比如，字符串 “中文123″ 在 Windows 2000 下，内存中实际存放的是 5 个序号：
2D 4E 87 65 31 00 32 00 33 00 00 00
中 文 1 2 3 \0
三 常用的编码
- iso8859-1 属于单字节编码，最多能表示的字符范围是0-255，应用于英文系列。比如，字母’a'的编码为0×61=97。很明显，iso8859-1编码表示的字符范围很窄，无法表示中文字符。但是，由于是单字节编码，和计算机最基础的表示单位一致，所以很多时候，仍旧使用iso8859-1编码来表示。而且在很多协议上，默认使用该编码。比如，虽然”中文”两个字不存在iso8859-1编码，以gb2312编码为例，应该是”d6d0 cec4″两个字符，使用iso8859-1编码的时候则将它拆开为4个字节来表示：”d6 d0 ce c4″（事实上，在进行存储的时候，也是以字节为单位处理的）。而如果是UTF编码，则是6个字节”e4 b8 ad e6 96 87″。很明显，这种表示方法还需要以另一种编码为基础。
- GB2312/GBK 这就是汉子的国标码，专门用来表示汉字，是双字节编码，而英文字母和iso8859-1一致（兼容iso8859-1编码）。其中gbk编码能够用来同时表示繁体字和简体字，而gb2312只能表示简体字，gbk是兼容gb2312编码的。
- unicode 这是最统一的编码，可以用来表示所有语言的字符，而且是定长双字节（也有四字节的）编码，包括英文字母在内。所以可以说它是不兼容iso8859-1编码的，也不兼容任何编码。不过，相对于iso8859-1编码来说，uniocode编码只是在前面增加了一个0字节，比如字母’a'为”00 61″。需要说明的是，定长编码便于计算机处理（注意GB2312/GBK不是定长编码），而unicode又可以用来表示所有字符，所以在很多软件内部是使用unicode编码来处理的，比如java。
- UTF 考虑到unicode编码不兼容 iso8859-1编码，而且容易占用更多的空间：因为对于英文字母，unicode也需要两个字节来表示。所以unicode不便于传输和存储。因此而产生了utf编码，utf编码兼容iso8859-1编码，同时也可以用来表示所有语言的字符，不过，utf编码是不定长编码，每一个字符的长度从1-6 个字节不等。另外，utf编码自带简单的校验功能。一般来讲，英文字母都是用一个字节表示，而汉字使用三个字节。注意，虽然说utf是为了使用更少的空间而使用的，但那只是相对于unicode编码来说，如果已经知道是汉字，则使用GB2312/GBK无疑是最节省的。不过另一方面，值得说明的是，虽然utf编码对汉字使用3个字节，但即使对于汉字网页，utf编码也会比unicode编码节省，因为网页中包含了很多的英文字符。
IE中打开UTF-8编码title为中文的网页会显示空白页的问题
on 2006.8.10 归类于 网页设计 5,247字 标签：bug, IE, unicode.
很久很久以前(大概2005年10月~2006年3月)，当时在blogger.com写Blog。当时blogger.com有中文界面，对中文用户也算是比较关心了，不过blogger.com的所有模版里都有一个问题，那就是<title>标签被放在<meta>标签前面。当title为中文的时(比如Blog名为中文或者文章标题为中文)，在IE下会出现显示空白页的问题。昨天Dre·J在群里又问到这个问题，今天过来好好研究一下。
这个问题只存在于blogger.com中，WordPress系统中不存在。先说一下在blogger.com中这个问题的解决办法：在模版的<body>标签下面找到<title>标签，调整成这样：
<$BlogMetaData$><title><$BlogPageTitle$></title>保证meta在前面就可以了。可以参考《感谢Yskin》和《UTF-8字符集网页在IE上会显示空白问题的解决方案》。
这个问题要从浏览器解析html的方式讲起。浏览器读取了页面的html代码后开始进行解析。解析前浏览器要先知道页面的编码方式，然后根据编码方式进行解码，然后才能开始解析。我大概想了一下，浏览器可以从下面3个方面得到页面编码方式：HTTP Header中的"Content-Type"项、返回的html代码开头是否有BOM、html代码中的meta标签。
做了一个小测试，使用Windows 2000 SP4操作系统，IE6 SP1和Firefox 1.5.0.5浏览器。所有文件使用DOS格式换行符。测试代码如下：
<?phpheader("Content-Type: text/html; charset=utf-8");?><html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>你好啊</title></head><body>你好啊。</body>先不要前面的PHP语句，直接使用html文件，分无meta、meta在title前、meta在title后3种方式，分别做成GBK、UTF-8(no BOM)、UTF-8(BOM)三种编码方式的文件，再分别用IE和Firefox测试。我的Blog所在的服务器上，访问html文件时HTTP Header里Content-Type是Content-Type: text/html。第二遍测试加上PHP语句，用Header函数给HTTP Header中加上Content-Type: text/html; charset=utf-8，再把第一遍做的重新做一遍。
|
|
IE6 SP1 |
Firefox 1.5.0.5 |
字节 |
地址 |
| 无meta |
||||
| GBK |
正常 |
正常 |
73 |
|
| UTF-8(no BOM) |
空白页 |
使用GBK解码形成乱码 |
80 |
|
| UTF-8(BOM) |
正常 |
正常 |
83 |
|
| meta在前 |
||||
| GBK |
使用UTF-8解码形成乱码 |
使用UTF-8解码形成乱码 |
144 |
|
| UTF-8(no BOM) |
正常 |
正常 |
151 |
|
| UTF-8(BOM) |
正常 |
正常 |
154 |
|
| meta在后 |
||||
| GBK |
使用UTF-8解码形成乱码 |
使用UTF-8解码形成乱码 |
144 |
|
| UTF-8(no BOM) |
空白页 |
正常 |
151 |
|
| UTF-8(BOM) |
正常 |
正常 |
154 |
|
| ---加了Header语句后--- |
||||
| 无meta |
||||
| GBK |
使用UTF-8解码形成乱码 |
使用UTF-8解码形成乱码 |
133 |
|
| UTF-8(no BOM) |
正常 |
正常 |
140 |
|
| UTF-8(BOM) |
正常 |
正常 |
143 |
|
| meta在前 |
||||
| GBK |
使用UTF-8解码形成乱码 |
使用UTF-8解码形成乱码 |
204 |
|
| UTF-8(no BOM) |
正常 |
正常 |
211 |
|
| UTF-8(BOM) |
正常 |
正常 |
214 |
|
| meta在后 |
||||
| GBK |
使用UTF-8解码形成乱码 |
使用UTF-8解码形成乱码 |
204 |
|
| UTF-8(no BOM) |
正常 |
正常 |
211 |
|
| UTF-8(BOM) |
正常 |
正常 |
214 |
文件中有6个汉字和一个汉字句号，所以UTF-8(no BOM)格式比GBK格式多出7个字节。UTF-8的BOM占用3个字节，所以UTF-8(BOM)比UTF-8(no BOM)多出3个字节。经验证，所有数据都符合这个规则，所以各文件格式没有错误。
PHP不支持BOM，又因为BOM的3个字符在最前面，显示不包含在<?php...?>标签里，所以PHP引擎会3个字符输出，于是输出的html文件也有了BOM。所以这次测试中，为了修改http header而加入的PHP语句不影响最终输出的html文件的BOM。
从测试结果可以看出，浏览器(无论是IE还是Firefox)在解析页面时，首先取HTTP Header中的Content-Type项，如果有写明charset的话就认定页面的编码方式为charset指定的值。如果没有指明，则认定为默认值。根据上表，IE中文版的默认值是GB2312，Firefox中文版的默认值是GBK，不过IE的GB2312好像和GBK没啥区别。然后，浏览器会看一下有没有BOM。一旦发现有UTF-8的3字节BOM，则重新认定页面的编码方式为UTF-8。
然后是解码阶段，解码完成后是解析html的阶段。解析html的过程中，当解析到head部分的meta标签时，浏览器会根据<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />这个语句中的说明，重新认定编码方式为charset后面的方式，中断html解析过程，返回到解码步骤重新解码。
知道了这个步骤，再来看这个表：在加了Header语句设置了HTTP Header后，两个浏览器解析所有页面都是用的UTF-8方式，包括GBK编码的页面。(当然要正常解析GBK编码的文件，可以在title前加上个meta标签标明编码方式。)在上表的下半部分可以清楚的看到这一点。再来看上半部分，在没有加Header语句的页面里，首先浏览器认定页面编码方式为默认值GBK。检测有无UTF-8的3字节BOM，检测到的，认定页面编码方式为UTF-8，解码再解析html，一切正常。如上表所示，上半部分带BOM的页面都能正常显示。如果没有BOM，页面可能是GBK或者UTF-8(no BOM)格式，浏览器会先按照默认的GBK方式开始解码。页面为GBK格式时，无meta时正常，有meta时浏览器解析到meta标签会回头重现按UTF-8方式解码，所以GBK,meta在前或后，无论IE还是FF都是乱码。再看UTF-8(no BOM)的页面，无meta时FF用GBK方式解码下去，最终显示乱码，IE则解码出错，形成空白页。有meta时，Firefox找到meta后回头重新按UTF-8方式解码，所以无论meta在前或在后都是正常；IE则是在meta在前时能够和Firefox一样回头重新解码，当meta在后时，又是解析到title出错，返回空白页。
所以，IE显示空白页的问题，很明显是因为IE的解码程序兼容性差。上网查了下，GBK的编码范围是0×8140-0xfefe。从GB2312-80开始，因为ASCII码的范围是0~127，首字位是0，所以GB2312-80使用双字节，并设置首字位为1。“GBK 亦采用双字节表示，总体编码范围为 8140-FEFE，首字节在 81-FE 之间，尾字节在 40-FE 之间。”[via]UTF-8中中文都是3个字节的，由于Unicode中中日韩的文字都混在一起，可以使用Windows自带的字符映射表查看CJK表意字符的范围，即为汉字的范围。(可以参考我的这篇文章里的图片)3字节的UTF-8编码是这样子的：1110xxxx 10xxxxxx 10xxxxxx，编码范围是8000-EFFF，首字节在80-EF之间，尾字节在00-FF之间。[via]显然当一段UTF-8编码的文本被按照GBK方式解码的时候，由于有一些编码在GBK中不存在，造成解码程序出现错误。当UTF-8文本被按照GBK的方式解码的时候，前两个字节会被认为是一个字，后一个字节将和下一个字符结合。当<title>标签里的汉字数是偶数个时，勉强有3/4的概率通过解码程序(因为GBK的第二个字节要求是40-FE)，当有奇数个汉字的时候，最后一个汉字的三个字节的最后一个字节会和</title>的第一个字符<结合，而<的编码是3C，正好不在尾字节40-FE的范围中，造成错误。如果</title>标签前有多余的空格也会产生错误，因为空格的编码20也不在范围中。
再做一个测试，修改t12.html中title的部分，修改成两个汉字，再用IE打开发现不再是空白页，而是用GBK编码导致的乱码页面了。地址：s.html
所以，空白页的出现是不固定的。《UTF-8字符集网页在IE上会显示空白问题的解决方案》所说的“IE 解析网页编码时是 HTML 內的标识优先的，然后是 HTTP header ；而mozilla 系列的浏览器刚刚好相反。”是不对的。在网上搜索“meta的作用”，很容易就可以找到一堆meta标签的说明。比如《HTML中meta的作用》里提到：“meta是用来在HTML文档中模拟HTTP协议的响应头报文。”在meta标签中写和在HTTP头里写是一样的，这也是为了解决用普通HTML写网页的人无法自行定义HTTP头的问题。但是，meta是一个html标签，所以必须进入到html解析的步骤才能生效，而生效后，浏览器会退回几步，重新设置好HTTP头从头再开始解码、解析html。所以meta中写的内容会覆盖HTTP头里的内容，无论哪个浏览器都是这样的。如果象他所说的，mozilla系列浏览器是HTTP Header优先于HTML内的标识，那meta标签不就等于没有用了吗？这不符合html标准。
而《一个 utf-8 网页在 IE6 下的BUG》中所说的出现空白页必须的3项条件(1.title标签里的内容为中文其他双字节字符；2.指定网页编码的 meta 信息在 title 标签的下方；3.另存或转换utf-8编码时没有包括 unicode 签名 (BOM))基本上正确，不过不够全面，具体的原因我上面已经详细分析过了。还有BOM不能算签名吧，唉，就叫他BOM好了，Byte Order Mark，字节序标识，用于UTF-16编码的文件，在UTF-8编码的文件中不需要标识字节序，所以被用来标识这是一个UTF-8编码文件。
这个问题还是IE的兼容性问题，在解码的时候如果遇到错误的编码就中断解码。毕竟html代码是从网络上传输过来的，很可能传错几个字节，所以解码程序不必弄的这么严格吧。乱码页面起码让浏览者知道网页已经打开，有点经验的会知道切换网页编码，如果是空白页很可能被浏览者认为是网页本身就是空白的，从而放弃浏览。IE在html解析和CSS解析上容错性很好的呀，怎么解码这块会做的这么严格呢。某些天天喊叫IE兼容性好，IE能正常浏览的网页多的人，你看这个，这个，嘿嘿。
测试了一下，blogspot,sitesled,Blogger Spaces上的页面都是返回的Content-Type: text/html，所以他们都会出现空白页的问题。好像Apache默认情况下不会乱声明编码方式的，无论是国外的主机还是国内的主机。我的Blog的页面的HTTP Header都包含Content-Type: text/html; charset=UTF-8，后台的页面也都有，一般不会有问题。比较奇怪的是，我查了WordPress和K2所有的文件，也没发现哪儿用Header命令设置过这个HTTP头。一些输出RSS和atom或者是发送trackback的文件都很仔细的用Header命令设置这个HTTP头，不过不存在一个地方用了Header命令从而一劳永逸地使所有输出的页面都包含这个头的。难道Apache在处理PHP文件的时候会自动检测文件的编码方式并设置HTTP头吗？WordPress自带的WordPress Default和WordPress Classic模版都把 单独放在title标签的前面，可能WordPress开发组注意到了这个问题，K2模版则没有注意这个问题。blogger.com的模版也没有注意这个问题，难道老外都习惯了meta一起放在title下面？
另外，这个是IE的bug，不过也不要认为你用的是MyIE、MyIE2、遨游Maxthon、GreenBrowser、腾讯TT就不会受到影响，他们都是以IE为核心的，IE的bug他们一个个都跑不掉。尽早投降吧，投到Firefox或者Opera的怀抱里来吧
在论坛里看到很多人碰到将数据插入到数据库的时候显示乱码及从数据库读取出来的数据在网页上显示为乱码的问题，为了能方便用户能在第一时间解决问题，今天特意写了这个教程，希望对有需要的朋友有所帮助。（其实就是做到数据库编码，网页编码及表的编码一致）！GBK2312与下同理
(1) 设置数据库编码， 为了与国际接轨，一般都设置成utf-8
mysql1.gif (16.06 KB)
2007-11-2 13:34
（2）数据表的设置，也设置成utf-8
mysql2.gif (17.23 KB)
2007-11-2 13:34
(3)把你的网页编码也设置成utf-8,打开Dreamweaver，（修改）--（页面属性）
3.gif (7.54 KB)
2007-11-2 13:34
4.gif (18.36 KB)
2007-11-2 13:34
（4）在你的PHP文件的第一行加上 header("Content-Type: text/html; charset=utf-8");
5.gif (1.76 KB)
2007-11-2 13:34
（5）在对数据进行操作之前应该先进行mysql_query('set names utf8');操作，然后再执行对数据的查询，更新，插入等
6.gif (9.49 KB)
2007-11-2 13:34
实践：
1、安装mysql选utf8，就这一步就好了。以后数据库和表的建立都是命令行或*.sql导入，不会涉及phpmyadmin的问题。其实*.sql导入非常方便。而且文档也好。
2、选了utf8也有烦恼，想用dos控制看，都是乱码。都在本地的话，控制台比phpmyadmin方便多了。谁能给出一个windows下支持utf8中文的方法啊。
3、如果php.ini设置为gb2312，连接数据库是设置set names 'gb2312'，不想就每次也好办，类。
当然，开发的用途不一样，设置可能就不同
Apache和PHP网页的编码问题分析
谈谈Apache和PHP网页的编码。还有一篇关于MySQL字符集的：http://www.phpchina.com/bbs/viewthread.php?tid=13861
谈到Apache的编码我们就要涉及到3个东西
· http标记语言中的<META http-equiv="content-type" content="text/html; charset=xxx">标签
· PHP中的header("content-type:text/html; charset=xxx");函数
· Apache配置文件httpd.conf中的AddDefaultCharset
一、<META http-equiv="content-type" content="text/html; charset=xxx">标签
按顺序来，先说这个<META>标签，这个标签有很多功能的，具体请点这里。
我今天想说只是上面提到的那种形式。解释一下<META http-equiv="content-type" content="text/html; charset=utf-8">，意思是对这个网页进行声明，让浏览器对整个页面的内容采用xxx编码，xxx可以为GB2312，GBK，UTF-8（和MySQL不同，MySQL是UTF8）等等。因此，大部分页面可以采用这种方式来告诉浏览器显示这个页面的时候采用什么编码，这样才不会造成编码错误而产生乱码。但是有的时候我们会发现有了这句还是不行，不管xxx是哪一种，浏览器采用的始终都是一种编码，这个情况我后面会谈到。
请注意，<meta>是属于html信息的，仅仅是一个声明，它起作用表明服务器已经把HTML信息传到了浏览器。
二、header("content-type:text/html; charset=xxx");
这个函数header()的作用是把括号里面的信息发到http标头。关于此函数具体用法请点击这里。
如果括号里面的内容为文中所说那样，那作用和<META>标签基本相同，大家对照第一个看发现字符都差不多的。但是不同的是如果有这段函数，浏览器就会永远采用你所要求的xxx编码，绝对不会不听话，因此这个函数是很有用的。为什么会这样呢？那就得说说HTTPS标头和HTML信息的差别了：
引用:
https标头是服务器以HTTP协议传送HTML信息到浏览器前所送出的字串。
因为meta标签是属于html信息的，所以header()发送的内容先到达浏览器，通俗点就是header()的优先级高于meta（不知道可不可以这样讲）。加入一个php页面既有header("content-type:text/html; charset=xxx")，又有<META http-equiv="content-type" content="text/html; charset=xxx">，浏览器就只认前者http标头而不认meta了。当然这个函数只能在php页面内使用。
同样也留有一个问题，为什么前者就绝对起作用，而后者有时候就不行呢？这就是接下来要谈的Apache的原因了。
三、AddDefaultCharset
Apache根目录的conf文件夹里，有整个Apache的配置文档httpd.conf。具体如何配置apache请点击这里（[url=thread-2674-1-1.html]windows[/url]，[url=thread-1381-1-1.html]linux[/url]）。
用文本编辑器打开httpd.conf，第708行（不同版本可能不同）有AddDefaultCharset xxx，xxx为编码名称。这行代码的意思：设置整个服务器内的网页文件https标头里的字符集为你默认的xxx字符集。有这行，就相当于给每个文件都加了一行header("content-type:text/html; charset=xxx")。这下就明白为什么明明meta设置了是utf-8，可浏览器始终采用gb2312的原因。
如果网页里有header("content-type:text/html; charset=xxx")，就把默认的字符集改为你设置的字符集，所以这个函数永远有用。如果把AddDefaultCharset xxx前面加个“#”，注释掉这句，而且页面里不含header("content-type…")，那这个时候就轮到meta标签起作用了。
总结：
来个排序
1. header("content-type:text/html; charset=xxx")
2. AddDefaultCharset xxx
3. <META http-equiv="content-type" content="text/html; charset=xxx">
如果你是web程序员，给你的每个页面都加个header("content-type:text/html; charset=xxx")，保证它在任何服务器都能正确显示，可移植性强。
至于那句AddDefaultCharset xxx，要不要注释就仁者见仁了。反正我是注释掉了，不过我写页子也要写header()，便于放到不同的服务器上能正常显示。
Apache2.2\conf\extra httpd-languages.conf
加入：
DefaultLanguage zh-CN
AddDefaultCharset utf-8