首頁  >  文章  >  web前端  >  HTML5標準學習-編碼詳解

HTML5標準學習-編碼詳解

黄舟
黄舟原創
2017-03-21 15:14:151582瀏覽

相信每個前端工程師都或多或少遇上過「亂碼」這位仁兄,無論你的基礎有多麼紮實,在生產的過程中都免不了偶爾和「亂碼」兄弟喝上幾杯茶吧。身為一個前端工程師,你是如何指定一個頁面的編碼的呢?你知道瀏覽器是怎麼辨識編碼的嗎?

首先,一個很簡單的例子,用遇簡的HTML頁面來看看各瀏覽器下方有什麼不同:

<!DOCTYPE html>

最簡HTML,93f0f5c25f18dab9d176bd4f6de5d30e6c04bd5ca3fcae76e30b72ad730ca86d都沒有內容,伺服器也不給予具體的編碼聲明,直接從本地打開,各個瀏覽器下查看頁面的編碼:

##IE9GB2312系統預設#Firefox3.5GBK2312系統預設字元集Firefox4.0ISO-8859-1#西歐語言,英文預設編碼GBK系統預設字元集Opera中文-自動偵測應該也是GB2312

It can be seen from the Table that each browser has different parsing for pages that do not use any means to declare encoding. Of course, in the simplest page, no matter what encoding is used (of course, the premise is a superset of ASCII), it has no impact, but it is enough to show the importance of setting the encoding correctly.

Encoding Statement

HTML4 and HTML5 each adopt a chapter to explain the encoding statement method. You can click here to view the relevant chapters of HTML4 or click here to view the relevant chapters of HTML5. chapter.

First of all, what is coding? Encoding is to specify the browser (or user agent) to use a special algorithm to parse the byte stream in a certain way to obtain the truly correct content. In the HTML standard, encodings can be represented using aliases. Encoding aliases come from the IANA definition, and only encodings that appear in this list can be recognized by browsers. Therefore, if UTF-8 is written as UTF8, the browser may completely ignore it. In addition, encoding aliases are case-insensitive.

In HTML4, there are three methods to specify the encoding of the page. According to the priority, they are:

  1. The Content-Type field in the HTTP header is followed by characters set.

  2. Use the fb0219da7bc07e28bd061c326636787c tag to declare.

  3. For some external resources, such as js files loaded by the 3f1c4e4b6b16bbbd69b2ee476dc4f83a tag, they can be declared through the charset attribute on the tag.

Of course there is no doubt about this. It should be noted that if the page is declared through the fb0219da7bc07e28bd061c326636787c tag, When the browser encounters this tag, if it finds that the encoding it uses does not match the tag declaration, it will go back to the beginning and re-parse the page. This will cause part of the page to be re-parsed, so if you are trying to use a tag to declare the encoding, it is recommended to write the tag as early as possible. A best practice is to write it after the 93f0f5c25f18dab9d176bd4f6de5d30e tag and before any other tags. Regarding this point, Google PageSpeed ​​also has a corresponding introduction.

Evolution of the Times

But as time went by, developers gradually discovered one thing. Just like the simplest statement of DOCTYPE, in fact, when the browser reads the encoding of the e8e496c15ba93d81f6ea4fe5f55a2244 tag, it does not strictly follow the standard. All in all, since in the HTML parsing stage, the encoding of the page must be determined before the Tokenizer stage, it is impossible for the browser to decompose it when the DOM tree is built like analyzing the DOM treee8e496c15ba93d81f6ea4fe5f55a2244The structure of the tag, take out the http-equiv and content attributes, and then determine the encoding.

In reality, the browser does a very simple thing to read the encoding defined by the e8e496c15ba93d81f6ea4fe5f55a2244 tag:

  1. ## Make sure this is a

    e8e496c15ba93d81f6ea4fe5f55a2244 tag. According to the status machine of HTML parsing, the "11560dcfe6332e12b3e3af69e5b2db15

  2. < ;meta charset="utf-8" />

  3. ##5c63b0c9e2aeb7f2e73596ac1dc2ffb0

  4. ...and many other weird ways of writing.
  5. So, as history progressed, finally one day, various browser manufacturers sat together and began to discuss this issue... In the end, they were surprised to find that their implementations were very similar. (Maybe they just learned from each other), so they decided to turn this method into a standard... Finally, after a long discussion, the widely loved coding declaration method in HTML5 was born. In HTML5, it is called a "meta charset element", and its simplest form is as follows:
    <meta charset=utf-8>

    当然这是HTML的语法,如果遵从XHTML并觉得XHTML更加亲切地话,写成acbc3b8881b6b4f3abaf7379ad2340e7也是没问题的。

    而前文所述的具体获取编码的算法也被详细地记录在案,可以在这里看到。

    到了HTML5时代,标准再次对编码的声明方式做了修正和细化,总得来说有以下的区别:

  • HTML5允许使用BOM来决定编码,但仅支持UTF-16的BOM(即U+FEFF),且没有说明BOM指定编码的优先级如何。

  • HTML5添加了meta charset标签。

  • HTML5规定如果一个页面没有指定编码,则使用ASCII作为其编码,而HTML4则规定浏览器可以根据所处的环境自行选择。

其他杂项

除了编码的基本声明方式外,标准中还有不少需要注意的细节:

  • 如果使用e8e496c15ba93d81f6ea4fe5f55a2244标签声明编码的话,该编码只能是ASCII的超集编码。可以简单地认为ASCII超集就是支持ASCII的256个字符的编码。

  • HTML5非常推荐使用UTF-8编码。

  • 标准中提出不要使用UTF-32、JIS_C6226-1983、JIS_X0212-1990、HZ-GB-2312、JOHAB等字符集,并禁止使用CESU-8、UTF-7、BOCU-1和SCSU字符集。但事实上浏览器却至少能识别UTF-7。

  • 对于想要严格遵守XHTML的开发者,应当使用XML声明来指定编码,即e4f551cb26a907a6bcdf652256fc4dfd。但是这个在IE6下会影响到DOCTYPE,所以开发者也不得在这一点上给予妥协,乖乖地去用HTML的声明方式。

  • 关于现实中各编码声明方式的优先级,以及一些其他需要注意的细节,这篇文章值得一读。

最佳实践

  • 尽可能使用HTTP头指定编码。

  • 尽可能使用UTF-8,或者至少全站所有资源使用统一编码。

  • 如果想使用UTF-16,就给文件加上BOM,以确定是Little Endian还是Big Endian的。

  • 如果使用e8e496c15ba93d81f6ea4fe5f55a2244标签指定编码,可以不使用http-equiv的形式,但尽可能让标签出现在前面,至少保证在任何非ASCII字符之前。

  • 链接外部的脚本,如果无法确定编码相同的话,加上charset属性。

瀏覽器 顯示編碼 備註
#IE6 UTF- 8  
IE8 #UTF-8  
字元集
#Chrome

以上是HTML5標準學習-編碼詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn