Python re 中的贪婪匹配与非贪婪匹配

Question

请帮助我发现这是否是 Python (2.6.5) 中的错误、我编写正则表达式的能力或我对模式匹配的理解的错误。

（我接受可能的答案是“升级你的Python”。）

我正在尝试解析 Yubikey 令牌，允许可选的附加功能。

当我使用此正则表达式来匹配没有任何可选附加项的标记（即，仅包含与两个捕获组匹配的内容）时，匹配失败：

r'^\t?[^a-z0-9]?([cbdefghijklnrtuv1-8]{0,32})\t?([cbdefghijklnrtuv1-8]{32})\t?\r?\n?$'

但是，如果我使第一组非贪婪：

r'^\t?[^a-z0-9]?([cbdefghijklnrtuv1-8]{0,32}?)\t?([cbdefghijklnrtuv1-8]{32})\t?\r?\n?$'

它会成功。

所以，好吧，它有效，但我认为这两个正则表达式之间最终结果的唯一区别是性能。

Expresso 和 Regex Coach 都喜欢这两种模式。

我错过了什么？

---

这是我正在测试的两个字符串。

没有可选的附加功能（可能会失败的附加功能）：

"vvbrentlnccnhgfgrtetilbvckjcegblehfvbihrdcui"

有可选的附加功能（到目前为止还没有失败；实际的选项卡在此处显示为“_”）：

"_!_8R5Gkruvfgheufhcnhllchgrfiutujfh_"
"_!1U4Knivdgvkfthrd_brvejhudrdnbunellrjjkkccfnggbdng_"

---

我尝试使用 Alex Martelli 的建议来重现它，但它没有在原始 Python 环境中不会失败，所以我将重新审视我的代码（我实际上是在 yubikey-python 上进行黑客攻击）；大约一天后我会回来报告。

---

我向大家道歉。我无法重现该问题。当它发生时，我正在通过 getpass 读取输入；我怀疑是意外的外键敲击造成的。

我要结束这个问题了。如果投票该问题的人希望取消投票，那是公平的。

非常抱歉。

Answer 1

我建议使用 yubikey-python 来与 yubikey 进行 Python 接口 - 但是，这是一个次要的（并且严格实用的）问题；-)。

理论上，不应该存在贪婪和非贪婪之间的选择导致 RE 在一种情况下匹配而在另一种情况下失败的情况 - 它应该只影响匹配的内容（正如您提到的性能），而不是匹配是否匹配完全成功了，因为 RE 应该为此目的而回溯。

问题是，我无法重现该问题 - 我手头没有 yubikey，也没有 此文件 显示两个 RE 的匹配/不匹配行为之间没有差异。

您能否发布一些失败的示例（其中一个匹配，另一个不匹配），最好通过编辑您的问题，以便我可以重现问题并尝试将其减少到最低限度？听起来可能存在 RE 错误，但如果没有可重现的情况，我无法检查它是否以及何时被修复、已经报告或什么。谢谢！

编辑 OP现在发布了一个失败的示例，但我仍然无法重现：

$ py26
Python 2.6.5 (r265:79359, Mar 24 2010, 01:32:55) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> r1 = re.compile(r'^\t?[^a-z0-9]?([cbdefghijklnrtuv1-8]{0,32})\t?([cbdefghijklnrtuv1-8]{32})\t?\r?\n?
即，匹配在两种情况下都成功，因为它应该 - 这与OP完全相同的2.6.5 Python版本正在使用。 OP，请在您的平台上显示这个简单命令序列的结果，并准确地告诉我们该平台是什么，因为它看起来像一个奇怪的依赖于平台的错误...谢谢！
)
>>> r2 = re.compile(r'^\t?[^a-z0-9]?([cbdefghijklnrtuv1-8]{0,32}?)\t?([cbdefghijklnrtuv1-8]{32})\t?\r?\n?
即，匹配在两种情况下都成功，因为它应该 - 这与OP完全相同的2.6.5 Python版本正在使用。 OP，请在您的平台上显示这个简单命令序列的结果，并准确地告诉我们该平台是什么，因为它看起来像一个奇怪的依赖于平台的错误...谢谢！

... )
>>> nox="vvbrentlnccnhgfgrtetilbvckjcegblehfvbihrdcui"
>>> r1.match(nox)
<_sre.SRE_Match object at 0xcc458>
>>> r2.match(nox)
<_sre.SRE_Match object at 0xcc920>
>>> 

即，匹配在两种情况下都成功，因为它应该 - 这与OP完全相同的2.6.5 Python版本正在使用。 OP，请在您的平台上显示这个简单命令序列的结果，并准确地告诉我们该平台是什么，因为它看起来像一个奇怪的依赖于平台的错误...谢谢！

Answer 2

你是对的：简单地从贪婪量词切换到非贪婪量词不应导致正则表达式停止工作。它可以改变正则表达式匹配（或匹配失败）的速度、匹配的程度以及在哪些组中捕获哪些部分，仅此而已。

（以下“解决方案”不适用，但问题仍然没有表明正在执行不区分大小写的匹配，所以我将保留它。）

您的问题是带有可选附加项的字符串也有大写字母其中，您的正则表达式仅允许使用小写字母。在前面或正则表达式上粘贴 (?i) ，它就可以正常工作。