zoukankan      html  css  js  c++  java
  • UTF-8 BOM(EF BB BF)

    原标题:link标签和script标签跑到body下面,网页顶部有空白,出现“锘匡豢”乱码,UTF-8 BOM,EF BB BF

    来自:http://tunps.com/link-and-script-goes-under-body-tag

    最近在做一个简单的记账系统,用php+mysql。在要完工的时候发现了一个问题,研究了2天的时间才有了答案。

    以下是页首的裁图:

    页面的头部有空白区域。有的人可能怀疑是css的margin,padding,border没有重置为0造成的。其实不然,我已经将这几个属性重置为0。

    而且在firebug下面查看HTML代码会发现link标签和script表情跑到body下面:

    并且body标签下面和link标签之间有空行。

    我自诩的查看我的模板文件是没有任何问题的,想了很久最后实在是没辙了,跑到Stackoverflow高手云集的地方去提问

    有个人提出了是页面中存在stray text。

    You've got some stray text content inside the , before the tag. The browser sees the text and decides this means you're starting the main document body but have forgotten to include the tag.

    This is actually valid—if inadvisable—in HTML4: the end-tag and start-tag are both optional. This is how you can have just Hello! as a valid HTML document. But it's not permissible in XHTML, so if you validate your document you should get a “character data is not allowed here” error at the point the stray text occurs.

    The browser then parses the rest of the document as body content, putting the inside the body (which is not valid, but which is nonetheless commonplace). It ignores the real when that comes along because it already has a body.

    If you can't see the stray text, perhaps it's an invisible character like U+00A0 No-break space or—most likely for Chinese documents—U+3000 Ideographic space , which you may get when you press space in some input method modes. These characters won't be visible, but they're not ‘ignorable whitespace’ like a normal U+0020 Space or newline, so they trigger ‘text content’ processing and force the .

    就是说页面存在浏览器不能忽略的空白,比如U+0020活U+3000之类的。

    我的php脚本全部使用的是utf-8编码,html页面的也就是utf-8,我强制让浏览器把页面用其他编码来解析,比如GB2312,然后出现了如下图的情况:

    空白的部分出现了乱码,而且内容都是“锘匡豢”,这下子更是把我搞糊涂了。我按照SO上面bobince兄的建议,把模板页传到W3C markup validator上面去检查,得出来如下结论:

    大概意思是说,UTF-8中的BOM编码在一些编辑器或者是浏览器中支持不好,可能会出现问题。

    然后网上搜索了关于Byte Order Mark的信息:

    在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来标记文本文件的编码方式的。

    然后我用UltraEdit的16进制编辑模式查看代码,都是EF BB BF开头的,说明都是带BOM的。我手动的将所有文件转成UTF-8 without BOM。页面终于正常了。link,script标签乖乖的跑到head下面,网页顶部空白消失。oh yeah。这就是搞了2天的答案。

    最后我在网上随便下载了知名php程序的utf-8版,发现都是UTF-8 without BOM的。

    那么我们继续回头看看出现问题的现象就有答案了。“锘匡豢”在页面头部出现多次的原因是首页处理文件index.php require_once了多个类和库文件,而那些库和类文件都是用的带BOM的UTF-8,所有PHP无法识别,直接将EF BB BF输出,在charset="utf-8"的页面中是空白,在GB2312的页面中的输出的就是一个稀有汉字。不信可以查锘匡豢这几个字的GB2312代码是多少:

    UTF-8编码是变长的,1—6个字节。其中汉字编码,是3个或4个字节。而恰好EF BB BF多次出现,两个EF BB BF组成EFBB BFEF BBBF ,而EFBB BFEF BBBF就是“锘匡豢”的UTF-8编码。这也是很多网站页面顶部出现“锘”加一个方框。

    看来得找个时间恶补编码知识了。

    相关阅读:

    [1] 字节顺序标记.http://zh.wikipedia.org/zh-cn/%E4%BD%8D%E5%85%83%E7%B5%84%E9%A0%86%E5%BA%8F%E8%A8%98%E8%99%9F.2013-06-19

    [2]PHP源码编码与转换:搞定首行为空和“锘匡豢”.http://chensd.com/2011-09/php-source-convert-gbk-big5-to-utf8.html.2013-06-19

    [3]【转】PHP源码编码与转换:搞定首行为空和“锘匡豢”.http://www.cnblogs.com/fzzl/archive/2012/11/20/2780015.html.2013-06-19

  • 相关阅读:
    STM32学习之路-SysTick的应用(时间延迟)
    STM32M CUBE实现printf打印调试信息以及实现单字节接收
    iframe动态创建及释放内存
    第13周项目2-成绩处理
    1036. Boys vs Girls (25)
    CS0433: 类型“BasePage”同一时候存在于“c:WindowsMicrosoft.NETxxxxxxxxxxxxxxxx
    Java读取Excel转换成JSON字符串进而转换成Java对象
    Java对象与JSON互相转换jsonlib以及手动创建JSON对象与数组——(二)
    GSON中Java对象与JSON互相转换——(一)
    Java泛型方法与泛型类的使用------------(五)
  • 原文地址:https://www.cnblogs.com/ccdc/p/3144323.html
Copyright © 2011-2022 走看看