blocks|key|932717|text|与正则表达式相比，我更喜欢文本操作来解析分隔字符串输入。发出字符串拆分比管理正则表达式要简单得多(至少对我来说是这样)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|932718|给出了一些案文：|932719|value1,+value2,+value3|code-block|syntax|javascript|932720|您可以轻松地解析行：|932721|var+values+=+myString.Split(',');|932722|我肯定还有更好的方法，但对于正则表达式，您必须执行如下操作：|932723|var+match+=+Regex.Match(myString,+"%5E([%5E,]*),([%5E,]*),([%5E,]*)$");
var+value1+=+match.Group[1];
...|932724|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I prefer text manipulation over regular expressions to parse delimited string input. It's far simpler (for me at least) to issue a string split than to manage a regular expression.

Given some text:

<pre><code>value1, value2, value3
</code></pre>

You can parse the line easily:

<pre><code>var values = myString.Split(',');
</code></pre>

I'm sure there's a better way but with regular expressions you'd have to do something like:

<pre><code>var match = Regex.Match(myString, "^([^,]*),([^,]*),([^,]*)$");
var value1 = match.Group[1];
...
</code></pre>

blocks|key|932731|text|我通常只对简单的字符串替换使用文本操作(例如用实际值替换模板中的标记)。当然，使用Regex可以做到这一点，但是替换要容易得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|932732|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I'll usually just use text manipulation for simple string replacements (e.g. replacing tokens in a template with actual values). You could certainly do this with Regex, but replacements are much easier.

blocks|key|2329068|text|是。示例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2329069|char*+basename+(const+char*+path)
{
++char*+p+=+strrchr(path,+'/');
++return+(p+!=+NULL)+?+(p%2B1)+:+path;
}|code-block|syntax|javascript|2329070|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Yes. Example:

<pre><code>char* basename (const char* path)
{
 char* p = strrchr(path, '/');
 return (p != NULL) ? (p+1) : path;
}
</code></pre>

blocks|key|2329100|text|RegEx的功能非常灵活和强大，因为它们在许多方面都类似eval()语句。话虽如此，但取决于实现，它们可能会有点慢。然而，通常情况下，如果可以在一个特别昂贵的循环中避免这些问题，这并不是一个问题，这可以提高性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2329101|尽管如此，我倾向于使用它们，只担心当应用程序“完成”时的性能，并且我有真正的基准来证明我需要调整性能。即避免过早优化。|2329102|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

RegEx's are very flexible and powerful, because they are in many ways similar to an eval() statement. That being said, depending on the implementation, they can be a bit slow. Normally, this is not an issue, however, if they can be avoided in a particularly costly loop, that can boost performance. 

That being said, I tend to use them, and only worry about performance when the app is "done" and I have real benchmarks to prove I need to tweak performance. i.e, avoid premature optimization.

blocks|key|2329113|text|Regex解析和执行是指宿主语言将处理推迟到其regex+"engine“。这增加了开销，因此对于任何可以使用本机字符串操作的实例，速度(以及可读性)都是可取的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2329114|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Regex parsing and execution refers the host language to defer processing to its regex "engine". This adds overhead, so for any instance where native string manipulation could be used it is preferable for speed (and readability!).

blocks|key|2329131|text|当您可以简单地使用本机文本操作时，通常最好不使用regex+(更简单的阅读和更好的性能)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2329132|个人经验法则:如果“手动”操作比较棘手或相对较长，而且性能提高是可以忽略不计的，则不要这样做。|2329133|不要举例：|2329134|拆分|unordered-list-item|2329135|简单查找和替换|2329136|长文本|2329137|循环播放|2329138|现有的本机函数(如PHP、strrchr、ucwords.)|offset|length|style|CODE|2329139|entityMap^0|0|0|0|0|0|0|0|D|7|L|7|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|10|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|11|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|12|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|13|8|@$Q|14|R|15|S|T]|$Q|16|R|17|S|T]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|V|$]]

When you can do it simply with native text manipulation, it is usually preferable (simpler to read &amp; better performance) not to use regex.

Personal rule of thumb: if it's tricky or relatively longer to do it "manually" and that performance gain is negligible, don't. Else do.

Don't examples:

<ul>
<li>split</li>
<li>simple find &amp; replace</li>
<li>long text</li>
<li>loop</li>
<li>existing native functions (like, in PHP, <code>strrchr</code>, <code>ucwords</code>...)</li>
</ul>

blocks|key|933347|text|使用regex基本上意味着在程序中间嵌入一个用不同编程语言编写的小程序。我将忽略对本机字符串操作使用regex的效率低下，因为在大多数情况下它可能与此无关。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|933348|与regex相比，我更喜欢本地文本操作，因为对于其他人来说，本机文本操作更容易跟踪。这是经常发生的事，因为我周围的很多人对regex不太熟悉。除非使用与解析(通过regex)相关的内容，否则就不需要这样做了！|933349|与本机字符串操作相比，正则表达式通常速度更慢、可读性更低、调试难度更大。|933350|我更喜欢regex而不是字符串操作的主要情况是，当我希望能够有不同的方法来解析依赖于源的字符串时，源的类型将随着时间的推移而增加。在这种情况下，本机字符串操作实际上并不实用。我在数据库里插了一个regex列.|933351|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Using a regex basically means embedding a tiny program, written in a different programming language, in the middle of your program. I'll ignore the inefficiency of using a regex over native string manipulation, because it probably isn't relevant in most cases.

I prefer native text manipulation over regex any time native text manipulation will be easier to follow for other people. Which is true quite frequently, since plenty of the people around me are not strongly familiar with regex. Unless working with something that is very much about parsing (via regex) they should not need to be!

Regular expressions are usually slower, less readable, and harder to debug than native string manipulation.

The main case where I'll prefer regex over string manipulation is when I want to be able to have different ways to parse strings dependning on the source, and the types of sources will increase over time. Native string manipulation is not really practical in this case. I've had cases where I've stuck a regex column in a database...

blocks|key|2329220|text|只要有合理数量的代码，就可以达到相同的结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2329221|正则表达式非常强大，但它们往往很难读懂。如果您可以对简单的字符串操作执行同样的操作，这通常意味着代码更易于管理和维护。|2329222|在设置对象和解析表达式时存在一些开销。对于更简单的字符串操作，使用简单的字符串方法可以获得更好的性能。|2329223|示例：|2329224|从文件路径获取文件名(是的，我知道path类应该用于此，这只是一个例子.)|2329225|string+name+=+Regex.Match(path,+@"([%5E\\]%2B)$").Groups[0].Value;|code-block|syntax|javascript|2329226|与|2329227|string+name+=+path.Substring(path.LastIndexOf('\\')+%2B+1);|2329228|第二个解决方案是直截了当的，只需做最少的工作就可以得到结果。正则表达式解决方案会产生相同的结果，但是它会做更多的工作来解析字符串，并且它会产生一堆不需要的对象。|2329229|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|11|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|13|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Whenever the same result can be achieved with a reasonable amount of code.

Regular expressions are very powerful, but they tend to get hard to read. If you can do the same with simple string operations that usually means that the code gets easier to manage and maintain.

There is some overhead in setting up the object and parsing the expression. For simpler string manipulation you can get better performance with simple string methods.

Example: 
Getting the file name from a file path (yes, I know that the Path class should be used for that, it's just an example...)

<pre><code>string name = Regex.Match(path, @"([^\\]+)$").Groups[0].Value;
</code></pre>

vs.

<pre><code>string name = path.Substring(path.LastIndexOf('\\') + 1);
</code></pre>

The second solution is straight forward and does the minimal work needed to get the result. The regular expression solution produces the same result, but it does more work to parse the string, and it produces a bunch of objects that is not needed for the result.

Are there particular cases where native text manipulation is more desirable than regex?
In particular .net?

Note:
Regex appears to be a highly emotive subject, so I am wary of asking such a question. This question is not inviting personal/profession opinions on regex, only specific situations where a solution including its use is not as good as language native commands (including those which have underlying code using regex) and why.

Also, note that Desirable can mean performance, can mean code-readability; it does not mean <a href="http://dictionary.reference.com/search?q=panacea" rel="nofollow noreferrer">panacea</a>, as each solution for a problem has its benefits and limitations.

Apologies if this is a duplicate, I have searched SO for a similar question.

Are there particular cases where native text manipulation is more desirable than regex?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

是否有特定情况下，本机文本操作比regex更可取？特别是.net？注： Regex似乎是一个非常情绪化的话题，所以我不想问这样的问题。这个问题并不是征求个人/专业人士对regex的意见，只是在特定情况下，包括使用regex的解决方案不如语言本机命令(包括那些具有使用regex的底层代码的命令)，以及为什么。另外，请注意...

问是否有特定情况下，本机文本操作比regex更可取？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否有特定情况下，本机文本操作比regex更可取？EN