多年来,我慢慢地开发了一个正则表达式,它可以正确验证大多数电子邮件地址,假设它们不使用IP地址作为服务器部分。
我在几个PHP程序中使用它,而且大多数时候都可以使用。然而,不时有人与我联系,他们对使用它的网站有问题,我最终不得不做出一些调整(最近我意识到我不允许四个字符的TLD)。
你有或见过验证电子邮件的最佳正则表达式是什么?
我见过几种使用函数的解决方案,这些函数使用了几个较短的表达式,但我宁愿在简单函数中使用一个长的复杂表达式,而不是在更复杂的函数中使用几个短表达式。
多年来,我慢慢地开发了一个正则表达式,它可以正确验证大多数电子邮件地址,假设它们不使用IP地址作为服务器部分。
我在几个PHP程序中使用它,而且大多数时候都可以使用。然而,不时有人与我联系,他们对使用它的网站有问题,我最终不得不做出一些调整(最近我意识到我不允许四个字符的TLD)。
你有或见过验证电子邮件的最佳正则表达式是什么?
我见过几种使用函数的解决方案,这些函数使用了几个较短的表达式,但我宁愿在简单函数中使用一个长的复杂表达式,而不是在更复杂的函数中使用几个短表达式。
当前回答
您可以使用jQuery 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])))\.?$/i
其他回答
对于Angular2/Angular7,我使用以下模式:
emailPattern=“^[a-zA-Z0-9-_.+-]+@[a-zA-APP-GW-9-]+[.]+[a-zA-62-9-.]+(\\s)*”;私有createForm(){this.form=this.formBuilder.group({email:['',[Validators.required,Validators.pattern(this.emailPattern)]]});}
它还允许在结尾处添加额外的空间,在将其发送到后端之前,应该将其截断,但某些用户,特别是移动用户,很容易在结尾处错误地添加空间。
[更新]我整理了我所知道的有关电子邮件地址验证的所有信息http://isemail.info,它现在不仅可以验证,还可以诊断电子邮件地址的问题。我同意这里的许多意见,即验证只是答案的一部分;看看我的文章什么是有效的电子邮件地址?。
据我所知,is_email()仍然是唯一一个能明确告诉您给定字符串是否为有效电子邮件地址的验证器。我已在上载了新版本http://isemail.info/
我整理了来自Cal Henderson、Dave Child、Phil Haack、Doug Lovell、RFC 5322和RFC 3696的测试用例。总共275个测试地址。我对我能找到的所有免费验证器进行了所有这些测试。
我会尽量让这个页面保持最新,因为人们会增强他们的验证器。感谢Cal、Michael、Dave、Paul和Phil在编译这些测试时的帮助和合作,以及对我自己的验证器的建设性批评。
人们应该特别注意RFC 3696的勘误表。其中三个典型示例实际上是无效地址。地址的最大长度是254或256个字符,而不是320个字符。
我使用
^\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$
这是RegularExpressionValidator在ASP.NET中使用的值。
对我来说,检查电子邮件地址的正确方法是:
检查符号@是否存在,在它之前和之后是否有一些非@符号:/^[^@]+@[^@]+$/尝试用一些“激活码”向该地址发送电子邮件。当用户“激活”他/她的电子邮件地址时,我们将看到一切都是正确的。
当然,当用户键入一封“奇怪”的电子邮件时,您可以在前端显示一些警告或提示,以帮助他/她避免常见错误,如域名部分没有圆点或名称中没有空格而没有引号等。但您必须接受地址“hello@world“如果用户真的想要它。
此外,您必须记住,电子邮件地址标准过去和将来都会发展,因此您不能总是只键入一些“标准有效”的正则表达式。而且你必须记住,一些具体的互联网服务器可能会在一些常见标准的细节上失败,事实上,它们可以使用自己的“修改标准”。
所以,只需检查@,在前端提示用户,并在给定地址发送验证电子邮件。
没有人提到本地化问题(i18n)。如果你的客户来自世界各地呢?
然后,您需要按国家/地区对正则表达式进行分类,我看到开发人员最终构建了一个大型字典或配置。检测用户的浏览器语言设置可能是一个很好的起点。