试图建立一个正则表达式来检查模式 - 2

Question

我想知道是否可以添加更多检查：[之前回答的问题]（ Trying to build a regular expression to check pattern）。

使用Brian Rogers的正则表达式可以很好地解决上述问题：

/^([1-9]|[12][0-9]|3[01])(-([1-9]|[12][0-9]|3[01]))?(,([1-9]|[12][0-9]|3[01])(-([1-9]|[12][0-9]|3[01]))?)*$/  

[仅供参考，再次发布较旧的问题]

1. 以数字开头和结尾
2. 连字符应以数字开头和结尾
3. 逗号应以数字开头和结尾
4. 数字范围应为1-31
5. 如果数字以连字符（ - ）开头，则不能以逗号以外的任何其他字符结尾并遵循上面列出的所有规则。

E.g。 2-2,1或2,2-1在1-1-1-1无效时有效。

例如为：
- 1-5,5,15-29
- 1,28,1-31,15
- 15,25,3 - 1-24,5-6,2-9

这可以更进一步并添加其他验证吗？

1）数字应按升序排列
E.g：
  - 1,2-3 - 有效
  - 4-6,23 - 有效
  - 23,4-5 - 无效

2）数字不应重复
E.g：
a）2,2,2 - 无效
b）2,3-6,3 - 无效
c）2,5,7-20 - 有效

3）如果可能
如果先前在范围中定义，则不应重复编号 E.g：
a）2,3-6,4 - 无效，因为4已经是3到6之间的数字 b）12-16,14-18 - 无效，因为14,15和16已在12-16中定义 c）9-13,15,17-19-有效

Answer 1

正则表达式应该检查模式而不是处理业务逻辑。当你开始用“if ... then ... else”来陈述你的问题的那一刻，它不是正则表达式应该处理的东西。

Answer 2

正则表达式非常强大，可以用来解决你所面临的挑战 - 甚至可以实现某种业务逻辑验证。

从架构和软件工程的角度来看，我建议您重新构建问题并使用相当程序代码来解决问题。让我解释一下原因：代码将得到

• 很难阅读和理解
• 容易出错且不易测试
• 维持它的成本将会飙升

总而言之，即使正则表达式非常强大（我在我的应用程序中也大量使用它们），我也不会过度使用它。他们非常优雅地解决了一些问题，但是解决简单的事情变得非常难看。