本文深入探讨了使用ANTLR解析自然语言文本时，词法分析器贪婪匹配导致数字标识（如“Figure 3.A”）解析错误的问题。通过重构ANTLR语法，分离词法规则与解析规则，并利用语义谓词和规则优先级，我们展示了如何实现更精确的文本结构识别，尤其是在处理图表编号等复杂模式时。
在使用ANTLR进行语法解析时，尤其是处理非结构化的自然语言文本，常常会遇到词法分析器（lexer）的贪婪匹配行为导致预期之外的解析结果。本教程将通过一个具体案例，详细阐述这一问题的原因，并提供一套优化后的ANTLR语法设计方案，以实现对文本中特定模式（如图表编号）的精准识别。
理解ANTLR词法分析器与解析器的工作原理
ANTLR的解析过程通常分为两个阶段：词法分析（Lexing）和语法分析（Parsing）。
- 词法分析器 (Lexer)：负责将输入字符流分解成一系列有意义的“词法单元”（tokens）。例如，将"Figure"识别为FIGURE类型的token，将"123"识别为NUMBER类型的token。词法分析器遵循“最长匹配”原则：当多个词法规则可以匹配当前输入时，它会选择匹配字符数最多的那个规则。
- 语法分析器 (Parser)：接收词法分析器生成的token流，并根据语法规则构建抽象语法树（AST）。语法分析器在面对多个可行的解析路径时，会根据规则定义的顺序和语义谓词来决定。
问题的核心往往出在词法分析阶段的贪婪匹配。例如，原始语法中定义了一个LABEL_TOKEN规则，旨在识别图表编号：
LABEL_TOKEN : [0-9]+ [a-zA-Z]?
| [0-9]+ '.' [0-9]+
| [0-9]+ '.' [a-zA-Z];这个规则试图在词法层面直接识别多种复杂的编号模式。当遇到输入文本如Figure 6.Regulation时，LABEL_TOKEN会贪婪地匹配到6.R，而不是预期的6.作为一个独立的编号部分，因为6.R比6.更长。后续的egulation则被识别为另一个WORD_TOKEN。这种不精确的词法分析为后续的语法分析带来了障碍。
我们可以通过grun Text text -tokens input.txt命令来验证原始语法的词法分析结果：
[@0,0:5='Figure',<'Figure'>,1:0] [@1,6:6=' ',,1:6] [@2,7:9='6.R', ,1:7] // 错误：将'6.R'识别为LABEL_TOKEN [@3,10:18='egulation',<
