描述邪恶的正则表达式，从wikipedia：
>正则表达式将重复(“”，“*”)应用到复杂子表达式;
>对于重复的子表达式，存在也是另一有效匹配的后缀的匹配。
有了例子，再次从wikipedia：
>(a)
>([a-zA-Z])*
>(a | aa)
>(a | a？)
>(。* a){x} for x> 10
这是一个问题，只是没有一个更简单的解释？我正在寻找一些东西，这将使它更容易避免这个问题，同时编写正则表达式，或者在现有的代码库中找到它们。
我会采取一个模式灵感来自你给你的第一个例子，并拼写出来给你：
^((ab)*)+$
给定输入：
ababab
正则表达式引擎尝试类似(ababab)，并在第一次尝试找到匹配。好极了！但是，我们把猴子扳手放在：
abababa
正则表达式引擎尝试(ababab)但是失败，因为额外的a。但不要害怕，我们的强大的正则表达式引擎再次尝试，这次有类似(abab)(ab)。但这也没有工作。 “”好吧，“它自我说，”时间屈服和解决这个问题。
(ababab)– Nope
(abab)(ab)– Nope
(ab)(abab)– Nope
(ab)(ab)(ab)– Nope
()(ababab)– Nope
()(abab)(ab)– Nope
()(ab)(abab)– Nope
()(ab)(ab)(ab)– Nope
…
在你知道之前，正则表达式引擎正在占用你所有的系统资源，试图解决这个问题，直到用尽了所有可能的条款组合，它终于放弃，并转向你说“这不是一个匹配。回头看看正则表达式引擎，你可以看到你的服务器，一堆燃烧的熔融金属。
对于识别这些正则表达式，它实际上可能是非常棘手的。我自己写了一对夫妻，尽管我知道他们是什么，一般如何避免他们。看到Regex taking surprisingly long time.包裹一切你可以在一个atomic group可以帮助防止回溯问题。它基本上告诉正则表达式引擎不要尝试多个组合 – “如果开始你不成功，立即运行！
不幸的是，一旦写入，实际上很难立即或快速找到正规表达式的问题。最后，识别坏的正则表达式就像识别任何其他错误的代码 – 它需要大量的时间和经验和/或单个灾难性事件。
(注意：上面的“匹配”只是说明性的，匹配的实际顺序将取决于正则表达式引擎，但你得到的是主旨。
