你有一个问题，决定使用正则解决，现在你有两个问题了？！

复杂的匹配都是先匹配一次，把匹配结果再进行匹配

我能用逻辑判断的还是避免写正则，有时候自己写的过两个月自己都看不懂

能用库尽量用库，比如 html 标签过滤这些，有的时候正则写复杂需求就是想 shi

具体说说这个问题，我很好奇怎么变成两个问题的

除非有极致的性能要求（正则也不见得比很多 if 要快），或者非常简单或常见的情况，不然我一般不会用正则。

因为我还会遇到另外两个问题：
1.太久没用又要学一次，doge 。
2.没写注释，看不懂了。

我一般用 regex101 测试好再贴到代码里

@Kasumi20 第二个问题是：怎么用正则表示第一个问题。


@loading 太真实了，用一次学一次。


@seers
@murmur 我的需求一般是字符串格式判断和提取，最近一次忘了写非贪婪匹配的? 就悲剧了

/t/875230

正则主要就字符串匹配和捕捉，复杂一点的就用 lpeg ，好用到飞起。

https://regexper.com/ 用这个，正则表达式图形化

@loading 正则不是效率比较差吗

正则很容易的

我发觉很多时候给别人答案是正则时，对方甚少接受的
正则我很常用，因为平常文件改名、搜索文件、搜索文本……就在用，最小的频率也不低 1 次 /2 天，所以大部分都能读懂和手写


@HankAviator #12
跟纯 string 函数比，是效率低，但也是次数少的情况，但其他场景就不一定了
1. 要好几个甚至非常多字符串函数组合的情况
2. 需要泛匹配的情况
3. 数量巨大，例如十万或百万 html 匹配，用正则比 DOM 效率高很多

能不用就不用, 每次都要重新去看一下语法, 然后过几天又忘了

regex101 是神器，测试通过就可用了

写完之后在文本编辑器中多测试一下不同场景（ PS：现在主流的文本编辑器基本都可以测试正则表达式匹配），基本就没啥问题了

你想写一个匹配邮箱的正则, 结果发现茫茫多的边缘 case

比如 1@1 是合法的邮箱吗?

@lixinrui000 regex101 是我个人觉得最好的正则表达式解析网站了

写正则到还好吧.最坑的是遇见过正则死循环.程序跑半天不结束,cpu 跑满.
具体原因也不知道为啥,去掉 * 号重写就好了

正则简单的还好，复杂的头晕，可能还有潜藏的 case 没有覆盖以及性能问题

个人认为能不用就不用。

骚操作：读到 `<div class="member">用户名</div>`，用 string.repace(/^<div class="member">(.*)</div>$/, $0) 提取用户名。

测试覆盖好边界，注释写清楚。

更复杂的场景写 parser

正则这东西真特么神奇，隔一段时间绝对可以忘得一干二净！

正则这东西，真是只有在所有可以使用的正则的地方经常使用，才能体现投入产出比。
但是麻烦的就是在 php,python,grep,vim,sed 各类可以使用的地方，他们的正则在细微处总有差异，特别在转义方面有着各自的坚持，实在是令人抓狂。

除了上面提到的 regex101.com ，补充个 debuggex.com 的图形化显示也能较好辅助理解。

@bulay 你这是遇到“灾难性回溯”（或“回溯陷阱”）了

随便一搜，资料很多。比如： https://zh.Javascript.info/regexp-catastrophic-backtracking

@fstar #21 linux 管道流式分析日志都是用这种方式提取，包括一些日志软件

这个笑话我在学校学 C 的时候老师就讲过了，大意是正则晦涩难懂，其实无他手熟尔

regex 是天书，非常需要注释。所以每写一条都要在旁边写一些例子，便于后期阅读。

@HankAviator 自己写出同样功能的代码, 效率不一定比正则好. 所以放心用吧.

感觉还是因为害怕使用，所以不愿意用，尽可能避免用。
但是经常用的话，看正则跟看普通代码一样没啥区别，逻辑不复杂的正则根本不需要注释。除非括号嵌套比较深的，如果正则引擎或语言其他特性支持的话，给换行带个缩进就好。

我有这样的想法是在之前学 iptables 的时候，一堆参数记不住，都是一个字母的，也没啥具体含义的参数，所以我就不想用。可是 iptables 用的人很多啊，经常用的人这些参数都能直接写出来的，没啥难度哇。
正则也是，如果自己不会的话，是不愿意用，但自己会用的话，效率还是很高的。

@jinliming2 emmmm ，iptables 参数没啥具体意义，这个说法不太对。是说参数含义比较难记。

@wxf666 具体内容忘了,应该是这个原因.看完之后豁然开朗.其实就是两个贪婪标志加边界问题.被匹配对象太长没有注意到

以前做过一些硬件报文的解析，几千个字符，每个数据之间用空格隔开，提取数据的时候还是正则香。。。

regex coach ，很棒的正则验证软件，可惜只有 Windows 端得

感觉标题的这个现象是因为对正则表达式过度神化了。如果你无法用正则语言描述你的数据（或你需要处理的子集），那么你的数据八成是没法通过正则表达式处理的，还是老老实实写字符串处理代码比较好。

比如「匹配 n 个 a 之后跟着 n 个 b 的字符串」，这个需求是根本不能用正则表达式做的。同理「匹配身份证是否有效」这个需求也是（除了枚举所有有效的身份证号）无法完整地用正则表达式实现的（只是匹配 18 位数字或者 17 位数字带一个 X 是不完整的）。1@1 是合法的邮箱么？ 13600000000 是合法的手机号么？很多我们觉得「或许可以用正则处理」的问题实际上是在操作不正则的数据（比如测试邮箱是否合法），或者操作虽然因是有限语言而正则但是枚举所有句子根本不可行的数据（比如测试身份证号是否合法）。

当然，算上 Perl 给大家带来的那种 irregular 的正则，或许可以处理一点点上下文无关的数据。但还是，很怪。