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