JavaCC的词法解析被转化为一组词法状态，每个状态都有一个唯一的标识符用于命名。Token Manager(生成的代码)在运行时总是处于状态之一，默认的一个词法状态是DEFAULT。当Token Manager初始化时，默认情况下是以DEFAULT状态开始。也可以在Token Manager 构造时，指定起始词法状态¹。

上一篇文章我们简单介绍了 JavaCC的语法和使用。本文将以实现一个计算器为例，介绍JavaCC 在实际代码中的使用。

JavaCC 是 java 生态中常用的Parser Generator。特征如下:

• JavaCC 生成的解析器是基于LL 的，默认是LL(1)，通过配置可以支持 LL(K)。
• 由于是LL 方式，需要用户自己书写递归下降的语法规则来避免出现左递归问题。
• JavaCC 支持 EBNF 语法范式。

JavaCC的工作流程如下:

• 令牌管理器读入一个字符序列并生成一个称为令牌的对象序列。用于将字符序列分解为标记序列的规则取决于语言-它们由用户作为正则表达式的集合提供。
• 解析器使用一个令牌序列，分析它的结构，并产生一个由用户定义的输出。

最近在做SQL方面的工作，主要是SQL语法解析和改写。因此打算记录下解析的技术&工具。

文本解析一般首推使用正则表达式。对于大多数的文本，正则都可以很好的解析。以ELK套件中的Logstash为例，其内置的Grok插件支持了120+种常用Pattern，可以很好的用于解析多种形式的文本。但是。正则不是文本解析的万能钥匙，由于正则表达式的自身实现约束，大多数正则表达式引擎不能较好的处理嵌套结构的数据。此外，对于脚本语言或编程语言，正则表达式也是无能为力。

举个例子，如果想替换SQL中的某个字段名，如果只是简单的使用正则替换，那么很可能会错误修改其他位置的文本。例如想修改下面SQL中的order_cnt别名时，就很有可能错误修改其他位置的order_cnt，要避免这类问题需要对正则添加很多断言和约束，由于实际场景中可能会对SQL的列名，表名，条件等各个位置进行改写，场景十分复杂。所以正则这种方式不能从根本上解决问题。由此，引出了接下来要介绍的技术–语法解析器(Parser)。

select 
  dt,
  sum(order_cnt) as order_cnt
  from(
   select order_cnt
   from order_info
   where dt between xxx and xxx
  )group by dt

在前面的编译原理-词法分析一文中，我们介绍了基于正则表达式方式构建NFA和DFA进行词法分析的方案。本文将基于该方案，扩展一些功能，实现一个正则表达式执行引擎JRegex - alpha版本。

解析是编译器将一系列标记转换为树表示的过程：

                            Add
                 Parser     / \
"1 + 2 * 3"    ------->   1  Mul
                              / \
                             2   3

Pratt Parser解析是手写解析最常用的技术之一。

编译器模型：

graph LR
源代码-->|词法分析器|词法单元
词法单元-->|语法分析器|语法分析树
语法分析树-->|中间代码生成器|中间代码
中间代码-->|代码优化,机器无关|中间代码
中间代码-->|代码生成器|目标代码
目标代码-->|机器相关代码优化|机器码
机器码-->output((机器码执行))

上下文无关的组成部分:

• 终结符号
• 非终结符号
• 一个开始符号
• 一组产生式

例如，下面数学表达式:

$$ expr \to expr+term $$

$$ expr \to expr-term $$

$$ expr \to term $$

$$ term \to term * factor $$

$$ term \to term/factor $$

$$ term \to factor $$

$$ factor \to (expr) $$

$$ factor \to id $$

1. 终结符号(词法单元)是组成串的基本符号，例如上面的 +,-。
2. 非终结符号是表示串的集合的语法变量,例如上面的term和factor。非终结符号表示的串集合用于定义由文法生成的语言。