手寫一個詞法分析器

前言

最近大部分時間都在擼 Python，其中也會涉及到將數據庫錶轉換爲 Python 中 ORM 框架的 Model，但咱們並無找到一個合適的工具來作這個意義不大的」體力活「，因此每次新建表後你們都是根據本身的表結構手寫一遍 Model。

一兩張表還好，一旦 10 幾張表都要寫一遍時那痛苦只有本身知道；這時程序員的 slogan 再次印證：一切毫無心義的體力勞動終將被計算機取代。

intellij plugin

既然沒有現成的工具那就本身寫一個吧，演示效果以下：

考慮到咱們主要是用 PyCharm 開發，正好 jetbrains 也提供了 SDK 用於開發插件，因此 UI 層面能夠不用額外考慮了。

使用流程很簡單，只須要導入 DDL 語句就能夠生成 Python 所須要的 Model 代碼。

例如導入如下 DDL：

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userName` varchar(20) DEFAULT NULL COMMENT '用戶名',
  `password` varchar(100) DEFAULT NULL COMMENT '密碼',
  `roleId` int(11) DEFAULT NULL COMMENT '角色ID',
  PRIMARY KEY (`id`),  
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8

便會生成對應的 Python 代碼：

class User(db.Model):
    __tablename__ = 'user'
    id = db.Column(db.Integer, primary_key=True, autoincrement=True)
    userName = db.Column(db.String)  # 用戶名
    password = db.Column(db.String)  # 密碼
    roleId = db.Column(db.Integer)  # 角色ID

詞法解析

仔細對比源文件及目標代碼會很容易找出規律，無非就是解析出表名、字段、及字段的屬性（是否爲主鍵、類型、長度），最後再轉換爲 Python 所須要的模板便可。

在我動手以前我認爲是很是簡單的，無非就是解析字符串，但實際上手後發現不是那麼回事；主要是有如下幾個問題：

1. 如何識別出表名稱？
2. 一樣的如何識別出字段名稱，同時還得關聯上該字段的類型、長度、註釋。
3. 如何識別出主鍵？

總結一句話，如何經過一系列規則識別出一段字符串中的關鍵信息，這一樣也是 MySQL Server 所作的事情。

在開始真正解析 DDL 以前，先來看下一段簡單的腳本如何解析：

x = 20

按照咱們平時開發的經驗，這條語句分爲如下幾部分：

• x 表示變量
• = 表示賦值符號
• 20 表示賦值結果

因此咱們對這段腳本的解析結果應當爲：

VAR 	 x
GE 	    =
VAL 	 100

這個解析過程在編譯原理中稱爲」詞法解析「，可能你們聽到編譯原理這幾個字就頭大（我也是）；對於剛纔那段腳本咱們能夠編寫一個很是簡單的詞法解析器生成這樣的結果。

狀態遷移

再開始以前先捋一下思路，能夠看到上文的結果中經過 VAR 表示變量、GE 表示賦值符號 」=「、VAL 表示賦值結果，如今須要重點記住這三個狀態。

在依次讀取字符解析時，程序就是在這幾個狀態中來回切換，以下圖：

1. 默認爲初始狀態。
2. 當字符爲字母時進入 VAR 狀態。
3. 當字符爲 」=「 符號時進入 GE 狀態。

同理，當不知足這幾個狀態時候又會回到初始從而再次確認新的狀態。

光看圖有點抽象，直接來看核心代碼：

public class Result{
        public TokenType tokenType ;
        public StringBuilder text = new StringBuilder();
    }

首先定義了一個結果類，收集最終的解析結果；其中的 TokenType 就對應了圖中的三種狀態，簡單的用枚舉值來表示。

public enum TokenType {
    INIT,
    VAR,
    GE,
    VAL
}

首先對應到第一張圖：初始化狀態。

須要對當前解析的字符定義一個 TokenType：

和圖中描述的流程一致，判斷當前字符給定一個狀態便可。

接着對應到第二張圖：狀態之間的轉換。

會根據不一樣的狀態進入不一樣的 case，在不一樣的 case 中判斷是否應當跳轉到其餘狀態（進入 INIT 狀態後會從新生成狀態）。

舉個例子： x = 20:

首選會進入 VAR 狀態，接着下一個字符爲空格，天然在 38 行中從新進入初始狀態，致使再次肯定下一個字符 = 進入 GE 狀態。

當腳本爲 ab = 30:
第一個字符爲 a 也是進入 VAR 狀態，第二個字符爲 b，依然爲字母，因此進入 36 行，狀態不會改變，同時將 b 這個字符追加進來；後續步驟就和上一個例子一致了。

多說無益，建議你們本身跑一下單測就會明白：
https://github.com/crossoverJie/sqlalchemy-transfer/blob/master/src/test/java/top/crossoverjie/plugin/core/lab/TestLexerTest.java

DDL 解析

簡單的解析完成後來看看 DDL 這樣的腳本應當如何解析：

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userName` varchar(20) DEFAULT NULL COMMENT '用戶名',
  `password` varchar(100) DEFAULT NULL COMMENT '密碼',
  `roleId` int(11) DEFAULT NULL COMMENT '角色ID',
  PRIMARY KEY (`id`),  
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8

原理相似，首先仍是要看出規律（也就是語法）：

• 表名是第一行語句，同時以 CREATE TABLE 開頭。
• 每個字段的信息（名稱、類型、長度、備註）都是以 "`" 符號開頭 "," 結尾。
• 主鍵是以 PRIMART 字符串開頭的字段，以 ) 結尾。

根據咱們須要解析的數據種類，我這裏定義了這個枚舉：

而後在初始化類型時進行判斷賦值：

因爲須要解析的數據很多，因此這裏的判斷條件天然也就多了。

遞歸解析

針對於 DDL 的語法規則，咱們這裏還有須要有特殊處理的地方；好比解析具體字段信息時如何關聯起來？

舉個例子：

`userName` varchar(20) DEFAULT NULL COMMENT '用戶名',
`password` varchar(100) DEFAULT NULL COMMENT '密碼',

這裏咱們解析出來的數據得有一個映射關係：

因此咱們只能一個字段的所有信息解析完成而且關聯好以後才能解析下一個字段。

因而這裏我採用了遞歸的方式進行解析（不必定是最好的，歡迎你們提出更優的方案）。

} else if (value == '`' && pStatus == Status.BASE_INIT) {
    result.tokenType = DDLTokenType.FI;
    result.text.append(value);
}

噹噹前字符爲 」`「 符號時，將狀態置爲 "FI"(FieldInfo)，同時當解析到爲 "," 符號時便進入遞歸處理。

能夠理解爲將這一段字符串單獨提取出來處理：

`userName` varchar(20) DEFAULT NULL COMMENT '用戶名',

接着再將這段字符遞歸調用當前方法再次進行解析，這時便按照字段名稱、類型、長度、註釋的規則解析便可。

同時既然存在遞歸，還須要將子遞歸的數據關聯起來，因此我在返回結果中新增了一個 pid 的字段，這個也容易理解。

默認值爲 0，一旦遞歸後便自增 +1，保證每次遞歸的數據都是惟一的。

用一樣的方法在解析主鍵時也是先將整個字符串提取出來:

PRIMARY KEY (`id`)

只不過是 "P" 打頭 ")" 結尾。

} else if (value == 'P' && pStatus == Status.BASE_INIT) {
    result.tokenType = DDLTokenType.P_K;
    result.text.append(value);
}

也是將整段字符串遞歸解析，再遞歸的過程當中進行狀態切換 P_K ---> P_K_V 最終獲取到主鍵。

---

因此經過對剛纔那段 DDL 解析獲得的結果以下：

這樣每一個字段也經過了 pid 進行了區分關聯。

因此如今只須要對這個詞法解析器進行封裝，即可以提供一個簡單的 API 來獲取表中的數據了。

總結

到此整個詞法解析器的所有內容都已經完成了，雖然實現的是一個小功能，但我本身花的時間可很多，其中光復習編譯原理就讓人頭疼。

但這還只是整個編譯語言知識點的冰山一角，後續還有語法、語義、中間、目標代碼等一系列內容，都是一個比一個難啃。

其實我相信大多數人和我想法同樣，這個東西太底層並且枯燥，真正從事這方面工做的也都是百裏挑一，因此花這時間幹啥呢？

因此我也決定這個弄完後就棄坑啦。

---

哈哈，開個玩笑，或許有生之年本身也能實現一門編程語言，當老了和兒子吹牛時也能有點資本。

本文全部源碼及插件地址：

https://github.com/crossoverJie/sqlalchemy-transfer

你們看完記得點贊分享一鍵三連哦