大家好,欢迎来到IT知识分享网。
最近在玩Discuz! X 的dx1.5,发现没有wap版,广告一下地址 m.home118.com,结果在windows没有任何问题,上传liunx服务器就出现了如下:
Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at……
————————————————————–
很明显说明:session前头有输出了,可是前面看起来没有什么输出,后经搜索发现原因如下:
用记事本编辑后,保存为utf-8编码的代码文件最前面会有BOM信息,而BOM信息是文件开头的一串隐藏的字符,用于让某些编辑器识别这是个UTF-8编码的文件。
PHP在设计时就没有考虑BOM的问题(可能人家创始人就不爱玩windows),也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符(十六进制下查看是以EF BB BF开头)。
所以当用记事本或DW(DW编码为utf8)打开该文件时,前面什么都没有,看不到。
但是实际上有BOM信息输出,而php的session前面不允许有输出,所以报错。
术语解释:
Unicode规范中有一个BOM的概念。BOM——Byte Order Mark,就是字节序标记。在这里找到一段关于BOM的说明:
在UCS 编码中有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符,它的编码是FEFF。而FFFE在UCS中是不存在的字符,所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前,先传输字符”ZERO WIDTH NO-BREAK SPACE”。这样如果接收者收到FEFF,就表明这个字节流是Big-Endian的;如果收到FFFE,就表明这个字节流是Little- Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被称作BOM。
UTF-8不需要BOM来表明字节顺序,但可以用BOM来表明编码方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流,就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。
另外unicode网站的FAQ-BOM详细介绍了BOM。官方的自然权威,不过是英文的,看起来比较费劲。
UTF-8编码的文件中,BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话,用UE打开这个文件,切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法,软件通过BOM来识别这个文件是否是UTF-8编码,很多软件还要求读入的文件必须带BOM。可是,还是有很多软件不能识别BOM。我在研究Firefox的时候就知道,在Firefox早期的版本里,扩展是不能有BOM的,不过 Firefox 1.5以后的版本已经开始支持BOM了。现在又发现,PHP也不支持BOM。
解决方案:
1.千万别用“记事本”来另存utf-8格式;
2.用ultredit存为“utf-8无bom”格式。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/23702.html