指正《精通正则表达式第3版》关于匹配连续行的错误

匹配连续行（续前）
Continuing with Continuation Lines

继续前一章中匹配连续行的例子（见178页），我们发现，在传统型NFA中使用「^\w+=.*(\\\n.*)*」并不能匹配下面的两行文本：

SRC=array.c builtin.c eval.c field.c gawkmisc.c io.c main.c\
    missing.c msg.c node.c re.c version.c

问题在于，第一个「.*」一直匹配到反斜线之后，这样「(\\\n.*)*」中的匹配反斜线的「\\」就不能按照预期匹配反斜线了。所以，本章出现的第一条经验就是：如果不需要点号匹配反斜线，就应该在正则表达式中做这样的规定，我们可以把每个点号替换成「^\n\\」（请注意，\n包含在排除性字符组中。你应该记得，原来的正则表达式的假设之一就是，点号不会匹配换行符，我们也不希望它的替代品能够匹配换行符），于是，我们得到：

「^\w+=[^\n\\]*(\\\n[^\n\\]*)*」

它确实能够匹配连续行，但因此也产生一个新的问题：这样反斜线就不能出现在一行的非结尾位置。如果需要匹配的文本中包含其他的反斜线，这个正则表达式就会出问题。现在我们假设它会包含，所以需要继续改进正则表达式。

迄今为止，我们的思路都是，“匹配一行，如果还有连续行，就继续匹配”。现在换另一种思路，这种思路我觉得通常都会奏效：集中关注在特定时刻真正容许匹配的字符。在匹配一行文本时，我们期望匹配的要么是普通（除反斜线和换行符之外）字符，要么是反斜线与其他任何字符的结合体。在点号通配模式中，「\\.」能匹配反斜线加换行符的结合体。

所以，正则表达式就变成了「^\w+=([^\n\\]|\\.)*」，在点号通配模式下，因为开头是「^」，如果需要，可能得使用增强的文本行锚点匹配模式（见112页）。

但是，这个答案仍然不够完美——我们会在下一章讲解效率问题时再次看到它（见270页）

以上内容摘自《精通正则表达式第3版》－Jeffrey E.F.Friedl 著，第186页。为了便于理解，原文做了稍微改动。

遗憾的是，我发现「^\w+=([^\n\\]|\\.)*」并不能匹配本文格式的连续行。分析如下：

「^\w+=」可以匹配字符串SRC=

「[^\n\\]」，正如作者所说，除反斜线和换行符之外的之符。「([^\n\\])*」由于*号是匹配优先的，所以它会一直匹配到array.c builtin.c eval.c field.c gawkmisc.c io.c main.c

「\\.」可以匹配 \ 及后面的回车符[CR]

目前为止一切按“计划”进行，但不幸的是，不管是否采用“单行模式”，这个正则无法继续往下匹配了。

因为回车符后面的换行符无法被该表达式匹配：由于[^\n\\]排除了换行符，所以无法匹配；而「\\.」首先需要匹配反斜线，也无法匹配换行符。因此匹配结束。

后续：

导致这个表达式无法匹配，原因在于「\\.」无法匹配换行符，那么只需要将这个表达式换成“或”的形式就可以了。“或的关系且匹配一个字符”让我们想到的是字符组。那么表达式改为：

「^\w+=([^\n\\]|[\\.])*」，又很不幸，也无法匹配。想想为什么？