在介紹如何進行詞法分析之前，先來說說一個不怎么被提及的問題――怎么從源文件中讀取字符流。為什么這個問題這么重要呢？是因為在詞法分析中，對字符流是有要求的，它必須能夠支持回退操作（就是將多個字符放回到流中，以后會再次被讀?。?。

先來解釋下為什么需要支持回退操作，舉個簡單的例子來說，現在要對兩個模式進行匹配：

圖 1 流的回退過程

上面是一個簡單的匹配過程，僅為了展示回退過程，在后面實現 DFA 模擬器時會詳細解釋是如何匹配詞素的。

現在來看看 C# 中與輸入相關的類，有 Stream，它支持流的查找，但是只能以字節方式訪問；BinaryReader 和 TextReader 雖然支持讀取字符，但是又不能支持回退。所以，就必須自己完成這個輸入緩沖類了，大致思路就是以 TextReader 作為底層的字符輸入，然后由自己的類完成對回退能力的支持。

《編譯原理》上給出了一種緩沖區對的方法，簡單的說就是開辟兩個緩沖區，設緩沖區大小都是 N 個字符。每一次都將 N 個字符讀入到緩沖區中，并在這個緩沖區上實現字符操作。如果當前緩沖區的數據已經處理完畢，就將 N 個新字符讀入到另一個緩沖區中，接下來就換做操作新的緩沖區。

這樣的數據結構效率很高，而且只要維護合適的指針，就可以很容易的實現回退功能。不過它的緩沖區大小是固定的，新讀入的字符會覆蓋舊的字符。如果需要回退的字符數量過多（比如在分析很長的字符串時），就容易出現錯誤。我通過使用多個緩沖區解決了舊字符被覆蓋的問題――如果緩沖區不足了，就開辟新緩沖區，而不是覆蓋舊數據。

如果僅僅是不斷的添加緩沖區，那么占用的內存只會不斷增加，這樣是沒有什么意義的，因此我定義了三個釋放緩沖區的操作：Drop，Accept 和 AcceptToken。Drop 的作用是將當前位置之前的所有數據標記為無效（被拋棄），被標記無效的數據占用的緩沖區就被釋放掉，可以拿來被重復利用了；Accept 則會將標記為無效的數據以字符串形式返回，而不僅僅是簡單的拋棄；類似的，AcceptToken 是以 Token 形式返回被無效化的數據，是為了方便進行詞法分析。

這樣的數據結構比較類似于 STL 中的 deque，不過這里不需要隨機訪問和插入、刪除數據，僅會在數據的頭、尾進行操作，因此我直接將多個緩沖區使用雙向鏈表連成一個環，使用三個指針 current，first 和 last 指向鏈表中有數據的緩沖區，如下圖所示：

圖 2 多個緩沖區組成的鏈表，紅色的部分表示有數據，白色的部分沒有數據

其中，first 指向的是最早的數據緩沖區，last 指向的是最新的數據緩沖區，current 指向的是當前正在訪問的數據緩沖區，current 總是在 [first, last] 范圍之內。firstIndex 和 lastLen 之間紅色的部分，就是包含有效數據的緩沖區，idx 表示當前正在訪問的字符。白色的部分表示空緩沖區，或是緩沖區中的數據已無效。

當需要讀取下一個字符時，就從 current 中依次讀取數據，并將 idx 后移。如果 current 中的數據已經讀取完畢，則將 current 移向 last（這里用移向，是因為 current 和 last 之間可能有多個緩沖區），同時 idx 也要相應的移動。

圖 3 current 移向 last

如果需要繼續讀取字符，但是 current 中沒有新數據了，而此時 current 已經與 last 相同，表示緩沖區中已經沒有更新的數據，那么就需要從 TextReader 中讀取數據，放到新的緩沖區中，同時后移 current 和 last（需要保證 last 總是指向最新的緩沖區）。

圖 4 current 和 last 向后移

現在來看看回退操作。進行回退時，只需要將 current 向 first 的方向移動（同樣，current 和 first 之間可能有多個緩沖區）。

圖 5 回退操作

Drop 操作（Accept 和 AcceptToken 也同理）的實現也很簡單，只需要將 first 移動到 current 位置，將 firstIndex 移動到 idx 即可，這就表示 idx 之前的數據都看作無效數據。

圖 6 Drop 操作

這里需要注意的就是，Drop 操作完成后，被無效化的數據就有可能會被新數據覆蓋，因此應該確定數據不再需要時再執行 Drop 操作。Drop 操作的效率很高（移動兩個引用），基本不用擔心會影響效率。

使用這種環形數據結構的優點是除了將字符填充到緩沖區之外，完全避免了數據的額外復制，無論是前進、回退還是 Drop 操作都只有指針（引用）操作，效率很高。當 Drop 比較及時時，僅會使用兩個緩沖區，不會額外的占用內存。當占用的緩沖區過多時，還能夠實現主動釋放多余的內存（這里現在沒有考慮）。

缺點就是實現起來會復雜些，需要仔細處理好 first、current 和 last 的關系，以及 firstIndex、index 和 lastLen 范圍限制，有時還會涉及到多個緩沖區的操作。

完整的代碼可見 SourceReader.cs。

在對源代碼進行解析的時候，記錄每個 Token 對應的行號和列號顯然是很必要的工作，沒有人會喜歡面對一大堆 Error，而且還偏偏不告訴你到底是哪錯了……因此，我認為代碼定位絕對是詞法分析必備的功能，所以直接把這個功能內置到了 SourceReader 類中了。

下面來說明如何實現代碼定位。代碼定位包含三維數據：索引、行號和列號。索引是從 0 開始的字符索引，主要是方便程序進行處理；行號和列號則都是從 1 開始的，主要是為了人去看。

行定位比較簡單，Unix 的換行符是 '/n'，Windows 的換行符是 "/r/n"，所以直接統計 '/n' 的個數即可。

接下來是列定位。為了達到比較好的效果，需要考慮兩個因素：全角、半角字符和 Tab 字符。

一個中文字符（即全角字符）對應的是兩列，英文字符（半角字符）對應的則是一列，這樣在等寬字體下，每一列都是上下對齊的。在計算列數的時候，自然也應當如此，使用 Encoding.Default.GetByteCount() 而不是字符串的長度。不過這里我發現了一個內存問題（詳情參考這里），改用 Encoding.Default.GetEncoder() 的 GetByteCount 方法就可以了。

一個 Tab 字符的長度是不定的（一般是為 4 或 8，因人而異），所以定義了一個 TabSize 來表示 Tab 字符的寬度。那么，一個 Tab 字符就對應 TabSize 列么？并不是這樣的，雖然一般看來是這樣，但事實上，Tab 字符是讓下一字符對應的列總是為 TabSize 的整數倍再加 1。如果 TabSize = 4，那么它的行為如下圖所示，其中 a 和 bcc 后面都是有兩個 Tab 字符，bcccccc 和 bccccccc 后面都是有一個 Tab 字符，每個 Tab 字符我都用灰色箭頭標出來了。

圖 7 Tab 字符實例

所以，實際的列號應當使用下面的公式計算，其中 currentCol 是 Tab 字符所在的列，nextCol 就是下一字符所在的列：

nextCol = tabSize * (1 + (currentCol - 1) / tabSize) + 1;

代碼定位的計算方法有了，然后就是計算的時機。如果每次 Read 的時候都計算當前字符的位置，一是計算效率會略低，因為 GetByteCount 方法中，一次性計算較長一個字符數組的效率，差不多是多次計算長度為 1 的字符數組的一倍。二是回退的時候應該怎么辦？如果將之前的位置計算結果都保存起來，內存占用會是一個問題，如果不考慮的話，又無法根據當前字符的位置推算出前一個字符的位置（比如當前字符在第一列的話，前一個字符應該在第幾列？）。

綜合考慮之后，我決定將代碼位置的計算放到 Drop 操作（Accept 和 AcceptToken 也一樣）中，一個是向上面所說的，計算效率會略高，另一個是一般僅當識別出了一個 Token 后才需要為它定位，此時恰好是 Drop 或 AcceptToken 的時機，識別 Token 的過程中就是定位了也沒有什么用處。

我將代碼定位的功能單獨封裝到了 SourceLocator.cs 類中。

下一篇將會介紹詞法分析中用到的正則表達式，以及如何解析正則表達式。