Regex 有邪恶的地球仪吗？

我读过关于邪恶的RegExp，通常在处理用户输入的RegExp时确保基本的安全级别

我不确定的是，这个问题是否也存在于Glob中。我想这将归结为Glob'ing的单个实现，在我的特定实例中，我正在使用Glob'ing

对于如何测试此问题以及如何缓解此问题，我非常感谢您提供的任何建议。

所谓“邪恶的正则表达式”，我想您指的是一个遭受灾难性回溯的正则表达式

从您描述的内容来看，您似乎在使用glob库来避免这些“邪恶的正则表达式”。Globs本质上是regex的一个较弱的版本

这里缺少的一点是正则表达式不一定是邪恶的。这可以在无需外部库的纯Go中得到验证

尝试运行此Go程序：

package main

import (
    "fmt"; "regexp"
)

func main() {
    reg := regexp.MustCompile(`^([^z]*?,){11}P`)

    txt := `1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18zP`

    fmt.Println(reg.ReplaceAllString(txt, ""))
}

您可能想知道，为什么这段代码不度量执行所花费的时间。这是因为它不需要（也因为我不知道该怎么做）

regex几乎适用于所有regex口味。您可以尝试用Java、Perl或其他类似的语言运行它（我喜欢在上使用PCRE），但结果将是两件事之一：

• 暂停
• 你受够了要花多长时间，就停止这个节目

是的，在大多数正则表达式中，这种组合会导致灾难性的回溯。但是不要去。为什么?

Go的正则表达式根本不使用回溯，所以它甚至不可能。根据：

在Go中，我们找到了一个优化的正则表达式引擎。这在线性时间内运行，使复杂模式更快。它位于regexp包中

阅读更多有关回溯引擎和非回溯引擎之间的差异的信息

---

---

考虑到glob库（根据GitHub链接）比Go的regexp看起来更快，性能应该不会有问题。

你确定没有办法用难以转换为状态机的大型正则表达式攻击优化程序吗？@Bergi我不确定你在问什么。如果正则表达式的大小是可变的（通常不是），则为O（m*n），其中一个是正则表达式长度，另一个是输入长度。如果你问正则表达式编译器在编译正则表达式时是否有问题，我对此表示怀疑（这可能是Go的一个bug）。只要正则表达式有效，引擎就应该是好的。@Laurel这是个好消息，GoLang框中还有一个勾号。实际上，我使用Glob是出于用户体验的原因，这种模式需要非技术人员添加。让我把参考资料通读一遍，我会接受答案的。谢谢请确保限制全局的大小，这样你就可以了。仅供参考，如果你说的“邪恶正则表达式”指的是一个可以导致无限递归回溯的正则表达式，那么在围棋中你就不用担心它了。标准库中的regexp包使用有限状态自动机正确地实现正则表达式，因此它永远不必回溯（代价是不支持某些您可能实际上并不需要的功能）。有关更多信息，请参阅：