原文：https://blog.csdn.net/hczhiyue/article/details/20483209
LL(k) 分析
LL 分析又称为自顶向下的分析（top-down parsing），也有叫递归下降分析（recursive-descent parsing）。也是最简单的一种分析方式。它工作的方式类似于找出一个产生式可以从哪一个终结符开始。
当分析时，从起始符号开始，比较输入中的第一个终结符和启动集，看哪一个产生式规则被使用了。当然，两个启动集之间不能拥有同一个终结符。如果有的话，就没有办法决定选择哪个产生式规则了。
LL文法通常用数字来分类，比如 LL(1)，LL(0) 等。这个数字告诉你，在一个文法规则中的任何点可以允许一次察看的终结符的最大数量。LL(0) 就不需要看任何终结符，分析器总是可以选择正确的产生式规则。它只适用于所有的非终结符都只有一个产生规则。只有一个产生规则意味着只有一个字符串。[不用看当前的终结符是什么就可以决定是哪一个产生规则，说明这个规则是为一个固定的字符串所写的。] 这种文法是没有什么意义的。
最常见也是比较有用的事 LL(1) 文法。它只需要看一个终结符，然后就可以决定使用哪一个产生规则。而 LL(2) 则可以查看两个终结符，还有 LL(k) 文法等等。对于某个固定的 k 值，也存在着根本不是 LL(k) 的文法，而且还很普遍。
下面来分析一下本章开头给出的例子。首先看下面这条规则：
D := '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
上述规则有十个产生式，每个产生式的启动集是一个数字终结符构成的集合 {'0'}、{'1'}、……、{'9'}。这是一个很好的 LL(1) 文法，因为我们只要看一个终结符，就可以选择一个正确的产生式。例如，如果看到一个终结符，其内容是 3，那么就采用上面第四个产生式，即 D := '3'。
接下来分析 DL 规则。
DL := D | D DL
上述规则有两个产生式，启动集是 {D}，{D}。很不幸，两个产生式的启动集相同。这就表示只看第一个输入中的第一个终结符不能选择正确的产生式。
然而可以通过欺骗来绕过这个问题：如果输入中第二个终结符不是一个数字，那么就选择第一个产生式，但如果两者都是数字就必须选择第二个产生式。换句话说，这意味着这是一条好的 LL(2) 文法规则。实际上这里有些东西被简化了。
再分析下 FN 规则吧。它的情况更糟糕。
FN := DL | DL '.' DL
它有两条产生式，而且启动集相同，均为 {DL}。然而这次不像 DL 规则那么幸运了。咋一看，似乎通过 LL(2) 可以分辨应该使用哪一个产生式。但是很不幸，我们无法确定在读到终结符 ('.') 之前，需要读多少个数字才算是 DL 符号的最后一个数字。[想想吧，分析器这么工作着：读入第一个终结符，一看是相同的 DL 符号，那么就读第二个终结符吧；读入第二个终结符，两者合起来一看，还是一样的 DL 符号；读入第三个终结符，前三个终结符合起来看，仍然是相同的 DL 符号。但是 DL 符号表指示数字表示没有长度限制的。]没有任何一个给定的 k 值，这都不符合 LL(k)文法，因为数字表总能突破这个 k 的长度。
最后看看启动符号规则。有点意外，它产生规则的选择很简单。
S := '-' FN | FN
它有两个产生规则，两者的启动集是 {'-'} 和{FN}。因此，如果输入中第一个终结符是'-'，那么就选择第一个产生式，否则选择第二个产生式。所以这是一个 LL(1)文法。
从上述的 LL 分析看，只有 FN 和 DL 规则引起了问题。但是不必绝望。大部分的非 LL(k) 文法都可以容易地转换为 LL(1) 文法。下面以当前的这个例子来看看如何转换有问题的 FN 和 DL。
对于 FN 符号来说，它的两个产生式都开始于 DL，但是第二个产生式其后续的是一个小数点终结符 ('.')，以及另外一个数字表。那么这很容易解决：可以将 FN 改变为一个产生式，其以 DL 开始，后跟一个 FP（fractional part）符号。而 FP 符号则定义成或者为空，或者为小数点后跟着一个数字表，如下所示：
FN := DL FP
FP := @ | '.' DL
上述 @符号表示为空。现在 FN 文法没有任何问题了，因为它现在只有一个产生式。而 FP 也不会有问题，因为它的两个产生式的启动集是不同的：前者是输入的尾端，后者是小数点终结符。
DL 符号就不是好啃的核桃了，原因在于其递归和至少需要一个 D 符号。解决方案就是，给 DL 一个产生式，由一个 D 后跟一个 DR（digit rest）构成；而 DR 则有两个产生式，一个是 D DR（表示更多的数字），一个是 @（表示没有更多的数字）。最后本章开头的例子被转换成下面的一个完全的 LL(1) 文法了：
S := '-' FN | FN
FN := DL FP
FP := @ | '.' DL
DL := D DR
DR := @ | D DR
D := '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
LR 分析
Lr 分析也叫自底向上的分析（bottom-up parsing），或者叫移进 - 归约分析（shift-reduce parsing），相比 LL 分析难度更大些。它的基本原理是，首先收集输入，直到它发现可以据此利用一个符号对收集到的输入序列进行归约。可以与数学里面解方程式时的消元法进行类比。这听起来似乎很难。下面还是以一个例子来澄清。例子中将分析字符串 3.14，看看是怎样从文法产生出来的。
S := '-' FN | FN
FN := DL | DL '.' DL
DL := D | D DL
D := '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
首先从输入中读入 3。
3
然后看看是否可以将其归约为一个符号（Symbol，即非终结符）。实际上可以归约，就是说用 D 符号的产生式可以得到当前读入的字符串（这也是成为产生式的原因）。
很快发现，从 DL 符号可以产生符号 D，于是又可以归约成 DL。（实际上还可以进一步地归约成 FN，于是这里就产生了歧义，到底应该归约成哪一个呢？这表明这个文法定义是二义性的，我们在这里就忽略这个问题，直接选择 DL 作为归约结果吧。）接着从输入中读入一个小数点，并试图进行归约：
D ==> 规约到 DL
DL ==> 读入下一个字符
DL . ==> 规约到？
但是这次的归约尝试失败了，因为没有任何符号的定义可以产生这种形式的字符串。也就是说，这种形式不能规约到任何符号。
所以接着我们读入下一个字符 1。这次可以将数字 1 归约到 D 符号。接着再读入一个字符 4。4 可以归约到 D，继续归约到 DL。这两次的读入和规约形成了 D Dl 这个序列，而这个序列可以归约到 DL。
DL . ==> 读入下一个字符 1
DL . 1 ==> 1 归约到 D
DL . D ==> 读入下一个字符 4
DL . D 4 ==> 4 归约到 D
DL . D D ==> 4 继续归约到 DL
DL . D DL ==> D DL 归约到 DL
察看文法我们可以很快地注意到，FN 能产生 DL . Dl 这种形式的序列，所以可以做一个归约。然后注意到 FN 可以从 S 符号产生，所以可以归约到 S，然后停止，整个分析结束。
DL . DL ==> 归约到 FN
FN ==> 规约到 S
S ==> 分析结束
可能你已经注意到，我们经常可以选择是否现在就做归约，还是等到读入更多的符号后再作不同的归约。移进 - 归约分析算法有很多不同的变种，按照复杂度和能力递增的顺序是：LR(0)， SLR， LALR 和 LR(1)。LR(1) 通常需要一个巨大的分析表，在实践上不具有实用性，因此 LALR 是最常使用的算法。SLR 和 LR(0) 对于大部分的程序语言来说还不够强大。