手写一个词法分析器

前言
最近大部分时间都在撸 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 以前，先来看下一段简单的脚本如何解析：

1.x =20

按照咱们平时开发的经验，这条语句分为如下几部分：

• x 表示变量

• = 表示赋值符号

• 20 表示赋值结果

因此咱们对这段脚本的解析结果应当为：

1. VAR      x

1. GE         
=

1. VAL      
100

这个解析过程在编译原理中称为”词法解析“，可能你们听到 编译原理这几个字就头大（我也是）；对于刚才那段脚本咱们能够编写一个很是简单的词法解析器生成这样的结果。

状态迁移
再开始以前先捋一下思路，能够看到上文的结果中经过 VAR 表示变量、 GE 表示赋值符号 ”=“、 VAL 表示赋值结果，如今须要重点记住这三个状态。

在依次读取字符解析时，程序就是在这几个状态中来回切换，以下图：

1. 默认为初始状态。

2. 当字符为字母时进入 VAR 状态。

3. 当字符为 ”=“ 符号时进入 GE 状态。

同理，当不知足这几个状态时候又会回到初始从而再次确认新的状态。

光看图有点抽象，直接来看核心代码：

1. public cla***esult {

1. public TokenType tokenType ;

1. public StringBuilder text =new StringBuilder();

1. }

首先定义了一个结果类，收集最终的解析结果；其中的 TokenType 就对应了图中的三种状态，简单的用枚举值来表示。

1. public enum TokenType {

1.     INIT,

1.     VAR,

1.     GE,

1.     VAL

1. }

首先对应到第一张图：初始化状态。

须要对当前解析的字符定义一个 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，保证每次递归的数据都是惟一的。

用一样的方法在解析主键时也是先将整个字符串提取出来:

1. PRIMARY KEY (`id`)

只不过是 "P" 打头 ")" 结尾。

1. } else if(value =='P'&&pStatus ==Status.BASE_INIT) {

1.     result.tokenType = DDLTokenType.P_K;

1.     result.text.append(value);

1. }

也是将整段字符串递归解析，再递归的过程当中进行状态切换 P_K--->P_K_V 最终获取到主键。

因此经过对刚才那段 DDL 解析获得的结果以下：

这样每一个字段也经过了 pid 进行了区分关联。

因此如今只须要对这个词法解析器进行封装，即可以提供一个简单的 API 来获取表中的数据了。

总结
到此整个词法解析器的所有内容都已经完成了，虽然实现的是一个小功能，但我本身花的时间可很多，其中光复习编译原理就让人头疼。

但这还只是整个编译语言知识点的冰山一角，后续还有语法、语义、中间、目标代码等一系列内容，都是一个比一个难啃。

其实我相信大多数人和我想法同样，这个东西太底层并且枯燥，真正从事这方面工做的也都是百里挑一，因此花这时间干啥呢？

因此我也决定这个弄完后就弃坑啦。

哈哈，开个玩笑，或许有生之年本身也能实现一门编程语言，当老了和儿子吹牛时也能有点资本。

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

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

你们看完记得点赞分享一键三连哦