摘要：解析器的工作通常分為兩個內容詞法分析器有時稱為標記生成器負責把輸入分解為很多符號，解析器負責根據該語言的語法規則來分析文檔結構，從而構建解析樹。解析器通常會向詞法分析器詢問是否有新的符號，并且試圖通過一條語法規則的來進行匹配。

1. 介紹

1.1 本文涉及到的瀏覽器

1.2 瀏覽器的主要功能

1.3 瀏覽器的主要結構

1.4 組件之前的通信

2. 渲染引擎

2.1 渲染引擎

2.2 主要的流程

2.3 流程示例

2.4 解析以及DOM樹的結構

2.5 渲染樹(Render tree)的結構

2.6 布局

2.7 繪制（Painting）

2.8 動態改變

2.9 渲染引擎的線程

2.10 css2 虛擬模型

2.11 資源

瀏覽器可謂是使用最廣泛的軟件. 這篇文章我將要解釋瀏覽器在底層是如何工作的. 我們將會了解當你在瀏覽器地址欄里輸入"google.com"直到頁面呈現出來這一過程都發生了什么。

目前市面上主要有5款瀏覽器： Internet Explorer, Firefox, Safari, Chrome 以及 Opera。
我將使用開源的瀏覽器中進行舉例，包含Firefox, Chrome 以及 部分開源的Fafari。
根據W3C browser statistics, 當前時間是2009年10月，使用Firefox, Safari 以及 Chrome 的比例占據將近60%。
所以目前開源瀏覽器占據的瀏覽器市場很大的份額。

瀏覽器的主要功能是把你從服務器請求到的網絡資源呈現在瀏覽器窗口上。資源通常包含了HTML，PDF， 圖片等等。資源通常是由用戶指定的URI(Unifor resource Identifier 統一資源定位符)來定位的。稍后的章節會介紹。

瀏覽器解釋和呈現HTML文件的方式是通過HTML和CSS規范來實現的。 這些規范是由W3C組織進行維護的，該組織是互聯網的標準制定者。長久以來各個瀏覽器廠商只實現了一部分規范，并且開發自己的擴展程序。這導致了在不同的瀏覽器當中很嚴重的兼容性問題。到目前為止，大部分的瀏覽器都大多實現了規范。
不同的瀏覽器UI有很多相同的部分:

輸入URI的地址欄

前進和后退按鈕

書簽操作

操作當前加載文檔的刷新和停止按鈕

返回主頁的主頁按鈕

但是比較奇怪的是， 瀏覽器的UI并沒有一個通用的規范，它只是不同的瀏覽器廠商從長期的使用習慣中積累的經驗。HTML5規范并沒有規定瀏覽器的UI必須包含哪些元素，只是列出了一些通用的元素。地址欄、狀態欄、工具欄以及各個瀏覽器指定的特定，例如Firefox的下載管理。更多參見用戶界面章節。

瀏覽器的主要組成部分:

用戶界面(The user interface) - 包含地址欄、前進/后退按鈕、書簽等等。除了主要的窗口之外你所看到的就是請求的頁面。

瀏覽器引擎 - 查詢和操作渲染引擎的入口。

渲染引擎 - 負責呈現請求內容。例如請求內容是HTML, 渲染引擎負責解析HTML以及CSS，并且渲染解析后的內容到屏幕上。

網絡鏈接 - 處理形如HTTP的網絡請求。它有針對不同平臺的實現接口。

用戶界面的后臺處理程序(UI Backend) - 用于繪制類似于 bombo 盒子的小部件以及一些窗口。它拋出了各個平臺通用的接口。它的底層是
使用了操作系統的用戶界面方法。

Javascript 解釋器。 用于解析和執行Javascrip代碼。

數據存儲。 這是一個持久層。瀏覽器需要在硬盤上保存各種各樣的數據，比如coocies。HTNL5規范定義了"web database",針對瀏覽器的完整的數據庫（盡管比較輕量）

Figure 1: Browser main components.

值得注意的是，Chrome不像其他的瀏覽器， 它給每一個tab分配一個渲染引擎的實例，每一個tab都是一個獨立的進程。

Firefox 和 Chrome 都獨自開發了一套特別的通信機制。

渲染引擎的職責就是進行渲染， 也就是負責把請求到的內容呈現在瀏覽器屏幕上。

在默認情況下，渲染引擎能夠展示HTML，XML以及image文檔。也能通過插件來展示其他類型的文檔。例如通過PDF視圖插件可以展示PDF。我們將會在特定的章節討論插件和擴展程序。本章節主要著重于主要的情況-如何展示由css格式化的HTML和images。

我們參考的Firefox,Chrome,Safari瀏覽器都是基于兩個渲染引擎建立的。 Firefox 使用 Gecko, 一個Mozilla自己開發的引擎。Safari 和 Chrome 都是使用的Webkit引擎。Webkit 引擎最開始是用于linux平臺的開源引擎。后續被修改用于支持Apple的Mac以及 Windows系統。 詳情移步http://webkit.org/

渲染引擎將會從網絡層請求到內容開始進行工作。這通常的大小在8k以內。

在這之后，以下就是渲染引擎基本的流程：

Figure 2: Render engine basic flow.  

解析HTML， 生成DOM tree -> 渲染render tree結構 -> 組織render tree 的布局 -> 在窗口繪制 render tree

渲染引擎會解析HTML文檔，把HTML文檔解析為“內容樹(content tree)”， 并把HTML標簽轉換為樹中的DOM節點。渲染引擎還要解析樣式文件，包含外鏈樣式文件以及內聯樣式元素。樣式信息和HTML當中可視化的指令將會用于創建另外一個樹 - 渲染樹 （render tree）。

渲染樹包含了具有顏色以及尺寸等可視化屬性的矩形盒子集合。這些矩形盒子都是按照在屏幕上的顯示順序排序的。

在構造晚渲染樹之后，將會經過“layout”過程。意思就是給每一個節點設置在屏幕上顯示的確切坐標位置。下一個階段是繪制(painting) - 渲染樹將會通過UI的后臺處理層，每一個節點都將會被繪制。

了解渲染的過程是一個循序漸進的過程很重要。為了達到更好的用戶體驗，渲染引擎將會盡可能快的把內容展示在屏幕上。它并不會等到所有的HTML都解析完之后才去構建和布局渲染樹。當請求到一部分內容的時候，引擎將會解析和渲染這一部分內容，同時程序也將繼續解析從網絡中請求到的余下的內容。

Figure 3: Webkit main flow

Figure 4: Mozilla"s Gecko rendering engine main flow

從圖3 和圖4 中可以看到盡管Webkit 和 Gecko 使用了稍微不同的術語，但是流程是基本相同的。
Gecko 把格式化的元素形象的稱為：Frame tree（結構樹）。每一個元素都是一個框架。Webkit 使用術語：Render tree， 它由Render Object 組成。Webkit把設置元素的位置稱為layout，而 Gecko稱為Reflow。 Webkit 把連接DOM節點和視覺信息生成渲染樹稱為Attachment。另外一個較小的非語義上的差別是Gecko在HTML與DOM樹之間多了額外的一層。叫做content sink, 它是創建DOM元素的工廠。我們將會逐個了解流程的每一部分。

通常的解析

既然解析在渲染引擎內是一個非常重要的過程，我們將會深入的了解它。
文檔解析，亦即把它轉換為一種代碼可以理解和使用的結構。解析的結果通常是一個表示文檔結構的節點樹。它被稱為解析樹或者語法樹。
例如：2 + 3 - 1 的表達式解析結果為

Figure 5: 運算表達式的樹節點

文法

解析是基于創建文檔語言所遵循的語法規則。每一個你能夠解析的格式，都有一個由詞法和語法規則組成的確切的文法。它被稱為context free grammar(上下文無關的語法)。人類語言不是這樣的語言，也就是說沒法用常規的解析技術來進行解析。

解析器 - 詞法組合

解析可以被分為兩個步驟 - 詞法分析 以及 語法分析。
詞法分析是把輸入的內容分解為很多符號的一個過程。這些符號是構成語言的詞匯(構建語言有效的塊集合)。在人類的語言中，它就是某種語言在字典中的所有單詞所組成的。
語法分析就是語言語法規則的應用。
解析器的工作通常分為兩個內容：詞法分析器（有時稱為 標記生成器）負責把輸入分解為很多符號，解析器負責根據該語言的語法規則來分析文檔結構，從而構建解析樹。詞法分析器知道如何區分和解釋特殊的字符，例如空格和換行符。

Figure 6: from source document to parse trees

解析的過程是迭代式的。解析器通常會向詞法分析器詢問是否有新的符號，并且試圖通過一條語法規則的來進行匹配。如果符合某條語法規則，該符號對應的節點將會被添加到解析樹，緊接著解析器會詢問另外一個符號就行解析。
如果沒有規則匹配，解析器會在內部存儲這個符號，并繼續詢問下一個符號直到某條規則匹配所有的內部存儲的符號。如果沒有找到對應的規則，解析器就回拋出一個異常。這意味著這個文檔無效，并且包含語法錯誤。

翻譯

通常解析樹并不是最終的結果。解析結果通常被翻譯-把文檔翻譯為另外一種格式。一個例子就是匯編。編譯器會把源碼編譯為機器碼，首先會把源碼解析為解析樹，然后再把解析樹翻譯為機器碼文檔。

Figure 7: compilation flow

解析實例

在圖5中，我們從一個數學表達式中創建了一個解析樹。 讓我們來定義一個簡單的數學語言來了解解析過程。

詞匯： 我們的語言包含整數，加法符號，減法符號

語法：

1. 構成語法的元素包含表達式，運算項，運算符。  
2. 我們的語言能夠包含任意數量的表達式。  
3. 一個表達式定義為： 一個運算項 跟著一個 操作符，再跟著另外一個運算項。  
4. 操作符為加號或者減號  
5. 運算項為一個整數或者一個表達式。

分析下："2 + 3 - 1"。
根據上面第5條規則，第一個匹配規則的子串是"2"。第二個匹配的的結果是"2 + 3"，它對應第二條規則。下一個匹配的結果已經到了該輸入項的結尾。我們已經知道了形如?2 + 3?表示一個完整項，那么 "2 + 3 + 1"就是一個表達式。"2 + +" 是一個無效的輸入，因為沒有匹配任何規則。

正式的定義詞匯和語法

詞匯通常都通過常規的表達式來表示。
例如我們將會像下面這樣來定義我們的語言：
INTER :0|1-9*
PLUS : +
MINUS : -
如你所見，整數是通過常規的表達式來表達的。
語法是遵循BNF（Backus Naur form）.html)來定義的。我們的語言將會做如下的定義:
expression := term operation tem
operation := PLUS | MINUS
term := INTEGER | expression

我們之前說過，如果程序的語法是一個上下文無關的語法，就可以使用通常的解析器進行解析。上下文無關的語法，最直觀的定義就是可以完全使用BNF來表示?？梢詤⒁奾ttp://en.wikipedia.org/wiki/Context-free_grammar

解析器類型

解析器有兩種類型： 自上而下 和 自下而上 的解析器。 自上而下的解析器是從語法層級比較高的地方著手進行匹配解析。自下而上的解析方式是從輸入開始，逐級向上翻譯為對應的語法規則，直到語法層級較高的規則為止。

讓我們結合實例來看看這兩種解析方式：

自上而下的解析將會從層級比較高的規則開始： 它將把 2 + 3 定義為一個表達式。然后再把 2 + 3 -1 定義為一個表達式。
自下而上的解析將會掃描整個輸入的字符串，如果有符合的規則， 則會根據規則替換匹配項，直到替換玩整個輸入。匹配的表達式將會存儲在解析器棧里。

自下而上的解析方式又稱之為移動減少解析器（shift reduce parser），因為輸入是從左向右移動的，并且根據規則匹配主鍵減少。

自動生成解析器

可以通過工具生成解析器，被稱之為解析器生成器。 你只需要提供語言的詞匯以及語法規則，它就能夠生成一個可用的解析器。創建一個解析器徐傲對解析有深入的理解。不太容易手動創建一個解析器，所有解析器生成器會比較有用。

Webkit 使用兩個比較出名的解析器生成器： Flex 用于創建詞法分析器， Bison用于創建解析器（你可以使用Lex 和 Yacc來運行）。Flex的輸入是包含通常的表達式定義的一個文件。Bison 的輸入是BNF格式的語法規則。

HTML 解析器

HTML解析器的職責是把HTML標記轉換為解析樹。

HTML 語法定義

HTML的詞匯和語法在w3c創建的規范里定義。

非上下文無關的程序語言

在解析一節的介紹里，我們知道程序語法可以通過BNF格式進行定義。
但是不幸的是，所有常規的解析器都不適用于HTML。HTML不能夠被輕易的定義為解析器需要的上下文無關的程序語法。
有一個定義HTML的通用格式-DTD（Document Type Definition), 不過并不是上下文無關的語法。
一眼看上去， HTML與XML非常的接近。 有很多的XML解析器。有一個HTML的XML變體-XXHTML。這二者有什么不用呢？
不同之處在于HTML的目的在于非嚴謹的，它允許忽略你某些標簽，并隱式的添加上，例如有時候允許忽略開始或者結束標簽。不同于XML語法的嚴格和硬性要求，HTML整體上都是比較寬泛的。
一方面這也是HTML如此瀏覽的一個原因，允許你犯錯，讓web開發更容易。另一方面，它導致很難定義一個語法格式。總結起來說， HTML比較難解析，由于并不是一個上下文無關的編程語法，它不能夠被普通的解析器解析， 也不能被XML解析器解析。

HTML DTD

HTML是通過DTD來定義的。 這個格式用于定義SGML(Standard Generalized Markup Language)語言。 它定義了所有允許的元素，屬性以及層級。正如我們之前所說的， HTML DTD 不能形成上下文無關的語言。
DTD有一些變動，嚴格模式嚴格符合規范，其他的模式支持歷史版本的瀏覽器。 目的也是為了兼容老版本的瀏覽器。 最新的嚴格DTD地址：http://www.w3.org/TR/html4/strict.dtd

DOM

解析樹是由DOM元素以及屬性節點組成的。 DOM是Document Objectd Model 的簡稱。 它是HTML文檔的對象形式以及其他外部語言(形如Javascript)的接口。樹的根節點是 Document 對象。

DOM與標簽之前有著一對一的對應關系。 例如：

    
        
            

                Hello World
            
            
 
        
      

將會被翻譯為以下的DOM樹：

Figure 8: DOM tree of the example markup  

跟HTML一樣， DOM也是被w3c組織定義和管理的。詳見http://www.w3.org/DOM/DOMTR。 它是操作文檔的通用規范。 一個特定的模塊描述了HTML特定的元素。 HTML定義可以參見http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html。

當我說樹包含了DOM節點， 意即樹是由實現了DOM接口的元素構建的。 不同的瀏覽器使用了具體的實現，這些實現包含了瀏覽器內部使用的其他屬性。

解析算法

在前幾節中，我們知道， HTML不能夠通過自上而下或者自下而上的解析器解析。
原因如下：

1. 語言的非嚴謹性。  
2. 瀏覽器具有傳統的容錯機制，用于支持很好的辨別無效的HTML。  
3. 解析進程的反復迭代機制。 在解析的過程中，解析源通常都不會被改變， 但是在HTML中， script標簽包含了document.write， 可以添    加額外的元素，所以解析過程中修改了原始輸入。  

由于不能夠使用通常的解析器就行解析， 瀏覽器為解析HTML創建了定制的解析器。
解析算法在HTML5規范中有詳細的描述。 算法由兩步構成： 符號化 和 構建樹。
符號化即詞法分析，把輸入解析為一組符號。 HTML的符號包括開始標簽， 結束標簽， 屬性名和屬性值。
標記生成器識別不同的標記， 并把它傳遞給樹構造器，緊接著識別下一個標記， 周而復始， 直到結束。

Figure 6: HTML parsing flow (taken from HTML5 spec)  

符號化的算法

算法的輸出結果是一個HTML的標簽。 算法被表示為狀態機。 每一個狀態消耗一個或者多個輸入流的字符，然后根據選中的字符跟更新下一個狀態。 當前的執行會被符號化的狀態和構建樹的狀態所影響。 這意味著， 相同的符號處理，將會產生不同的結果，根據當前的狀體來糾正下一個狀態。這個算法太復雜了， 因此不能完整的呈現出來。 所有我們通過一個簡單的實例來幫助我們理解這個原則。

基礎實例： 符號化以下的HTML：

    
        
            Hello world
        
    

初始狀態是"Data state"。當遇到"<"符號的時候 ，狀態被變更為"Tag open state"。在處理"a-z"之間的字符時會創建"Start tag token"，狀態被變更為"Tag name state"。狀態會一直保持，直到遇到">"字符。每一個字符都會被添加到新的標簽名里。在我們的事例里創建的是一個"html"標簽。

當處理到">"符號的時候，當前的標簽就回被發送出去，同時狀態會變更回"Data state"。""標簽也以同樣的方式進行處理。到目前為止，"html"和"body"標簽都被觸發。我們現在回到了"Data state"。

處理"Hello world"中的"H"字符會創建和出發一個字符標簽，直到遇到""的"<"符號為止。我們會為"Hello world"的每一個字符都觸發一個字符標簽。

現在我們回到"Tag open state"。處理"/"會創建一個"end tag token"，并且狀態變更為"Tag name state"。我們依然保留當前狀態直到遇到">"為止。之后新的標簽就回被出發，狀態返回"Data state"。""的處理方式雷同。

Figure 9: Tokenizing the example input

樹結構算法

當解析器被創建的時候，文檔對象也會被創建。在構建樹結構的過程中，文檔的DOM樹將會被修改，相應的元素將會被添加進去。標記生成器創建的每一個節點都會被樹構造器處理。規范中定義的每一個DOM元素關聯的標記都會被創建。除了把元素添加到DOM樹之外，還會被添加到"open elements"棧中。這個棧被用于糾正不匹配的嵌套以及處理未關閉的標簽。這個算法過程也被描述為一個狀態機。狀態被稱為"insertion modes"。

讓我們看看事例中構造樹的過程：

    
        
            Hello world
        
    

樹構造階段接收的輸入是從字符化階段傳入的字符序列。第一個模式是"initial mode"。當接收到html標簽的時候，會移動到"before html"模式，同時再對標簽進行處理。此時會創建一個HTMLHtmlElement元素，這個元素會被添加到文檔對象的根節點。

之后狀態將會變為"before head"。我們會接收到body標簽，此時將會隱式的創建一個HTMLHeadElementut元素并添加到DOM樹里，盡管示例中并沒有head標簽。

緊接著移動到"in head"，然后是"after head"。body標簽會被再加工，一個HTMLBodyElement將會被創建和添加到DOM樹， 模式會移動到"in body"。

接下來會接收到"Hello world"字符串。處理第一個字符的時候會創建一個"Text"節點，其他的字符會被添加到這個節點中。

當接收到body結束標簽的時候會移動到"after body"模式。此時我們會接收到html結束標簽，會移動到"after after body"模式。接收到文件結束標簽的時候將會結束解析。

Figure 10: tree construction of example html

解析之后的動作

在這一步瀏覽器將會把文檔標記為可交互的，同時開始解析在“defferred”模式下的scripts文件（在文檔解析完成之后將會被執行）。文檔的狀態將會被修改為“complete”，同時觸發一個“load”事件。

你可以在HTML5規范里查看標記化以及構建樹的完整算法。https://www.w3.org/TR/html5/syntax.html

瀏覽器的容錯

在HTML頁面里你永遠不會收到一個“語法無效”的錯誤。瀏覽器會處理無效的內容。

以下面的HTML為例：

    
        
        
        

        

        
            Really lousy HTML
        

    

我已經違反了很多規則（“mytag”不是標準的標簽，“p”和“div”標簽的錯誤嵌套等等），但是瀏覽器仍然會把內容正確的展示出來，并不會報錯。所以有很多的解析代碼來修復了HTML開發者的錯誤。

瀏覽器中的錯誤處理始終是一致的，但是讓人比較驚訝的是它并不是當前HTML規范的一部分。它就像書簽和前進后退按鈕一樣，只是多年以來在瀏覽器中開發出來的某個東西。 在很多站點中都已知很多無效的HTML結構，瀏覽器會試著已一致的方式修復它們，以順應其他瀏覽器。

HTML5規范針對這些要求做了一些定義。Webkit在HTML解析類開始的注釋中做了很好的描述：

The parser parses tokenized input into the document, building up the document tree. If the document is well-formed, parsing it is straightforward.

Unfortunately, we have to handle many HTML documents that are not well-formed, so the parser has to be tolerant about errors.

We have to take care of at least the following error conditions:

1. The element being added is explicitly forbidden inside some outer tag.
In this case we should close all tags up to the one, which forbids the element, and add it afterwards.

2. We are not allowed to add the element directly. 
It could be that the person writing the document forgot some tag in between (or that the tag in between is optional).
This could be the case with the following tags: HTML HEAD BODY TBODY TR TD LI (did I forget any?).

3. We want to add a block element inside to an inline element. Close all inline elements up to the next higher block element.

4. If this doesn"t help, close elements until we are allowed to add the element or ignore the tag.

讓我們看看Webkit的容錯示例：

 instead of 

某些站點使用
代替
。為了兼容IE和Firefox, Webkit 使用
。

代碼：

if (t->isCloseTag(brTag) && m_document->inCompatMode()) {
    reportError(MalformedBRError);
    t->beginTag = true;
}

注意： 錯誤處理是在內容，并不會呈現給用戶。

錯亂的table

錯亂偏離的table是指在另外一個table里但是卻不在table cell里的table。

就像下面的例子：

        
inner table
        
    outer table

Webkit 就會把結構修改為兩個子table

    
outer table


    
inner table

代碼：

if (m_inStrayTableContent && localName == tableTag)
    popBlock(tableTag);

Webkit 使用棧來管理當前元素內容，它會彈出內部table，再入棧到外部table的棧中。table至此就相鄰了。

嵌套的表單元素

以防用戶在form 中放置另外一個form, 第二個form將會被忽略。

if (!m_currentFormElement) {
    m_currentFormElement = new HTMLFormElement(formTag,    m_document);
}

過深的標簽層級

注釋不言而喻。

www.liceo.edu.mx is an example of a site that achieves a level of nesting of about 1500 tags, all from a bunch of s.
We will only allow at most 20 nested tags of the same type before just ignoring them all together.

bool HTMLParser::allowNestedRedundantTag(const AtomicString& tagName)
{

unsigned i = 0;
for (HTMLStackElem* curr = m_blockStack;
        i < cMaxRedundantTagDepth && curr && curr->tagName == tagName;
    curr = curr->next, i++) { }
return i != cMaxRedundantTagDepth;
}

Support for really broken html.
We never close the body tag, since some stupid web pages close it before the actual end of the doc.
Let"s rely on the end() call to close things.

if (t->tagName == htmlTag || t->tagName == bodyTag )
    return;