文字分析的三種典型設計模式

許式偉2004-10-27

該模型主要有parser和handler兩個元件。其原型大體如下：

class

***handler

;class

***parser};

該模型不規定handler型別的詳細規格，由parser的實現者根據具體情況而定。

這種模型的核心思想就是由parser類來具體分析文字的格式，而讓資訊真正的處理者handler類從具體的格式中脫離出來，不再需要關心文字物理組織細節。

這種模型僅涉及乙個tokenizer元件。該元件負責將文字分解為乙個個token。其原型大體如下：

class

***tokenizer;

其中分析的結果以乙個結構體token表示。這個結構體如何設計，同樣視具體情況而定。通常它看起來是這樣的：

struct

token;};

有了tokenizer，我們就可以輕易的遍歷整個文件：

void

visit(inputsource

*source)}

你可以劃分為：

elem

//element start

attr="

value"//

attr-value pair

content

//content

elem

//element end

也可以將attr-value pair細分為三個token：attr, assign-symbol, value。

你甚至也可以將整個element作為乙個token。

從廣義上來說，我們檔案系統提供的位元組流本身已經是乙個tokenizer了，只不過它劃分的token是乙個個並無多少邏輯含義的character。

而我們後面提到的dom模型，也可以算是乙個tokenizer。只不過它劃分的token只有乙個，就是dom樹，與檔案系統的位元組流走的是另乙個極端。

tokenizer方式與parse-handler方式設計思路，最大的不同在於具體處理資訊的人主被動地位相異。在tokenizer模式下，資訊處理者呼叫tokenizer得到分析資料，如果相鄰的token存在上下文關係，你可以根據需要去取得下乙個token，故處於主動地位。

而parse-handler模式相關死板一些，一方面handler類實現者才是真正試圖處理資訊的人，但是實際上對資訊的劃分（token）卻是由parse規定的，未必完全符合handler類的需求。另一方面在token存在上下文關係，當前接受的資料資訊不足時，handler類無法隨心所欲的取得下乙個token（因為從流程上它是被動的資料接受方），而只能暫時快取資料，等待下一條資訊的到來。

dom模型是最高端的一種模型。它的思路是將文件完整地讀入記憶體，並提供資料訪問介面。

dom模型消耗的記憶體最多，可提供的服務（我們可以聯想一下xml的諸多應用，如xslt等）也最為完整。

這裡提到dom模型消耗的記憶體最多，這種說法並不全面。例如，在將它與parse-handler模型相比時，我們只是計算了parser的開銷，而handler類是客戶實現的，記憶體開銷多少，無從計算。

另一方面，由於dom模型可以按自己的方式組織資料，它在記憶體開銷上的可優化餘地很大，並且客戶在使用它時通常不再需要大量的記憶體分配操作；而parse-handler模型中，handler類的實現者出現蹩腳的設計可能性非常高，計入handler類的記憶體開銷的話，有時甚至可能遠遠超過採用dom模型。

因此我個人認為相對於dom的能力而言，記憶體問題在dom模型中並不算乙個了不起的缺陷。實現者可以有很多技巧來進行記憶體優化。

但是dom模型有乙個問題，就是它一開始就將文件完整的讀入了記憶體，使得它無法勝任那些對響應時間要求較高、希望能夠漸進處理的應用。而這一點是採用parse-handler模型和tokenizer模型的好處。

這篇文章寫得比較早，因為最近寫winx視覺化開發工具相關的設計稿時用到，所以整理了下。我個人在文字檔案和各種文件格式的檔案打交道較多，多年來也算是形成了一定的經驗。我個人現在越來越傾向於採用dom模型來處理檔案。原因在於採用dom模型有很多優點：

文字分析的三種典型設計模式

文字分析的三種典型設計模式

文字分析的三種典型設計模式

文字處理的三種典型設計模式

相關推薦