刚刚写了一段正则表达式，用来验证 Email，除了已知两个连续的点不能过滤掉([email protected])，其他常见情况都覆盖到了。不知道还有没有漏掉什么？
\A[a-zA-Z0-9][a-zA-Z0-9_.-]*(?<![_.-])@[a-zA-Z0-9-]+\.[a-zA-Z0-9.-]+[a-zA-Z]\z
这些情况都不通过：
[email protected]
12#[email protected]
[email protected]
123@123
123@emailcom
123@emailcom.
这些情况能通过：
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
特殊字符的情况暂时不考虑，场景太少了。
漏掉了以下几种情况：
[email protected]
[email protected]
[email protected]
[email protected]
都加上了，最新的是这样。
\A[a-zA-Z0-9][a-zA-Z0-9_.-]*(?<![_.-])@(?!-)[a-zA-Z0-9-]+(?<!-)\.(?![.-])[a-zA-Z0-9.-]+[a-zA-Z]{2,}\z
以下这些暂时还是没办法过滤，放弃了感觉有点没完没了
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
经过 AI 辅助的最终版本，能过滤上边提到的所有非法邮箱地址：
\A[a-zA-Z0-9+]+([._-][a-zA-Z0-9+]+)*@[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?(\.[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?)*\.[a-zA-Z]{2,}\z
这个规则并没有按照 RFC 规范去生成，而是基于实际使用的常见的案例来做限制。比如 RFC 规则允许邮件地址出现 / 和 =，但实际使用中很少有这种情况，所以一律当成非法输入。
测试报告地址：https://www.onedoc.xyz/s/carwWiWUZ