jQuery插件和org.springmodules.validation之间的正则表达式电子邮件validation的区别
问候！ 我有一个Spring应用程序和一个在后端和前端validation的表单。 在后端，我在org.springmodules.validation的帮助下使用基于注释的EMAIL字段validation。 到现在为止还挺好。
在前端，我决定使用jQuery Form Validation插件，发现前后validation彼此不同步。
例如：@ bc传递jQueryvalidation但不传递Spring。 我看着两个重新gex’es和我的眼睛交叉。
有人会善意评论使用其中任何一个的权衡，利弊吗？
他们来了：
jQuery Validation Plugin正则表达式:( 原始来源）
^(([A-Za-z0-9]+_+)|([A-Za-z0-9]+\-+)|([A-Za-z0-9]+\.+)|([A-Za-z0-9]+\++))*[A-Za-z0-9]+@((\w+\-+)|(\w+\.))*\w{1,63}\.[a-zA-Z]{2,6}$ org.springmodules.validation正则表达式：
^((([az]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([az]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([az]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([az]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([az]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([az]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([az]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([az]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([az]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([az]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$
先谢谢了！
更不用说在不久的将来允许使用中文/阿拉伯语域名。 每个人都必须更改使用的电子邮件正则表达式，因为这些字符肯定不会被[az]/i或\w覆盖。 他们都会失败。
毕竟，validation电子邮件地址的最佳方法仍然是实际向相关地址发送电子邮件以validation地址。 如果电子邮件地址是用户身份validation（注册/登录/等）的一部分，那么您可以将其与用户激活系统完美地结合在一起。 即发送一封电子邮件，其中包含指向电子邮件地址的唯一激活密钥的链接，并且仅当用户使用电子邮件中的链接激活新创建的帐户时才允许登录。
如果正则表达式的目的只是为了在UI中快速通知用户指定的电子邮件地址看起来不是正确的格式，那么最好仍然检查它是否与以下正则表达式匹配：
^([^.@]+)(\.[^.@]+)*@([^.@]+\.)+([^.@]+)$
就那么简单。 为什么你会关心名称和域中使用的字符？ 客户有责任输入有效的电子邮件地址，而不是服务器的电子邮件地址。
通过正则表达式匹配电子邮件是一项艰巨的任务。 而jQueryvalidation的正则表达方式（！）简单。 它很简单，甚至会失败许多实际上有效的电子邮件地址。 再一次“嘿只有ASCII作为有效字符才忘记世界其他地方”
例如，带有德语变音字符的有效电子邮件地址
föobar@example.com
我的建议是只使用spring-backendvalidation电子邮件，并在客户端跳过该步骤。 之后你必须发送测试电子邮件，以检查电子邮件是否真的有效，活跃，……
有一百万种可能的解决方案，但我喜欢：
^[^<>\s\@]+(\@[^<>\s\@]+(\.[^<>\s\@]+)+)$
在这里，它正在做什么：
- 匹配左右V形，空白和@以外的所有字符
- 匹配@符号
- 重复＃1
- 匹配一个点（。）
- 重复＃1
这意味着当BalusC提到允许中文/阿拉伯语域名时，它将允许外国字符。 但它会捕获严重错误，如缺少@符号，域名没有点，空格等。此外，它在Javascript中的行为与在任何其他基于Perl的正则表达式语言I中的行为相同了解。 因此，它是客户端和服务器端validation的理想选择。
我在这里创建了测试用例：
http://regexhero.net/tester/?id=4a1f18cf-3dc0-4157-ab74-489a69e184ee
我确定你可以输入一些这个正则表达式匹配的无效地址。 但是出于网络validation的目的，我并不在乎这一点。 我的意思是，正则表达式永远不会完全取代真正的电子邮件validation。
所以我个人最关心的是在允许所有可能有效的电子邮件地址的同时捕获最常见的错误。 如果有人能找到这个正则表达式不匹配的有效电子邮件地址，我想知道它。 在那之前，这就是我将要使用的。 ;）
为什么不利用已经实现的解决方案： http ： //commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/EmailValidator.html
另一个正则表达式：
/^[a-z0-9\._-]+@[a-z0-9\._-]+\.(xn--)?[a-z0-9]{2,}$/i
如果用ASCII编写，它支持IDN（国际化域名）（例如xn--lvaro-wqa.es ）。 否则你需要实现Punycode编码。
我喜欢它，因为它非常简单。 它只寻找明显的打字错误。 如前所述，这是最好的方法。 表达式越复杂，您拒绝的有效电子邮件就越多。 真正的电子邮件validation只能通过实际发送电子邮件来完成。