.net - RegularExpressionValidator.ValidationExpression 强制长度为 10 或 12 个符号

标签 .net asp.net regex validation

RegularExpressionValidator.ValidationExpression="\d{10}" 表示仅数字 - 最多 10 个。

RegularExpressionValidator.ValidationExpression="\d{10,12}" 表示仅数字 - 10、11 或 12。

如何强制严格使用 10 或 12 个符号?

最佳答案

一种方法是:

"\d{10}(\d{2})?"

或者您可以更明确,但会牺牲一点性能:

"^(\d{10}|\d{12})$"

第二个表达式中 anchor 的原因描述为here :

If you experience problems with pattern-matching constructs, try wrapping the expression with "^(" and ")$". For example, "a|ab" becomes "^(a|ab)$".

<小时/>

更新

我对为什么 \d{10}|\d{12} 无法正常工作很感兴趣,并决定深入研究验证器的源代码以了解失败的原因。

RegularExpressionValidator 使用相同的正则表达式验证服务器端和客户端,在 \d{10}|\d{12} 的情况下长度为 12 时在客户端失败,但长度为 10 时有效。源代码揭示了如何进行匹配:

var rx = new RegExp(val.validationexpression);
var matches = rx.exec(value);
return (matches != null && value == matches[0]);

请注意,此正则表达式是 A|B 但如果 A 匹配,则甚至永远不会检查 B - 正则表达式在管道操作上不是“贪婪” - 它会采用它找到的第一个匹配项。所以这个正则表达式的匹配结果是,即使你输入了12位数字,十位数字也匹配成功。但是测试 value == matches[0] 失败,因为匹配不是完整的字符串。

交换术语的顺序,即编写 \d{12}|\d{10}确实有效,因为首先测试较长的匹配,并且仅当长匹配失败时才测试较短的匹配。

经验教训:在 RegularExpressionValidator 中使用管道时,最好显式使用 anchor ,以避免担心术语的顺序。

关于.net - RegularExpressionValidator.ValidationExpression 强制长度为 10 或 12 个符号,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2337176/

相关文章:

c# - ASP.NET 中的 Console.WriteLine

c# - 如何在内存映射文件中共享列表值

ruby - 替换括号中的文本 gsub

Python 正则表达式 : Group Backref

regex - VIM:替换没有参数的函数调用

.NET 等价于热键控制

c# - 较大数据集的子集 View 的设计模式

c# - 将经典 asp 应用程序移植到 .NET 时的语言选择

c# - 混淆模型与 View 模型

c# - 如何清除浏览器历史记录或清除缓存?