提醒：本文最後更新於 1952 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

一年半之前我寫了一篇《關於瀏覽器模式和文字模式的困惑》，介紹了 IE8+ 特有的瀏覽器模式（Browser Mode）和文字模式（Document Mode），以及我的測試和微軟文件有出入的部分。其中有一些沒有提到的內容，本文繼續討論。

判斷真正的 IE 版本

很多 JS 框架都通過 UA 判斷 IE 的版本。對於 IE6，這種做法沒問題（ IE6 沒有瀏覽器模式的概念，也沒有其它 IE 可以把瀏覽器模式改為 IE6；IE7 雖然也沒有瀏覽器模式，但 IE8+ 可以把瀏覽器模式設定為 IE7 模式）。但是從 IE8 開始引入的瀏覽器模式會產生不同的 UA。例如，IE9 有這些：

如果僅通過 UA 中的「MSIE X.0」來判斷，會得到 IE7~9 三種不同結果。

實際上，對於 IE8+，根據 UA 字串只能確定當前是否是相容性檢視。因為相容性檢視的 UA 中，IE 版本和 Trident 版本不匹配。例如 UA 裡同時有「MSIE 7.0」和「Trident/6.0」，說明瀏覽器模式肯定是 IE10相容性

除此之外，上面 IE7 和 IE8 這兩種瀏覽器模式，UA 和跟真正的 IE7 或 IE8 沒有任何區別，根據 UA 完全沒辦法區分。甚至連 IE9 模式，我們也無法確認這是 IE9 瀏覽器的預設模式，還是 IE10 瀏覽器的 IE9 模式。

下面來看看文字模式，依然用 IE9 測試。選擇不同的文字模式，documentMode 的值也不一樣。

document.documentMode 這個 JS 屬性是 IE8 引入的，對於 IE8+ 無論選擇什麼文字模式，這個屬性都有值。而 IE6 和 IE7 下，這個屬性是 undefined。根據這一點，可以結合 UA 判斷出使用者使用的是不是真正的 IE7：UA 包含 IE7 時，如果 documentMode 等於 undefined，就一定是真正的 IE7 瀏覽器。對於 IE8+，這種方法就力不從心。例如 IE10 在瀏覽器模式為 IE8，文字模式為 IE8標準 時，與真正的 IE8 比較，無論是 UA，還是 document.documentMode，都一模一樣。

綜上，我們可以通過檢查 UA 中 Trident 版本和 IE 版本是否匹配，來判斷瀏覽器是否工作在相容性檢視模式下。結合 document.documentMode，還可以判斷出使用者是否使用真正的 IE7 瀏覽器。

JScript 引擎版本號

JScript 是 IE 的 JS 引擎，IE 提供了一系列 JS 介面來獲取它的 JScript 資訊：

我用這些介面測試了 IE6~10，發現 JScript 的版本號只與瀏覽器有關，與瀏覽器的瀏覽器模式或文件模式無關。

忽略內部版本號，只關注前兩個數字，我們會發現，從 IE9 把 JS 引擎換成 Chakra 開始，版本號的規律變了。令人欣慰的是，不同的 JScript 版本號對應著不同版本的瀏覽器，這對判斷出真正的 IE 版本很有幫助。例如，要識別低於 IE8 的瀏覽器，下面這樣寫就可以了。

if(ScriptEngineMinorVersion() != 0 && ScriptEngineMinorVersion() < 8) {
    //這是 IE8-
}

實際上，IE 支援的條件編譯功能中，有個表示 JScript 版本的條件編譯變數，如下（完整的條件編譯變數清單見這裡.aspx)）：

<script type="text/javascript">
    /*@cc_on
        alert(@_jscript_version);
    @*/
</script>

這個變數是「major.minor」格式的 JScript 版本號，跟使用 JS 介面獲取到的版本號一致，也只取決於瀏覽器版本，不受瀏覽器模式和文字模式的影響。

文字模式對 JScript 沒影響？

看完上一節，再看我之前寫的這段：文字模式決定：1）排版引擎；2）JS引擎，有明顯的矛盾。難道之前的結論有誤？

實際上，JS 獲取到的 JScript 版本號僅僅表示了當前瀏覽器自帶的 JScript 引擎版本（例如 IE9 始終是 9.0，IE7 始終是 5.7），並不代表任何情況都可以使用這個版本 JS 引擎的所有功能，頁面使用哪種版本的 JScript 引擎還是由頁面的文字模式來決定。

例如，IE8 的 JScript 版本是 5.8，但是隻有在文字模式等於 IE8標準 時才可以使用 JScript5.8 的功能，其它任何文字模式都會導致頁面使用 JScript5.7。

舉個例子，JScript5.8 增加了對 JSON 的支援，所以 IE8 支援原生 JSON 物件。但網上很多人問為什麼在 IE8/9 下無法使用原生 JSON。一種可能是頁面沒寫 DTD，導致頁面進入了 IE5怪異 這種文字模式，進而啟用了不支援原生 JSON 的 JScript5.7 導致的。

再舉幾個例子：[,].length 在 JScript9.0 之前是 2；[1,2,3].join(undefined) 在 JScript5.8 之前是"1undefined2undefined3"。把 IE9 的文字模式分別改成 IE9標準、IE8標準 和 IE7標準，可以得到下表：

類似的例子還有很多。大部分情況下，頁面使用的 JScript 引擎版本會隨著文字模式的降低而退化，頁面對 JS 的支援度也隨之退化。但教主 franky 提供了一個「for in順序」的反例：

var o = {1 : '0', 0 : '1'}; for(var i in o) { console.log(i); }

對於 IE9+ 瀏覽器，這行程式碼輸出順序始終是 0 1；對於 IE9 以下的瀏覽器，輸出順序都是 1 0，並不受文字模式的影響。關於這一點我沒想到比較好的解釋。

一些 DOM 相關的方法，如 document.querySelectorAll，在文字模式為 IE7標準、IE5怪異 時不可用；addEventListener 在文字模式為 IE8標準、IE7標準、IE5怪異 時不可用。這說明 IE 瀏覽器對 DOM 的支援度也會隨著文字模式的降低而退化。

但是一些 BOM 方法，卻跟文字模式無關。例如 IE8 開始支援的 postMessage 和 localStorage，只要瀏覽器是 IE8+，無論什麼文字模式，這兩個功能都可用。IE9+ 支援的 window.performance，在 IE9+ 瀏覽器上，也始終可用，跟當前的文字模式無關。

小結下：隨著文字模式的降低，頁面上實際使用的 JScript 引擎會退化，一些高版本支援的語言特性不再可用（如 JSON），但 for in 的順序問題似乎不會退化；DOM 相關功能也有相應的退化；但大部分 BOM 介面卻不會退化（如 localStorage）。

總結

本文討論的內容在各部分都小結過，最後只說一個結論：在解決 JS 相容性問題時，一定要使用能力檢測和特性檢測。因為無論是從 UA 中得到的瀏覽器資訊，還是從 JS 介面中獲取到的 JScript 引擎版本，都非常不可靠。例如 UA 中包含 IE7，並不一定不支援 IE9+ 的 window.performace。也可能是 IE9 瀏覽器使用了 IE9相容性檢視，UA 確實會變成 IE7，文字模式為 IE7標準，但不影響對 window.performace 的支援。

另外，雖然 IE 的瀏覽器模式和文字模式非常複雜，組合起來有幾十種情況，但大部分情況只能通過開發者工具來構造。例如 UA 中包含 IE9，實際上使用 JScript5.7 的情況（瀏覽器模式為 IE9，文字模式為 IE7標準），正常情況下不會出現。

參考：

--EOF--

發表於 2013-09-07 02:50:37 ，並被新增「 IE 」標籤 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 1952 天前，文中所描述的資訊可能已發生改變，請謹慎使用。