是否存在本地文本操作比正则表达式更理想的特殊情况？ 特别是.net？
注意： 正则表达式似乎是一个高度情绪化的主题，所以我对提出这样一个问题很谨慎。 这个问题并没有邀请个人/专业人士对正则表达式的看法，只有特定情况下，包括其使用的解决方案不如语言本机命令（包括使用正则表达式的底层代码的那些）及其原因。< / p>
另外，请注意，Desirable可能意味着性能，可能意味着代码可读性;这并不意味着panacea，因为问题的每个解决方案都有其优点和局限性。
如果这是重复的道歉，我搜索了SO以寻找类似的问题。
答案 0 :(得分：6)
我更喜欢对正则表达式进行文本操作来解析分隔的字符串输入。发布字符串拆分比管理正则表达式要简单得多（至少对我来说）。
给出一些文字：
value1, value2, value3
您可以轻松解析该行：
var values = myString.Split(',');
我确信有更好的方法，但使用正则表达式，您必须执行以下操作：
var match = Regex.Match(myString, "^([^,]*),([^,]*),([^,]*)$");
var value1 = match.Group[1];
...
答案 1 :(得分：4)
当你可以使用原生文本操作简单时，通常更喜欢（更简单的阅读和更好的性能）不使用正则表达式。
个人经验法则：如果“手动”执行此操作是棘手的或相对较长的，并且性能增益可以忽略不计，请不要这样做。其他。
不要举例：
strrchr，ucwords ...）答案 2 :(得分：2)
使用正则表达式基本上意味着在程序中间嵌入一个用不同编程语言编写的小程序。我会忽略使用正则表达式而不是本机字符串操作的低效率，因为它在大多数情况下可能不相关。
我更喜欢本地文本操作而不是正则表达式，只要本地文本操作对其他人来说更容易理解。这种情况经常发生，因为我周围的人很多都不熟悉正则表达式。除非使用非常类似于解析的东西（通过正则表达式），否则它们不应该是！
正则表达式通常比本机字符串操作更慢，更不易读，也更难调试。
我希望正则表达式优先于字符串操作的主要情况是我希望能够根据源来解析字符串的不同方法，并且源的类型会随着时间的推移而增加。在这种情况下，本机字符串操作并不实用。我曾经遇到过在数据库中插入正则表达式列的情况......
答案 3 :(得分：1)
RegEx非常灵活且功能强大，因为它们在很多方面类似于eval（）语句。话虽如此，根据实施情况，它们可能会有点慢。通常，这不是问题，但是，如果可以在特别昂贵的循环中避免它们，则可以提高性能。
话虽这么说，我倾向于使用它们，只关心应用程序“完成”时的性能，并且我有真正的基准来证明我需要调整性能。即，避免过早优化。
答案 4 :(得分：1)
正则表达式解析和执行是指主机语言将处理推迟到其正则表达式“引擎”。这会增加开销，因此对于可以使用本机字符串操作的任何实例，它最好是速度（和可读性！）。
答案 5 :(得分：1)
只要使用合理数量的代码可以获得相同的结果。
正则表达式非常强大，但它们往往难以阅读。如果您可以通过简单的字符串操作执行相同的操作，这通常意味着代码更易于管理和维护。
设置对象和解析表达式会有一些开销。对于更简单的字符串操作，您可以使用简单的字符串方法获得更好的性能。
例：
从文件路径获取文件名（是的，我知道应该使用Path类，这只是一个例子......）
string name = Regex.Match(path, @"([^\\]+)$").Groups[0].Value;
VS
string name = path.Substring(path.LastIndexOf('\\') + 1);
第二种解决方案是直接的，并且完成了获得结果所需的最小工作量。正则表达式解决方案产生相同的结果，但它解析字符串的工作量更大，并且它会产生一堆结果不需要的对象。
答案 6 :(得分：0)
我通常只使用文本操作来进行简单的字符串替换（例如，用实际值替换模板中的标记）。你当然可以用Regex做到这一点，但替换更容易。
答案 7 :(得分：0)
是。例如：
char* basename (const char* path)
{
char* p = strrchr(path, '/');
return (p != NULL) ? (p+1) : path;
}