我已经使用正规表达式几年了,并对它们感到满意,但我想知道使用它们时是否有任何限制.我知道与递归相关的限制(在此讨论http://blogs.msdn.com/b/jaredpar/archive/2008/10/15/regular-expression-limitations.aspx).有没有与记忆相关的限制？我假设你可以捕获一个尽可能大的内存字符串(或者VM允许你).
我应该知道正则表达式还有其他限制吗？
提前致谢,
克里斯
巨大的正则表达可能非常缓慢且记忆力很大.我知道,因为我创造了一个.它可以标记正则表达式不应该标记的内容.:-)如果你想要一个链接......现在......我还没有对"小"正则表示基准,所以我不知道他们的速度.他们肯定是紧凑编写.
啊,我忘记了,正则表达是邪恶.他们的主要问题是它们就像一把锤子,当你拥有它们时,你会试图让所有的问题像钉子一样.所以他们的主要问题在于用户(程序员).
第一个"大"限制:Javascript只实现了它们的一部分,没有Unicode支持.通常,您使用服务器端的语言具有更完整的实现,因此您受到js的限制.即使是非常完整的实现,如.NET也有很大的限制:不支持代理对,也不支持"组合"字符(使用组合标记的字符).但是,与往常一样,问题在于程序员.有多少知道Unicode的程序员知道变音符号的各种数字组合的Unicode的复杂性？
第二个"大"限制:可维护性.它们编写时很复杂且难以理解.但几个月后呢？他们变得更糟!如果你必须训练一个新的程序员,现在他必须学习另一种语言:正则表达式.
第三个"大"限制:它们隐藏得太多了.你看\d\s\d.这是什么意思？数字空格和数字？一定.但两者\d并\s在.NET的正则表达式"隐藏"一个微观世界.\d"匹配"任何非欧洲数字(Unicode中有许多数字).\s"匹配"这么多深奥的空间,我甚至不知道这个名字......我甚至不想考虑它.它们就像冰山一样.只有1/8在水外,而7/8则被隐藏.但是7/8可能会杀了你.
正则表达式只能解析常规语法,无需任何上下文,而且需要更高的堆栈(即真正的解析器).
这是他们唯一真正的限制,性能取决于特定的实现,但与状态机相比,即使预编译通常也很慢.
限制
底线,它是一个工具.像任何其他工具一样使用它.不要过度使用它.不要让它成为工具包中的唯一工具.