我碰到了这个有趣的案子。我不确定|操作符的优先级,所以我最初使用非捕获组来分隔管道。但是,这会导致匹配结果为“无”,删除捕获组也会导致“无”。但是,在它们周围指定一个捕获组是可行的。这对我来说很奇怪。我不太明白发生了什么事。有什么想法吗?你知道吗
而且,搜索在所有情况下都有效,正如我所料。。。你知道吗
re.match(r'^Details: WARNING|CRITICAL|ERROR', 'Details: CRITICAL asdfasdf')
None
re.match(r'^Details: (?:WARNING)|(?:CRITICAL)|(?:ERROR)', 'Details: CRITICAL asdfasdf
None
re.match(r'^Details: (?:WARNING|CRITICAL|ERROR)', 'Details: CRITICAL asdfasdf'
<_sre.SRE_Match at 0x1b27d98>
re.search(r'^Details: WARNING|CRITICAL|ERROR', 'Details: CRITICAL asdfasdf')
<_sre.SRE_Match at 0x1b27ed0>
re.search(r'^Details: (?:WARNING)|(?:CRITICAL)|(?:ERROR)', 'Details: CRITICAL asdfasdf')
<_sre.SRE_Match at 0x1b27e00>
re.search(r'^Details: (?:WARNING|CRITICAL|ERROR)', 'Details: CRITICAL asdfasdf')
<_sre.SRE_Match at 0x1b27e00>
表达式
^Details: WARNING|CRITICAL|ERROR
被解释为这三个正则表达式的交替:^Details: WARNING
CRITICAL
ERROR
因为
re.match
(不同于re.search
)要求匹配从字符串的开头开始,所以它将无法匹配Details: CRITICAL
和Details: ERROR
。你知道吗如果不需要捕获组,最好的解决方法是:
与以下任意正则表达式匹配(如果要匹配):
^Details: WARNING
^Details: CRITICAL
^Details: ERROR
尽管
re.search
在这里工作得很好,但是将re.match
与此正则表达式一起使用更有意义,因为您只在字符串的开头查找匹配项。你知道吗我相信
|
元字符的优先级只有分组结构()
(在某种程度上,我假设字符类[]
分隔符,它将它转换为文字|
字符-但是它是文字,而不是“or运算符”)。你知道吗它就像短路、“或”操作符(^ {< CD5>})、爪哇、C/C++、C语言、JavaScript等等。或visualbasic中的
OrElse
)。您还可以将文本字符之间的nothing(零空格,零字符)看作具有更高优先级的“后跟”“运算符”,但这有点像是一种延伸。你知道吗基本上,表达式
^Details: WARNING|CRITICAL|ERROR
被解释为:而表达式
^Details: (WARNING|CRITICAL|ERROR)
被解释为:而表达式
^Details: (?:WARNING|CRITICAL|ERROR)
仅被稍微不同地解释为:希望这能回答你所有的问题!你知道吗
前两种说法是:匹配“详细信息:警告”、“严重”或“错误”。你知道吗
第三个是:匹配“细节:”,后跟“警告”、“严重”或“错误”。你知道吗
搜索结果是:在字符串中查找“Details:WARNING”、“CRITICAL”或“ERROR”。你知道吗
匹配从字符串的开头开始,这就是前两个不起作用的原因;搜索扫描整个字符串。你知道吗
相关问题 更多 >
编程相关推荐