javaCC---可读到可编程的桥梁

是啥

简单来说，是一套词法、语法解析器。我们的java程序代码就是通过进行前置的编译处理，对合法性进行校验，并生成对应的抽象语法树（AST），然后基于此做各种编译提示和编译优化的。

作为一套通用的标准，当然可以支持扩展。既然能够支持java语法的解析，那自然能够支持sql语法的解析，只不过是配置文件不同罢了。

怎么玩

怎么玩，网上内容一大堆，这里就不详述了。

的玩法 程序目录

的核心目录core 下面有一个专门的目录存放sql词法、语法定义文件，叫.jj。

基本的sql标准，在这个文件里面已经定义的相对完善了。譬如：

定义常用的关键词，在里面叫一个token：

定义一段ddl：

同时我们也可以看到，为了兼顾扩展性，定义文件中有一些语法：

这样一来，就可以通过相关的插件，把配置文件中的实现替换到jj文件。

一些概念

首先是词法，sql语法中的关键词，譬如 、table、join、left。在jj文件中会被定义成一个个token。当然不只与此，复杂的还有比如，定义一个标识符应该由什么东西构成。jj中定义为< : (|)* >，这是一个token的嵌套，同时是一个正则表达。表示一个必须由字母开头，后接0到多个字母或数字；

然后是语法，token和token互相组合搭配，形成有语义的一段定义，这是语法。比如上文提到的 table语法的定义，下面是一个详细的示例：

可以对照一下sql的 table语法定义是怎样的。是不是几乎可以一一对齐。

产物

编译.jj，将生成一个的解析器具体实现类。其针对一段sql进行解析，最终的产出物是一个，这是针对sql ast的一个抽象结构。

比如 table 。。。就会生成一个 。

xxxx from tbl 就会生成一个 ，等等。

有兴趣的朋友可以自己再扒一扒。

接下来做点什么

一旦产出，即宣告一段符合sql词法、语法定义的文件的分析完成。

但是符合语法，却不一定符合现实状况。比如我们查询一个不在table中的字段，这在语法上没有任何问题，但是不一定能够真的执行。所以接下来还需要校验sql的合法性。

这就是下一章的作用。