本文探讨了一个复杂正则表达式在数字匹配中遇到的问题，特别是由于单词边界`\b`和不当的量词使用导致某些预期数字未能匹配。教程详细解释了如何通过替换`\b`结构、并引入原子组（possessive quantifiers）来防止不必要的回溯，从而优化正则表达式，确保精确匹配目标数字模式，提升正则匹配的准确性和效率。
在处理数字匹配时，正则表达式的编写需要考虑各种边界情况和上下文。我们来看一个原始的正则表达式，它旨在匹配特定格式的数字：
(?<!\d[- ]|[\d.,])\(?-?(?:(?:[1-9]\d{0,2}(?:(?:[. ]\d{3})*|\d*))|0)(?:\b|[,]\d{1,3})-?\)?(?![\d.,\/]|-[\d\/])这个表达式在处理诸如 100,00stk 和 10,45stk 时能够正确提取 100,00 和 10,45。然而，当面对 99stk 这样的输入时，它却无法匹配到 99。
问题的核心在于 (?:\b|[,]\d{1,3}) 这一部分，特别是其中的单词边界 \b。单词边界 \b 会匹配一个单词字符（字母、数字、下划线）与一个非单词字符之间的位置，或者字符串的开始/结束位置。在 99stk 的例子中，99 是数字（单词字符），紧随其后的是 s（也是单词字符）。因此，在 99 之后，\b 无法匹配，导致整个表达式在该位置匹配失败。虽然 [,]\d{1,3} 可以匹配逗号及小数部分，但对于没有小数部分且紧跟单词字符的数字（如 99stk 中的 99），\b 的存在阻碍了匹配。
为了解决上述匹配失败的问题，我们需要对正则表达式进行两项关键的修改：
移除 \b 带来的歧义： 由于 \b 在某些情况下会限制匹配，且我们主要关注的是数字后面可能跟随的逗号和小数，或者直接是数字的结束，我们可以将 (?:\b|[,]\d{1,3}) 替换为 (?:,\d{1,3})?。这意味着我们只期望匹配可选的逗号和小数部分，不再依赖于 \b 来确定数字的结束。
引入原子组（Possessive Quantifiers）防止不必要的回溯： 在正则表达式中，当存在可选的模式（如 ? 量词）时，如果后续的模式匹配失败，正则表达式引擎可能会尝试回溯（backtracking），即撤销之前的匹配尝试，并尝试其他路径。在我们的场景中，移除了 \b 后，如果紧接着的可选部分（例如 )? 匹配右括号）在负向先行断言 (?![\d.,\/]|-[\d\/]) 之前，引擎可能会为了满足整个表达式而回溯，导致不期望的匹配。
为了避免这种不必要的回溯，我们可以使用原子组（Atomic Groups）或独占量词（Possessive Quantifiers）。独占量词如 ?+ (匹配零次或一次，独占)、*+ (匹配零次或多次，独占)、++ (匹配一次或多次，独占) 等，一旦匹配成功，它们不会回溯。这意味着它们会“贪婪地”匹配尽可能多的字符，并且不会在后续匹配失败时放弃这些字符以尝试其他路径。
在本例中，我们需要确保在移除 \b 后，可选的 ? 和 )? 不会引起回溯。因此，我们将它们改为独占量词 ?+ 和 )?+。
综合以上两点，修正后的正则表达式如下：
(?<!\d[- ]|[\d.,])\(?-?(?:(?:[1-9]\d{0,2}(?:(?:[. ]\d{3})*|\d*))|0)(?:,\d{1,3})?+-?+\)?+(?![\d.,\/]|-[\d\/])让我们分析一下主要变化：
使用修正后的正则表达式，我们再次测试之前的输入：
通过这些改动，正则表达式现在能够更准确地匹配预期的数字模式，同时避免了由于单词边界和回溯机制带来的问题。
通过对正则表达式的细致分析和优化，我们可以构建出更精确、更高效的匹配模式，从而更好地处理各种文本数据。
以上就是解析复杂正则表达式中边界与回溯问题：以数字匹配为例的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
274
收藏
