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

什麼是瀏覽器模式和文字模式？

經常使用IE開發者工具的同學，肯定見過瀏覽器模式和文字模式，對於這兩個名詞，綜合相關文件解釋如下：

瀏覽器模式（Browser Mode），用於切換IE針對該網頁的預設文字模式、對不同版本瀏覽器的條件註釋解析、決定請求頭裡userAgent的值。它在瀏覽器發出請求之前就已經確定，網站沒有辦法修改這個值。它代表的是使用者以何種瀏覽器訪問網站。IE9支援下列瀏覽器模式：

（IE9相容性模式與IE7模式的區別是：前者在UA里加上了Trident版本，後者和IE7完全一致無Trident標識；IE8中，IE9相容性模式對應為IE8相容性模式，UA裡Trident版本為4.0，其他沒變化。另，IE8中沒有IE9模式）

文字模式（Document Mode），其實就是經常說的文件模式。不同的文字模式對應不同的排版引擎，不同的JS引擎。上面提到，每一種瀏覽器模式對應一種預設的文字模式，網站還可以通過一些手段來更改文字模式，它代表的是瀏覽器以何種模式呈現頁面。IE9有下列文字模式：

（需要說明的是，IE8開始支援的渲染機制有：怪異模式（quirks mode）、完全標準模式（standards mode）和近似標準模式（almost standards mode），但開發者工具是無法選擇近似標準模式的，實際上我們一般都選擇觸發完全標準模式）

瀏覽器模式和文字模式有什麼用？

用來解決IE各版本帶來的相容性問題。根據微軟描述的IE相容性策略，在IE8+訪問一個頁面要經過這樣的流程：

一、首先，瀏覽器要確定瀏覽器模式。上面說過，瀏覽器模式是在請求傳送之前就必須確定，預設取最新（IE9為IE9標準

• 通過開發者工具選擇（可選項見上表）；
• 通過點選相容性檢視按鈕；
• 命中相容性檢視列表（微軟維護的需要採用相容性檢視的列表。IE8+預設對這個列表和區域網的網址都會採用相應的相容性模式）；

二、瀏覽器通過請求頭裡userAgent的值，告訴伺服器當前是何種瀏覽器模式；

三、伺服器可以通過下面方式改變瀏覽器文字模式：

• doctype；
• X-UA-Compatible Meta或對應的響應頭；

四、瀏覽器綜合考慮開發者工具設定、第三步伺服器返回的設定、相容性列表設定等等情況，決定頁面使用何種文字模式。這個過程有點複雜，放一張Qwrap群裡灰大提供的流程圖，可以自己點開看大圖。

（上圖是IE9選取文字模式的流程圖，這裡還有IE8版本，有一些區別）

問題終於來了！

回顧下前面的介紹，瀏覽器模式決定：1）傳送給服務端的UA；2）預設的文字模式；3）如何解析條件註釋。它在請求傳送前就已經確定，且不受服務端控制。文字模式決定：1）排版引擎；2）JS引擎。它在瀏覽器得到響應後最終確定，服務端可通過doctype或X-UA-Compatible來控制。

測試一、根據前文，如果使用者瀏覽器沒有啟用相容性檢視；沒有開啟IE開發者工具。那麼IE9的瀏覽器模式預設為IE9，預設對應的文字模式應該是IE9標準（對於IE8來說，是類似的），我們通過下列程式碼將它改到IE7標準：

<meta http-equiv="X-UA-Compatible" content="IE=7">

下面，我們分別用原生IE8、IE9測試這個頁面：

上表說明，瀏覽器傳送請求時的瀏覽器模式符合預期（根據請求頭UA），X-UA-Compatible確實會將瀏覽器文字模式改到了IE7標準（根據documentMode和JS引擎）。奇怪的是，文字模式的改變導致了瀏覽器模式的改變，因為條件註釋是由瀏覽器模式決定的。本例中，文字模式改到IE7標準，條件註釋也跟著變成IE7，意味著瀏覽器模式變到IE9/IE8相容性（從IE9的測試來看，不能是IE7，因為UA裡包含Trident）。至於IE8中JS取到的UA為什麼沒有變化，可能是bug或者理解不一致。

測試二、那如果把測試地址加到相容性列表呢？根據前文，這種情況瀏覽器模式應該是IE9/IE8相容性，對應的文字模式依然是IE7標準。測試結果如下：

上表是完全符合預期的。

測試三、如果把X-UA-Compatible改成IE=edge，繼續使用相容性模式測試呢？結論如下：

這個結論其實跟測試一是一致的：X-UA-Compatible為IE=edge，意味著文字模式會使用最新可用的版本，然而文字模式的更改，又把瀏覽器模式從IE9/IE8相容性變成IE9/IE8。IE9會按照新的瀏覽器模式來設定JS的navigator.userAgent，IE8下JS的UA不變。

測試四、那如果通過開發者工具人為設定瀏覽器模式和文字模式呢？經過測試，這樣測試都是符合預期的。例如IE9下，設定瀏覽器模式為IE8，文字模式為IE7標準，請求頭UA、JS的UA、條件註釋都表明瀏覽器模式是IE8，documentMode和JS引擎都表明文字模式是IE7標準。因為，IE開發者工具的優先順序最高，設定了這個，其他條件統統無視！

結論

IE8/9中X-UA-Compatible對文字模式的改變會導致瀏覽器模式的改變，也就是說服務端可以間接控制瀏覽器模式。這與微軟文件裡這一段描述有出入：

An important detail to remember is that Browser Mode is chosen before IE requests web content. This means that sites cannot choose a Browser Mode.

對於IE8，如果網站通過X-UA-Compatible meta/header更改文字模式為當前瀏覽器模式預設文字模式之外的值，那麼頁面將按照新的文字模式來呈現，條件註釋也按照新的文字模式對應的瀏覽器模式來解析，但是JS獲取的UA是瀏覽器模式初始狀態。這樣會導致用JS獲取UA得到的瀏覽器版本，與實際渲染的瀏覽器版本不符，這會對基於UA的瀏覽器檢測造成干擾。

對於IE9，只有一點與IE8不同：JS獲取到的是新文字模式對應的瀏覽器模式的UA。這會導致用JS獲取UA得到的瀏覽器版本，與請求頭髮送給伺服器UA裡標識的瀏覽器版本不符，這可能對統計有影響。

對於IE這種相容性方案，幾乎不可能做到理論上的完美。個人感覺還是IE9的策略影響面較小，更好一些。

PS，上述結論都是我用Windows XP的原生IE8，Windows 7的原生IE9親自測試得出來的。對於國內那些IE Shell們，實在過於奇葩，不在本文範圍內。

相關閱讀：

參考：

--EOF--

發表於 2012-02-08 20:31:18 ，並被新增「 IE 」標籤 。檢視本文 Markdown 版本 »

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