java詞法分析器DDL遞歸應用詳解
前言
最近大部分時間都在擼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所需要的模板即可。
在我動手之前我認為是非常簡單的，無非就是解析字符串，但實際上手後發現不是那麼回事；主要是有以下幾個問題：
- 如何識別出表名稱？
- 同樣的如何識別出字段名稱，同時還得關聯上該字段的類型、長度、註釋。
- 如何識別出主鍵？
總結一句話，如何通過一系列規則識別出一段字符串中的關鍵信息，這同樣也是 MySQL Server 所做的事情。
在開始真正解析 DDL 之前，先來看下一段簡單的腳本如何解析：
x = 20
按照我們平時開發的經驗，這條語句分為以下幾部分：
x表示變量=表示賦值符號20表示賦值結果
所以我們對這段腳本的解析結果應當為：
VAR x
GE =
VAL 100
這個解析過程在編譯原理中稱為”詞法解析“，可能大傢聽到編譯原理這幾個字就頭大（我也是）；對於剛才那段腳本我們可以編寫一個非常簡單的詞法解析器生成這樣的結果。
狀態遷移
再開始之前先捋一下思路，可以看到上文的結果中通過VAR表示變量、GE表示賦值符號 ”=“、VAL表示賦值結果，現在需要重點記住這三個狀態。
在依次讀取字符解析時，程序就是在這幾個狀態中來回切換，如下圖：
- 默認為初始狀態。
- 當字符為字母時進入
VAR狀態。 - 當字符為 ”=“ 符號時進入
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
以上就是java詞法分析器DDL遞歸應用詳解的詳細內容，更多關於java DDL遞歸詞法分析器的資料請關註WalkonNet其它相關文章！