什么时候最好使用正则表达式而不是基本的字符串拆分/子串？

似乎在我出现需要字符串的一部分,有关所述字符串的信息等的情况下,随时出现使用字符串解析与正则表达式的选择.

之所以出现这种情况,是因为我们正在评估一个soap标头的动作,之后它被解析为可通过WCF的OperationContext对象管理的东西,然后就此做出决定.现在,简单的解决方案似乎是基本的子串,以保持实现简单,但我的一部分想知道RegEx是否更好或更强大.我的另一部分想知道在我们的特定场景中是否使用霰弹枪杀死苍蝇.

所以我不得不问,在尝试决定使用RegEx而不是典型的字符串解析时,人们使用的典型阈值是什么.请注意,我在正则表达式中不是很强,因此,我试图回避,除非避免引入比我需要的更多复杂性是绝对重要的.

如果您无法通过我选择的缩写来判断,这是在.NET版本(C#)中,但我认为这与问题没有多大关系.

编辑:根据我典型的Raybell魅力,我在问题中一直过于罗嗦或误导.我想道歉.我提供了一些背景知识,以帮助提供关于我在做什么的线索,而不是误导人.

我基本上正在寻找关于何时使用子字符串及其变体的指南,而不是正则表达式,反之亦然.虽然有些答案可能已经错过了这一点(我的错也是如此),但我真的很感激他们并且相应地进行了投票.

我的主要指导是为一次性代码和用户输入验证使用正则表达式.或者当我试图在大量文本中找到特定模式时.出于大多数其他目的,我将编写一个语法并实现一个简单的解析器.

一个重要的指导原则(虽然我看到人们一直在尝试,但是很难回避)是在目标语言的语法是递归的情况下总是使用解析器.

例如,考虑一种微小的"表达式语言"来评估括号中的算术表达式.此语言中"程序"的示例如下所示:

1 + 2
5 * (10 - 6)
((1 + 1) / (2 + 2)) / 3

语法很容易编写,看起来像这样:

DIGIT := ["0"-"9"]
NUMBER := (DIGIT)+
OPERATOR := ("+" | "-" | "*" | "/" )
EXPRESSION := (NUMBER | GROUP) (OPERATOR EXPRESSION)?
GROUP := "(" EXPRESSION ")"

使用该语法,您可以在jiffy中构建递归下降解析器.

一个等价的正则表达式真难写,因为正则表达式通常不能很好地支持递归.

另一个很好的例子是JSON摄取.我见过人们尝试使用正则表达式来使用JSON,而且它是INSANE.JSON对象是递归的,所以它们只是求助于常规语法和递归下降解析器.

嗯......看看其他人的回答,我想我可能回答了错误的问题.

我把它解释为"什么时候应该使用一个简单的正则表达式,而不是一个完整的解析器？" 而大多数人似乎都把这个问题解释为"你应该何时推出自己的笨拙的逐个字符验证方案,而不是使用正则表达式？"

鉴于这种解释,我的答案是:永远不会.

好的....还有一个编辑.

我会对你自己的计划有点宽容.只是......不要称它为"解析":o)

我认为一个好的经验法则是,如果可以使用单个谓词实现所有逻辑,则应该只使用字符串匹配原语.像这样:

if (str.equals("DooWahDiddy")) // No problemo.

if (str.contains("destroy the earth")) // Okay.

if (str.indexOf(";") < str.length / 2) // Not bad.

一旦你的条件包含多个谓词,那么你就已经开始发明自己的特殊字符串验证语言了,你应该只是编写并学习一些正则表达式.

if (str.startsWith("I") && str.endsWith("Widget") &&
    (!str.contains("Monkey") || !str.contains("Pox")))  // Madness.

正则表达式真的不难学.与具有数十个关键字,原始类型和运算符的C#等huuuuge全功能语言以及具有数千个类的标准库相比,正则表达式绝对简单.大多数正则表达式实现支持大约十几个操作(给予或接受).

这是一个很好的参考:

http://www.regular-expressions.info/

PS:作为奖励,如果你也想了解如何编写自己的解析器(使用lex/yacc的,ANTLR,JavaCC的,或其他类似的工具),学习正则表达式是一个伟大的准备,因为分析器生成工具使用许多同样的原则.

正则表达式可以

更容易理解

更清楚地表达意图

矮得多

更容易改变/适应

在某些情况下,所有这些优点都可以通过使用正则表达式实现,而在其他情况下只实现了一些(正则表达式并不是很容易理解),而在其他情况下,正则表达式更难以理解,模糊了意图,更长时间而且很难改变.

我从正则表达式获得的那些(可能还有其他)优势越多,我就越有可能使用它们.

可能的经验法则:如果理解正则表达式对于熟悉正则表达式的人需要几分钟,那么你不想使用它(除非"正常"代码更复杂;-).

嗯...仍然没有简单的经验法则,对不起.