php 中文乱码的解决方法大集

首先是PHP网页的编码

1.     php教程文件本身的编码与网页的编码应匹配

a.     如果欲使用gb2312编码，那么php要输出头：header(“Content-Type: text/html; charset=gb2312")，静态页面添加<meta http-equiv="Content-Type" content="text/html; charset=gb2312">，所有文件的编码格式为ANSI，可用记事本打开，另存为选择编码为ANSI，覆盖源文件。

b.     如果欲使用utf-8编码，那么php要输出头：header(“Content-Type: text/html; charset=utf-8")，静态页面添加<meta http-equiv="Content-Type" content="text/html; charset=utf-8">，所有文件的编码格式为utf-8。保存为utf-8可能会有点麻烦，一般utf-8文件开头会有BOM，如果使用session就会出问题，可用editplus来保存，在editplus中，工具->参数选择->文件->UTF-8签名，选择总是删除，再保存就可以去掉BOM信息了。

2.     php本身不是Unicode的，所有substr之类的函数得改成mb_substr（需要装mbstring扩展）；或者用iconv转码。

二．         PHP与Mysql的数据交互

PHP与数据库教程的编码应一致

1.     修改mysql教程配置文件my.ini或my.cnf，mysql最好用utf8编码

[mysql]
default-character-set=utf8
[mysqld]
default-character-set=utf8
default-storage-engine=MyISAM
在[mysqld]下加入:
default-collation=utf8_bin
init_connect='SET NAMES utf8'

2.     在需要做数据库操作的php程序前加mysql_query("set names '编码'");，编码和php编码一致，如果php编码是gb2312那mysql编码就是gb2312，如果是utf-8那mysql编码就是utf8，这样插入或检索数据时就不会出现乱码了

三．         PHP与操作系统相关

 

         Windows和Linux的编码是不一样的，在Windows环境下，调用PHP的函数时参数如果是utf-8编码会出现错误，比如move_uploaded_file()、filesize()、readfile()等，这些函数在处理上传、下载时经常会用到，调用时可能会出现下面的错误:

Warning: move_uploaded_file()[function.move-uploaded-file]:failed to open stream: Invalid argument in ...

Warning: move_uploaded_file()[function.move-uploaded-file]:Unable to move '' to '' in ...

Warning: filesize() [function.filesize]: stat failed for ... in ...

Warning: readfile() [function.readfile]: failed to open stream: Invalid argument in ..

     在Linux环境下用gb2312编码虽然不会出现这些错误，但保存后的文件名出现乱码导致无法读取文件，这时可先将参数转换成操作系统识别的编码，编码转换可用mb_convert_encoding(字符串,新编码,原编码)或iconv(原编码,新编码,字符串)，这样处理后保存的文件名就不会出现乱码，也可以正常读取文件，实现中文名称文件的上传、下载。

    其实还有更好的解决方法，彻底与系统脱离，也就不用考虑系统是何编码。可以生成一个只有字母和数字的序列作为文件名，而将原来带有中文的名字保存在数据库中，这样调用move_uploaded_file()就不会出现问题，下载的时候只需将文件名改为原来带有中文的名字。实现下载的代码如下

header("Pragma: public");

header("Expires: 0");

header("Cache-Component: must-revalidate, post-check=0, pre-check=0");

header("Content-type: $file_type");

header("Content-Length: $file_size");

       header("Content-Disposition: attachment; filename="$file_name"");

header("Content-Transfer-Encoding: binary");

readfile($file_path);  

$file_type是文件的类型，$file_name是原来的名字，$file_path是保存在服务上文件的地址

php文件与静态网页的编码要一致。

1.使用utf-8编码的时候，php文件在所有输出之前加上：

header(“Content-Type: text/html; charset=utf-8")；
静态页面添加：
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">。

所有文件的编码格式为utf-8。保存为utf-8可能会有点麻烦，类似WINDOWS自带的记事本等软件，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM——Byte Order Mark）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件，这样并不会产生什么麻烦。

但对于 PHP来说，PHP在设计时就没有考虑BOM的问题，不会忽略UTF-8编码的文件开头 BOM的那三个字符，会把BOM作为该文件开头正文的一部分。由于必须在<?或者<?php后面的代码才会作为PHP代码执行，所以将会造成在页面上输出这三个字符，显示效果就要看浏览器了，一般是一个空行或是一个乱码。由于受COOKIE送出机制的限制，在这些文件开头已经有BOM的文件中，COOKIE无法送出（因为在 COOKIE送出前PHP已经送出了文件头），所以登入和登出功能失效。一切依赖COOKIE、SESSION实现的功能全部无效。
可用EmEditor来保存，在EmEditor中，另存为->去掉unicode签名（BOM）前的勾，再保存就可以去掉BOM信息了。

2.使用gb2312编码，php文件在所有输出之前加上：

header(“Content-Type: text/html; charset=gb2312")，
页面添加
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">

所有文件的编码格式为ANSI。

二．PHP与数据库的编码应一致
以Mysql数据库为例，在需要做数据库操作的php程序前加mysql_query("set names 'xx'");，如果php编码是gb2312那xx就是gb2312，如果是utf-8那xx就是 utf8（是utf8 而不是utf-8），这样操作数据时就不会出现乱码了。

另外mysql最好用utf8编码，修改mysql配置文件 my.ini或my.cnf

[mysql]
default-character-set=utf8
[mysqld]
default-character-set=utf8
default-storage-engine=MyISAM

在 [mysqld]下加入:
default-collation=utf8_bin
init_connect='SET NAMES utf8'

echo输出的中文显示成乱码，
其实应该是各种服务器脚本都会遇到这个问题，
根本还是编码问题，
一般来说出于编码兼容考虑大多的页面都将页面字符集定义为utf-8

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
这时候要正常显示中文需要转化一下编码方式，比如
echo iconv("GB2312","UTF-8",'中文');就不会乱码了
还有其他方法，比如
在php的echo前面加入header("Content-Type:text/html;charset=gb2312");
当然简体中文页面也可以干脆地，
把<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />中的UTF-8改成gb2312

 
实际中遇见奇怪的现象，
在本机服务器上正常显示的页面，传上服务器就echo出来乱码，
没仔细琢磨过这个缘由，因为通过iconv函数GB2312、UTF-8换换位置重新编码下就正常了，
不过估计肯定是APACHE，更确切说是PHP服务端的设置不同造成的，
看看PHP.INI应该就能解决

再来总结一下为什么会乱码

一般来说，乱码的出现有2种原因，首先是由于编码(charset) 设置错误，导致浏览器以错误的编码来解析，从而出现了满屏乱七八糟的“天书”，其次是文件被以错误的编码打开，然后保存，比如一个文本文件原先是GB2312 编码的，却以UTF-8 编码打开再保存。要解决上述乱码问题，首先需要知道开发中哪些环节涉及到了编码：

1、文件编码：指的是页面文件(.html,.php等)本身是以何种编码来保存的。记事本和Dreamweaver 在打开页面时候会自动识别文件编码因而不太会出问题。而ZendStudio却不会自动识别编码，它只会根据首选项的配置固定以某种编码打开文件，如果工作时候一不注意，用错误编码打开文件，做了修改之后一保存，乱码就出现了（我深有体会）。

2、页面申明编码：在HTML代码HEAD里面，可以用<meta http-equiv="Content-Type" content="text/html; charset="XXX" /> 来告诉浏览器网页采用了什么编码，目前中文网站开发中XXX主要用的是GB2312和UTF-8 两种编码。

3、数据库连接编码：指的是进行数据库操作时候以哪种编码与数据库传输数据，这里需要注意的是不要与数据库本身的编码混淆，比如MySQL内部默认是latin1编码，也就是说Mysql是以latin1编码来存储数据，以其他编码传输给Mysql的数据会被转换成latin1编码。
知道了WEB开发中哪些地方涉及到了编码，也就知道了乱码产生的原因：上述3项编码设置不一致，由于各种编码绝大部分是兼容ASCII的，所以英文符号不会出现，中文就倒霉了。

<html>
<head>
<title></title>
</head>
<body>
<?php
$mysql_server_name='localhost';
$mysql_username='root';
$mysql_password='000000';
$mysql_database='lib';
$conn=mysql_connect($mysql_server_name,$mysql_username,$mysql_password,$mysql_database);
$sql="select name,age from mytb";
print($conn);
$rs=mysql_db_query("lib","select * from mytb",$conn);
print("
<br>");
while($row = mysql_fetch_object($rs)){
print ($row->name.":".$row->age."<br>");
}
mysql_close($conn);
?>

　　显示如下：

Resource id #1
dd:54
ddd:8
??:15
???:25
??:32
　　mysql编码：utf8,GBK都试过了。mysql font 和命令行显示都正确。

　　问题补充：

　　乱码:

???:15
???:25
??:32
　　这几行,数据库里的值是汉字.显示出来的是问号.

　　解决办法：

　　在$rs=mysql_db_query("lib","select * from mytb",$conn);

　　前面加上

　　mysql_query("set names gb2312");或者mysql_query("set names gbk");

五．决战一些常见的错误情况与解决：

1、数据库采用UTF8 编码，而页面申明编码是GB2312 ，这是最常见的产生乱码的原因。这时候在PHP脚本里面直接SELECT数据出来的就是乱码，需要在查询前先使用： mysql_query("SET NAMES GBK"); 来设定MYSQL连接编码，保证页面申明编码与这里设定的连接编码一致（GBK是GB2312的扩展 ）。如果页面是UTF-8 编码的话，可以用： mysql_query("SET NAMES UTF8");
注意是UTF8而不是一般用的UTF-8。假如页面申明的编码与数据库内部编码一致可以不设定连接编码。

注：事实上MYSQL的数据输入输出比上面讲的更复杂一些，MYSQL配置文件my.ini中定义了2个默认编码，分别是[client]里的default -character-set和[mysqld] 里的default-character-set 来分别设定默认时候客户端连接和数据库内部所采用的编码。我们上面指定的编码其实是MYSQL客户端连接服务器时候的命令行参数character_set_client，来告诉MYSQL服务器接受到的客户端数据是什么编码的，而不是采用默认编码。

2、页面申明编码与文件本身编码不一致，这种情况很少发生，因为如果编码不一致美工做页面时候在浏览器看到的就是乱码了。更多时候是发布以后修改一些小BUG，以错误编码打开页面然后保存导致的。或者是用某些FTP软件直接在线修改文件，比如CuteFTP，由于软件编码配置错误而导致转换错了编码。

3、一些租用虚拟主机的朋友，明明上述3项编码都设置正确了还是有乱码。比方说网页是GB2312 编码的，IE等浏览器打开却总是识别成UTF-8 ，网页HEAD里面已经申明是GB2312 了，手动修改浏览器编码为GB2312 后页面显示正常。产生原因是服务器Apache设定了服务器全局的默认编码，在httpd.conf里面加了AddDefaultCharset UTF-8 。这时候服务器会首先发送HTTP头给浏览器，其优先级比页面里申明编码高，自然浏览器就识别错了。解决办法有2个，请管理员在配置文件自己的虚机里加上一条AddDefaultCharset GB2312 来覆盖全局配置，或者在自己目录的.htaccess里配置。

ajax页面乱码与get post乱码的解决
之前做ASP页面各种乱码,页面刷新就乱码或者链接就乱码,昨晚去问了下度娘,总结出一个解决办,在所有ASP页面之前加上 <% @ CODEPAGE = "65001" LANGUAGE = "VBSCRIPT" %> <% Response.CODEPAGE = 65001%> ,65001指的是UTF-8编码格式 GB2312是936,原因就是你在进入UTF-8页面的时候 其他程序没有声明Response.CodePage 而是 Session.CodePage立即被赋值了 （65001或936因版本不同赋值不一样）,接着进入另一页的时候 另一页的Response.CodePage立即被Session.CodePage赋值 于是如果那个页得@ CODEPAGE = 936 的话 你这个页的 Response.CodePage 被赋值成了 65001肯定会出乱码的 所以 在页面的开头先统一写好编码 。

　　然后昨晚后来又碰到一个问题是AJAX返回中文的时候显示乱码而 2个页面的编码都是一样的UTF-8 为毛会出现乱码 查了度娘是说在AJAX处理页面加上 <% Response.Charset = "UTF-8"%> 结果页面显示不出内容 自己研究了下估计是数据库教程的数据编码问题,因为ACCESS数据编码是根据你写进去数据时的编码我写进去的时候是GB2312现在用UTF-8格式的编码解码肯定会乱码 怎么办呢 把<% Response.Charset = "GB2312" %> 然后AJAX中文就返回正常了 . 这里讲下 Charset属性在W3C的解释是 向页面的Response对象中content-type 头部追加字符集名称。

　　添加 <% Response.Charset = "GB2312"%>

　　页面输出显示

　　<%content-type:text/html; charset=GB2312%>

我估计是Charset将字符集改成了GB2312所以可以接受GB2312编码的数据所以就不会乱码了

看一下get,post乱码的ajax解决办法

数据出现乱码从程序执行的过程来讲分为两种，一种是发送给后台程序的中文本身就是乱码，因为xmlHTTP沿用的是网页特效的字处理机制，使用UTF-8编码。但是后台页面使用GB2312或者其它类型编码的话，接收到的数据自然就是乱码了。还有一种是接受到数据再返回的时候，出现字符乱码。这也是因为后台页面使用的编码和Javascript编码不同造成的。服务器脚本返回的字符默认会使用服务器编码例如GB2312。服务器发回数据乱码问题是很容易解决的，我们只要在服务器发回数据的页面加上一个定义编码的文件头即可。
  定义文件头信息的时候根据脚本的不同，可以使用以下方式：
  PHP:header("Content-Type:text/html;charset=GB2312"); 
  ASP:Response.Charset("GB2312")
  JSP:response.setHeader("Charset","GB2312");
  （其它脚本可以查找其相关类库，通常都有设置header信息的函数或方法。）
  说完了发回信息，我们在说一下发送信息乱码的问题。其实不关是怎样的编码，我们输入的中文字符都会被正确的以UTF-8格式发送到服务器端，只是在服务器接收的时候没有按照我们预期的方式去解码，而是使用了服务器默认的字符编码方式，通常是GB2312来解码信息。那我们看到的字符自然就是错误的。
  我们都知道，XMLHTTP有两种发送数据的方式，一种是GET，一种是POST。GET的乱码解决起来比较简单。只要加上一个定义编码的Header信息即可：setrequestheader("Content-Type","text/html; encoding=gb2312")。这样GET方式发送出去的数据会被服务器脚本正确的理解为GB2312方式，从而进行解码。
  比较难的部分是使用POST方法发送数据的时候，上面的方法就失效了，因为POST数据使用的Content-type使用的是：xmlObj.setrequestheader("Content-Type","application/x-www-form-urlencoded");没有定义字符编码的地方。我在这个问题的解决上遇到了很大的困难，但是目前已经找到两种比较好的解决方法。首先是将中文字符在发送到服务器端之前进行URL编码。也就是使用：encodeURI()。
  但要注意的是，这个方法要用两次，第一次是将字符加工成URL编码。第二次是将编码后的数据再次编码。这样做是因为，第一次编码如果发送的话，服务器端会自动对其进行解码，如果这样那我们就没有办法来控制我们希望的解码方式了。所以要进行两次encodeURL。这样做的目的在于，我们在服务器端获得的数据是一个被encodeURL后的字符串。然后我们再用服务器端脚本的相应解码函数来还原字符串，如此一来，我们就得到了一个我们希望得到的正确的字符串了。这样做的坏处是，我们不得不成倍的增加Send出去的数据量。要知道，数据量变大，出错的机会也就随之变大。
  还有一种方式是使用cookies转储数据，这样虽然不会增加数据但是对于浏览器权限有一定要求。虽然读写cookie是很容易得事情。但我觉得这样操作并不理想。在我没有进行试验的情况下我也不好多说什么。而我认为，应该还有第三种方法可以解决乱码的问题。

  AJAX POST 乱码在 PHP 中的解决方法！
  虽然不高级，也不帅，但最终还是解决了问题。而问题的解决，正式因为PHP完善的函数库！只是一个 iconv() 函数就解决了乱码的问题！
  在客户端，不需要任何的设置。只要将正常的值获取并使用xmlHTTP Send到服务器端，然后在服务器端正常接受值。在接收到值之后使用iconv()函数将字符串重新编码一下就好了！
$R_Guest = strval(iconv("UTF-8","GB2312",$_POST["R_Guest"]));
$R_Content = strval(iconv("UTF-8","GB2312",$_POST["R_Content"]));

在程序初始时，遇到错误为：

PHP Parse error:  syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting T_STRING or T_VARIABLE or T_NUM_STRING in /var/www/developer/pp1/8-22.php教程 on line 5, referer: http://localhost/developer/pp1/form_input.html，在网上检查了一下，说是语法错误，检查了一下语法，发现8-22.php组后一行的echo语句有错无，应改为：

echo"产品将于三日内到达".$_GET['address']."<p>";

另外8-22.php代码为：

<?php
echo $_GET['company']."你好：<p>";
echo"感谢贵公司订购本公司的产品".$_GET['amount']."个，";
echo"货款共".($_GET['amount']*100)."元整.<p>";
echo"产品将于三日内到达$_GET['address']<p>";
?>

html代码

<form action="8-22.php" method="get">
公司名称<input type=text name=company size=20><p>
公司地址<input type=text name=address size=20><p>
订购产品数量<input type=text name=amount size=5><p>
<input type=submit value="填好了"><p>
<input type=reset value="充填">
</form>
</body>
</html>

在使用session_destroy(),进行Session变量的注销时，出现了

Warning: session_destroy() [function.session-destroy]: Trying to destroy
uninitialized session in

的错误！！经查证，在进行使用session_destroy()函数必须先调用session_start()函数。
也就是要有如下代码：
<?
session_start();
session_destroy();
?>

分析

还是经验不足啊，对session的理解不足。出现了这个错误，后来查了一下，

在调用session_destroy()之前，需要调用 session_start();

来告诉系统你当前是有session的。然后再去关闭

cookie存在客户端，跟服务器没有关系的，注意你程序里大小写问题，linux是大小写敏感的，还有php教程的配置，比如是否   register_globals   =   Off   的配置在两边都一样等等。

PHP 的 @、# 符号的意思

function foo($n)
{
    $result = 1/$n;
    return $result;
}
echo @foo(0); // 函数中会产生除 0 错误，但加上 @ 后并不显示该错误。
echo "end"; // 输出 end
# 注释符号

同 // 一样，# 是单行注释符（多行注释符为 /* */）。

由于使用了@setcookie，即便在写入cookies是发生错误，也不会输出，造成了无法发现问题。最后把@setcookie改成 setcookie，程序输出如下错误信息：

Warning: Cannot modify header information - headers already sent by (output started at

经过上网一查，发现原来在进行setcookie设置前不能有任何输出内容，然后就去检查代码，也没有发现在setcookie之前输出了东西，在搜索了一下，发现了问题所在，具体内容如下：

今天在WordPress中文论坛逛了一圈。坛子里人气不高，不过还是有很多高手的。会编写插件和模版的高手和连编辑文件都不会的初学者混在一起，论坛就是这样，哈哈。

看到好几个帖子里提到同一个错误，比如这个帖子里提到的:"Warning: Cannot modify header information - headers already sent by (output started at c:program fileseasyphp1-8wwwwp-config.php:1) in c:program fileseasyphp1-8wwwwp-login.php on line 9"

这是一个很典型的问题。WordPress的程序执行时会首先调用wp-config.php一类的配置文件，也会调用wp-db.php建立数据库教程连接以备后用。这些文件只是做一些设置，并不输出html代码。设置完了后，程序本身开始执行了，有些程序会使用header命令设置一个HTTP头。由于HTTP头必须在html代码输出之前设置好，否则html代码已经开始往客户端发送了，HTTP也就已经发送过了，没法追回来重新设置了。WordPress CodeX里对这个问题作出了说明：《How do I solve the Headers already sent warning problem?》。文章指出：要确保各个文件——尤其是经常被编辑的wp-config.php文件——以<?php开头，以?>结尾，前后不能有其他字符。具体到上面的例子，很明显，提示信息说wp-config.php的第一行就开始了html输出，这有可能是第一行的<?php部分前面被加上的其他字符，比如空格一类的。再联想到以前提到的BOM的问题，那么非常有可能是因为这位朋友使用了Windows的记事本编辑了wp-config.php文件并保存成了UTF-8编码的文档，从而因为BOM的三个字符的输出造成了header命令执行出错。

解决方法

WordPress中文论坛没有提供全文搜索的功能，只能搜索标题，所以我用Google搜索了一下Cannot modify header information site:wordpress.org.cn，好像碰到这个问题的人还真不少。目前大家用的WordPress主要是WordPress英文原版和几个WordPress中文版。我的中文包又不包含wp-config-sample.php文件，自然不关我的事；WordPress原版用的ASCII码，自然不包含BOM，也不会出这样的错误；xigang制作的WordPress中文版在WordPress中文论坛有下，我去下载了WordPress 2.0.4和2.0.3这两个，检查了一下，没有问题；点点游的WordPress 2.0.4中文版里，wp-config-sample.php文件用的是GB2312编码和DOS行尾符，GOD!不过这样也好，如果有人用记事本修改了这个文件，DOS行尾符不会造成编辑问题，GB2312编码不会造成BOM的问题

 cookie用法
关于删除cookie的说明开始-----

bool setcookie ( string name [, string value [, int expire [, string path [, string domain [, bool secure]]]]] )

要删除cookie需要确保它的失效期是在过去，才能触发浏览器的删除机制。

下面的例子说明了如何删除刚才设置的cookie：
<?php
//将过期时间设为一小时前
setcookie("TestCookie", "", time() - 3600);
setcookie("TestCookie", "", time() - 3600, "/~rasmus/", ".utoronto.ca", 1);
?>

-----关于删除cookie的说明结束-----

删除一个cookie的方法就是把这个cookie的有效期设置为当前时间以前，这也是几乎所有php程序员都会这么做。

后来一个初接触php的朋友告诉我，他在程序中本想把一个cookie的值设置为空，结果导致这个cookie直接被删除。我当时的第一反应是不相信，于是测试
了一下：
setcookie("testcookie", '');
print_r($_COOKIE);

结果果然是整个$_COOKIE数组都是空的，而非仅仅$_COOKIE['testcookie']为空。于是用winsock抓包，观察返回的http头，发现http头竟然是“Set-Cookie: testcookie=deleted; expires=Mon, 18-Jun-2007 02:42:33 GMT”，这说明“setcookie("testcookie", '');”的的确确是将testcookie这个cookie直接删除，而关于这种情况在php手册中完全没有说明。