浏览器编码

       很长一段时间莫有更新了，今天收集了一些关于页面编码的文章，并咨询了业内高手，有了这篇文章，帮大家梳理一下关于浏览器编码这一块的信息。
       在页面显示的时候，有时就可能出现乱码的情况。通过之前那篇文件可以知道乱码的缘由就是其编码转换时的错误，
本来是GBK的存储方式，却用UTF-8的方式去读取，那页面不得不出现乱码了。

       W3C规范中：
      The document character set, however, does not suffice to allow user agents to correctly interpret HTML documents as they are typically exchanged -- encoded as a sequence of bytes in a file or during a  network transmission. User agents must also know the specific character encoding that was used to  transform the document character stream into a byte stream.
 
        在转换的时候，我们得明确传过来的字节流或文件的编码，而浏览器通过什么样的方式识别编码？

        Also, protocol headers, attributes, and parameters referring to character encodings share  the same name -- "charset" --and use the same values from the [IANA] registry 。
        通过协议头部，或属性或参数来指定charset

 

        当请求的时候，user agent 会提供一个accept-charset的属性发到服务端，这样服务端也就知道可以采用什么样的编码 发送回去。现在的服务器有更不错的方式，可以自己设置编码，这样的结果是编码有可能会错误，而出现乱码。服务端设置编码 是在HTTP的消息头部header中申明 Content-Type:text/html;charset=UTF-8这样的方式，而如果不设置，则浏览器就通过另外的方式去 寻找页面的编码。
 
        当http头部的charset未设置，或者字符编码不能识别的时候（比如没有在[IANA]中注册过）的时候，浏览器会解析HTML文档 当解析到<meta 标签的时候，若含有代码 

      <META http-equiv="Conten-Type"content="text/html;charset=UTF-8">

 

 

       注意：这里要注意一个地方，若http头部charset未设置，浏览器会开始去解析HTML文档，如果<meta标签之前有非ANSI字符解析为乱码，则meta标签可能就解析不到，所以如果设置其meta，请在head中尽早出现。 (这里其实还是有一个小问题没解决，浏览器在发现charset未设置的时候，然后以何种编码解析HTML文件，这个有待争议，下次 测试才知道)

 从以上可以得知：
  关于页面的编码决定顺序：
  1.如果HTTP头部申明了charset，则会使用HTTP头部的，
  2.让HTTP头部莫有使用，或charset不可识别，则会去解析meta标签的，
  3.如果meta也没有的话，则会使用自动检测，如果用户允许的话， 
  4.否则 会使用本地UI的字符编码。
  
  关于CSS文件的编码决定顺序：
  根据 CSS 2.1 规范的描述，应按照以下优先级来确定一个外部 CSS 文件的编码：
  1.HTTP 响应头中 "Content-Type" 字段的 "charset" 参数指定的编码。
  2.BOM 以及/或者 @charset 定义的编码。
  3.<link charset=""> 或其他链接机制提供的元数据（如果有的话）指定的编码。
  4.引入该 CSS 文件的 HTML 或另一个 CSS 文件（如果有的话）中已确定的编码。
  5.如果以上几步都没能确定编码，则假定其编码为 UTF-8。
   
   而JS文件的编码决定顺序应大致不差，如同页面一般，未证实。找到相关的规范或官方文档后确定
  
  所以关于页面编码建议的模式如下：  
  1，尽量将页面保存为UTF-8；
  2，要申明文档使用的编码，如果可能，对HTTP header进行设置；
  3，在外部css文件中使用@charset规则，当css中包含非ANSI的内容；
  4，避免使用BOM在用UTF-8的时候，保证HTML代码是Unicode无BOM的正规化保存；
  5，尽量避免使用转义字符。
  总结转自http://www.w3.org/International/tutorials/tutorial-char-enc/

 

 浅见，欢迎大家指正。 

 

 

浏览器识别编码有3种方式：
1、HTTP头的Content-Type
2、meta标签（有2类meta标签可以设置编码）
3、BOM

当前面这3种都不存在时，浏览器默认使用US-ASCII编码，而不是UTF-8，至少标准是这么解释的，当然浏览器可能不以标准为参考：


当使用编码时，必须时刻注意这个编码必须是在INAA中有注册的，比如UTF-8就必须写UTF-8，虽然部分浏览器识别UTF8（少一个“-”），但在另外一部分浏览器下就可能出错
另外INAA明确指出了，编码名称大小写不敏感


另外当使用meta标签指定编码，即HTTP头和BOM都不存在时，编码必须是一个ASCII编码的超集，也就楼主说的有可能会找不到meta标签的情况

另外标准不允许使用以下的编码，但问题是浏览器竟然能解析UTF-7等编码，导致一些安全问题：
UTF-32, JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB, ISO-2022系列, EBCDIC系列, CESU-8, UTF-7, BOCU-1, SCSU

最后，如果是XML型（如XHTML），需要用XML声明来指定编码，如

<?xml version="1.0" encoding="UTF-8"?>

^_^  谢谢大大的补充~
 

  关于BOM的检测，在W3C的规范文档中，BOM并没有在识别编码的范围内，查找了一下您提出的规范，原来是来源WHATWG.
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#charset
  
  看了关于规范前面的说明：
  This specification is intended to replace (be the new version of) what was previously the HTML5, HTML4, XHTML1, and DOM2 HTML specifications.
  以及关于各浏览器关于此特性的实现程度说明：
  大致都为 Lastest *** beta:  has nearly complete support for this feature,but does not yet pass all the relevent test cases; 09-10-23
  
  浏览器各版本也会有不同的实现方式。

正如你所说，BOM这东西其实在浏览器中还是以“绝对悲剧”的角色存在着，多数情况下HTML页面里有BOM的话，直接导致doctype无法识别（因为doctype的要求是前面没有除换行外的其他字符）
不过我确实对w3c的规范阅读很少，几乎都集中在看HTML5 Reference了，有所欠缺啊~