PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE

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

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>

首先是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里配置。

 

在使用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手册中完全没有说明。

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

今天文件上传出现Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to move

 

<form action="" enctype="multipart/form-data" method="post">
<tr>
  <td width="150" height="30" align="right" valign="middle">请选择上传文件</td>
  <td width="250"><input type="file" name="fileup" /></td>
  <td width="100"><input type="submit" name="submit" value="上传" /></td>
</tr>
</form>
<?php教程
if(!empty($_FILES[fileup][name])){
    $fileinfo=$_FILES[fileup];
        $type=strstr($fileinfo['name'],".");
        if($type!=".jpg"){
          echo "您上传的文件格式不正确！";
        }else{
          if($fileinfo['size']<209715 && $fileinfo['size']>0){
             $path="10/".$_FILES["fileup"]["name"];
                 move_uploaded_file($fileinfo['tmp_name'],$path);
                 if(is_dir("10/")){
                   $dir=scandir("10/");
                   foreach($dir as $value){
                     echo $value."<br/>";
                   }
                 }else{
                    echo "目录路径出错！";
                 }
          }else{
          echo '文件大小不符合要求！';
          }
        }
}
?>

运行结果：
Warning: move_uploaded_file(10/02.jpg) [function.move-uploaded-file]: failed to open stream: No such file or directory in E:apps教程erv-win32-2.5.10AppServwww10index_7.php on line 26

Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to move 'C:WINDOWStempphp1A.tmp' to '10/02.jpg' in E:appserv-win32-2.5.10AppServwww10index_7.php on line 26
目录路径出错！

解决办法,把相对路径改绝对

$_SERVER[DOCUMENT_ROOT] . '/10/' . $_FILES['fileup']['name'];

解决办法
将
move_uploaded_file($_FILES["file"]["tmp_name"],"upload/" . $_FILES["file"]["name"])
改为
move_uploaded_file($_FILES["file"]["tmp_name"],"d:/" . $_FILES["file"]["name"])

方法二

Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to move
上传的时候出现类似这种报错，原因是目录权限是否为可写的问题。
一般设置777就可以解决。、
修改权限命令：

chmod 777 filename
chmod 777 dirname
sudo chmod 777 filename/dirname
chown wangr:admin dirname -R

注：-R 批量执行