原文:
匹配连续行(续前)
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\\]|[\\.])*」,又很不幸,也无法匹配。想想为什么?