UTF-8 BOM对PHP的影响

今天在用notepad++写代码时 载入一个frameset框架模版后 在页面上一直不显示该页面,查看源码后都正常。然后索性把里面东西全删掉 随便写了几个测试文字可以正常显示。

折腾了好长时间,最后偶然看见了有两个控制模版的PHP文件不一样 一个是以UTF-8无BOM编码另一个是UTF-8格式编码,试着就把那个UTF-8格式的改成了UTF-8无BOM格式了。然后保存,打开firefox,之前不显示的frameset模版居然显示了。然后又在chrome下试了试 还是不显示,然后就想到了是不是还有其他PHP文件的格式没有转成无BOM格式。查了下把所有的凡是UTF-8的都改成了UTF-8无BOM格式 保存后chrome也可以正常显示了。终于松了一口气。

之前一直对UTF-8和UTF-8无BOM这格式没太在意。所以就百度查了下他们到底有什么区别。大致如下:

UTF-8 编码的文件可以分为 no BOM 和 BOM 两种格式。

何谓BOM? "EF BB BF" 这三个字节就叫BOM,BOM的全称叫做"Byte Order Mard"。在utf-8文件中常用BOM来表明这个文件是UTF-8文件,而BOM的本意实在utf16中用来表示高低字节序列的。在字节流之前有 BOM表示采用低字节序列(低字节在前面),而utf8不用考虑字节序列,所以其实有无BOM都可以。UTF-8以字节为编码单元,没有字节序的问题。 UTF-16以两个字节为编码单元,在解释一个UTF-16文本前,首先要弄清楚每个编码单元的字节序。例如收到一个“奎”的Unicode编码是 594E,“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”,那么这是 “奎”还是“乙”?

如果文件保 存时,选择了使用 BOM,会使页面显示不正常。一般来说,php是不支持有BOM的,php文件应该保存为UTF-8无BOM类型

所以在保存 UTF8 编码PHP文件时,不要使用 BOM。

UTF-8 BOM对PHP的影响

时间: 2024-12-28 08:54:13

UTF-8 BOM对PHP的影响的相关文章

《Android Studio开发实战 从零基础到App上线》资源下载和内容勘误

http://blog.csdn.net/aqi00/article/details/72907534 http://blog.csdn.net/aqi00/article/details/73065392 版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[+] 资源下载 下面是<Android Studio开发实战 从零基础到App上线>一书用到的工具和代码资源:1.本书使用的Android Studio版本为2.2.3,因为Android官网现在不提供该版本的下载,所以博主

Android 上的 制表符(tab) —— 一个神奇的字符 (cocos2dx crash)

今天测试发现了游戏的一个问题,系统邮件,如果发了tab,在android上一打开邮件内容就会crash.而且他们很确定是tab的问题. 凭我多个月的经验(确实没多年...)来看,从来没听说在android上会因为一个tab崩溃,而且如果有这个问题,肯定会有很多人遇到,估计早就吵翻天了,搜索了一下,什么可用信息都没有. 于是写个测试工程测试了一下,分别在mac下和windows下,用文本编辑工具编辑了4个txt文档,utf有bom和无bom,内容是" tab abcd ",发现都能正常显

计算机字符编码详尽讲解

from http://www.guokr.com/blog/763017/ http://blog.csdn.net/stilling2006/article/details/4129700 下载一个文档,一打开发现是乱码,不抓狂才怪…… 你们都知道,这都是字符编码闯的祸.ASCII.ANSI.GB18030.Unicode.UTF-8.UTF-8 with BOM.UTF without BOM.UTF-16.UTF-16LE.UTF-16BE…… 一大坨的谁分得清?听说UTF-8就是Uni

ajax成功返回数据中存在多余字符的处理

ajax里有需要判断反馈的字符串是否为“ok”,在浏览器里调试,看到返回的内容明明是“ok”,但是if(“ok”==data)判断为false,用alert打印内容也是ok,但是打印长度的时候却是3. 于是把返回内容每个字符的16进制打出来 var hexCharCode = []; hexCharCode.push("0x"); for(var i = 0; i < data.length; i++) { hexCharCode.push((data.charCodeAt(i)

ecma5

介绍 这一Ecma标准建立在一些原本的技术上,最为著名的是JavaScript(网景)和JScript (微软).语言由网景的Brendan Eich发明而第一次出现在这个公司的Navigator 2.0浏览器上.它出现在所有Netscape后来的浏览器以及微软从Internet Explorer 3.0之后的所有浏览器上. 这一标准的编制自1996年十一月开始.这一Ecma标准的第一个版本被1997年六月的Ecma General Assembly采纳. 上述Ecma标准被以快速跟进流程提交至

Source Insight完美转换UTF-8 到 GB2312

前言 很多人用source insight 打开某些源码文件时,汉字显示为一堆乱码.这个问题是因为编码方式不同.记事本和一些编辑器默认编码方式是ANSI,在这种方式下输入汉字,其实就是GB系列的编码方式.不幸的是,广收欢迎的代码查看工具Source insight 虽然支持汉字,但是它不支持UTF-8.笔者感到疑惑的是,当初开发source insight的这帮人现在哪里去了?这么好的工具,却不再更新了,实在让人可惜. 可惜归可惜,程序还是要看.乱码怎么办?用记事本打开源代码逐个转换的笨方法虽然

Android 上的 制表符(tab) —— 一个奇妙的字符 (cocos2dx crash)

今天測试发现了游戏的一个问题,系统邮件,假设发了tab,在android上一打开邮件内容就会crash.并且他们非常确定是tab的问题. 凭我多个月的经验(确实没多年. . .)来看.从来没听说在android上会由于一个tab崩溃.并且假设有这个问题.肯定会有非常多人遇到,预计早就吵翻天了,搜索了一下,什么可用信息都没有. 于是写个測试project測试了一下.分别在mac下和windows下,用文本编辑工具编辑了4个txt文档.utf有bom和无bom,内容是" tab abcd "

python标准库之字符编码详解

codesc官方地址:https://docs.python.org/2/library/codecs.html 相关帮助:http://www.cnblogs.com/huxi/archive/2010/12/05/1897271.html #python标准库(英文地址:)http://www.ask3.cn/ebook/docspy3zh/library/index.html unicode入门: cpython2.xz支持2种类型字符串处理文本数据,老式的str实例使用单个8位字节表示字

遇到乱码不怕不怕啦——计算机字符编码详尽讲解

下载一个文档,一打开发现是乱码,不抓狂才怪…… 你们都知道,这都是字符编码闯的祸.ASCII.ANSI.GB18030.Unicode.UTF-8.UTF-8 with BOM.UTF without BOM.UTF-16.UTF-16LE.UTF-16BE…… 一大坨的谁分得清?听说UTF-8就是Unicode,但怎么Windows记事本里的保存选项有UTF-8和Unicode两个选项呀?!究竟各种软件是怎样判断一个文件是什么编码呢?为什么有时候又判断错误呢?让我一一道来. 世界上本没有字符编