电子邮件地址中允许使用哪些字符?

我不是在问完整的电子邮件验证。

我只是想知道电子邮件地址的user-nameserver部分允许使用哪些字符。这可能过于简单,也许电子邮件地址可以采用其他形式,但我不在乎。我只问这个简单的形式:user-name@server(例如wild.wezyr@best-server-ever.com)和两部分都允许使用的字符。

1137300 次浏览

RFC 5322:Internet消息格式,在较小程度上,RFC 5321:简单邮件传输协议

rfc822也涵盖了电子邮件地址,但它主要处理其结构:

 addr-spec   =  local-part "@" domain        ; global addresslocal-part  =  word *("." word)             ; uninterpreted; case-preserved 
domain      =  sub-domain *("." sub-domain)sub-domain  =  domain-ref / domain-literaldomain-ref  =  atom                         ; symbolic reference

像往常一样,维基百科有一个体面的关于电子邮件地址的文章

电子邮件地址的本地部分可以使用以下任何ASCII字符:

  • 大写和小写拉丁字母AZaz
  • 数字09
  • 特殊字符!#$%&'*+-/=?^_`{|}~
  • .,前提是它不是第一个或最后一个字符,除非引号,并且还提供除非引号,否则它不连续出现(例如不允许John..Doe@example.com,但允许"John..Doe"@example.com);
  • 允许使用空格和"(),:;<>@[\]字符,但有限制(它们只允许在带引号的字符串中使用,如下面段落所述,此外,反斜杠或双引号必须在反斜杠之前);
  • 注释允许在本地部分的两端带有括号;例如john.smith(comment)@example.com(comment)john.smith@example.com都等效于john.smith@example.com

除了ASCII字符之外,截至2012您还可以使用国际上面的字符U+007F,编码为UTF-8,如rfc6532规范中所述,并在维基百科中解释。请注意,截至2019年,这些标准仍标记为提议,但正在缓慢推出。此规范中的更改基本上增加了国际字符作为有效的字母数字字符(atext),而不会影响!#@:等允许和受限特殊字符的规则。

有关验证,请参阅使用正则表达式验证电子邮件地址

domain部分定义为如下

协议的互联网标准(征求意见)要求组件主机名标签只能包含ASCII字母az(不区分大小写)、数字09和连字符(-)。rfc952中主机名的原始规范要求标签不能以数字或连字符开头,也不能以连字符结尾。然而,随后的规范(rfc1123)允许主机名标签以数字开头。不允许其他符号、标点符号或空格。

你可以从维基百科文章开始:

  • 大写和小写英文字母(a-z, A-Z)
  • 数字0到9
  • ! # $ % &; ' * + - / = ? ^ _ ` { | } ~
  • 字符。(点,句点,句号),前提是它不是第一个或最后一个字符,并且它不连续出现两次或多次。

维基百科对此有一篇很好的文章官方规格在这里。来自维基百科:

电子邮件地址的本地部分可以使用以下任何ASCII字符:

  • 大写和小写英文字母(a-z, A-Z)
  • 数字0到9
  • ! # $ % &; ' * + - / = ? ^ _ ` { | } ~
  • 字符。(点,句点,句号),前提是它不是第一个或最后一个字符,并且它不连续出现两次或多次。

此外,引号字符串(即:“John Doe”@example.com)是允许的,因此允许使用否则将被禁止的字符,但是它们在通常的实践中不会出现。RFC 5321还警告“期望接收邮件的主机应该避免定义本地部分需要(或使用)引号字符串形式的邮箱”。

当心!这个帖子里有一堆腐烂的知识(以前是真的,现在不是了)。

为了避免当前和未来世界上任何地方的真实电子邮件地址被误判拒绝,你至少需要知道rfc3490的高级概念,“应用程序中域名的国际化(IDNA)”。我知道美国和A国的人通常不喜欢这个,但它已经在世界上排名第一(主要是非英语主导的部分)。

要点是,你现在可以使用像mason@日本. com和wildwezyr@fahrvergnügen.net.不,这还不兼容所有的东西(正如上面许多人哀叹的那样,即使是简单的qmail风格+ident地址也经常被错误地拒绝)。但是有一个RFC,有一个规范,它现在得到了IETF和ICANN的支持,更重要的是,目前有大量且越来越多的实现支持这种改进。

直到我搬回日本并开始看到hei@. ca等电子邮件地址和亚马逊URL,我自己对这一发展并不了解:

http://www.amazon.co.jp/ エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e? ie=UTF8&node=3210981

我知道你不希望链接到规格,但如果你仅仅依赖于黑客在互联网论坛上的过时知识,你的电子邮件验证器最终会拒绝非英语用户越来越希望工作的电子邮件地址。对于那些用户来说,这样的验证就像我们都讨厌的常见的脑残形式一样烦人,不能处理+或三部分域名或其他什么的。

所以我并不是说这不是一个麻烦,但是“在某些/任何/无条件下允许”的完整字符列表(几乎)是所有语言中的所有字符。如果你想“接受所有有效的电子邮件地址(以及许多无效的电子邮件地址)”,那么你必须考虑IDN,这基本上使得基于字符的方法毫无用处(对不起),除非你先转换国际化的电子邮件地址(自2015年9月起死亡,曾经是像这样-一个可行的替代方案是这里)到Punycode

这样做后,你可以遵循(大部分)上面的建议。

姓名:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

服务器:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

谷歌用他们的gmail.com地址做了一件有趣的事情。gmail.com地址只允许字母(a-z),数字和句点(忽略)。

例如,pikachu@gmail.com与pi.kachu@gmail.com相同,两个电子邮件地址将发送到同一个邮箱。PIKACHU@gmail.com也发送到同一个邮箱。

所以要回答这个问题,有时这取决于实施者想要遵循多少RFC标准。谷歌的gmail.com地址风格与标准兼容。他们这样做是为了避免混淆,不同的人会使用类似的电子邮件地址。

*** gmail.com accepting rules ***d.oy.smith@gmail.com   (accepted)d_oy_smith@gmail.com   (bounce and account can never be created)doysmith@gmail.com     (accepted)D.Oy'Smith@gmail.com   (bounce and account can never be created)

维基百科链接是关于电子邮件地址通常允许的很好的参考。http://en.wikipedia.org/wiki/Email_address

简短的回答是,有两个答案。你应该做什么有一个标准。即明智的行为,会让你远离麻烦。对于你应该接受而不制造麻烦的行为,还有另一个(更广泛的)标准。这种二元性适用于发送和接受电子邮件,但在生活中有着广泛的应用。

有关您创建的地址的良好指南;请参阅:https://www.jochentopf.com/email/chars.html

要过滤有效的电子邮件,只需传递任何可理解的内容即可查看下一步。或者开始阅读一堆RFC,小心,这里有龙。

检查@和。然后发送电子邮件让他们验证。

我仍然无法在互联网上20%的网站上使用我的. name电子邮件地址,因为有人搞砸了他们的电子邮件验证,或者因为它早于新地址有效。

可以在此维基百科链接中找到

电子邮件地址的本地部分可以使用以下任何ASCII字符:

  • 大写和小写拉丁字母AZaz

  • 数字09

  • 特殊字符!#$%&'*+-/=?^_`{|}~

  • .,前提是除非加引号,否则它不是第一个或最后一个字符,并且除非加引号,否则它不会连续出现(例如不允许John..Doe@example.com,但允许"John..Doe"@example.com);

  • 允许使用空格和"(),:;<>@[\]字符,但有限制(它们仅允许在带引号的字符串中使用,如下面段落所述,此外,反斜杠或双引号必须在反斜杠之前);

  • 注释允许在本地部分的两端带有括号;例如john.smith(comment)@example.com(comment)john.smith@example.com都等效于john.smith@example.com

除了上述ASCII字符外,rfc6531还允许使用U+007F以上的国际字符,编码为UTF-8,尽管邮件系统可能会限制在分配本地部分时使用哪些字符。

带引号的字符串可以作为点分隔的实体存在于本地部分中,也可以在最外层的引号是本地部分的最外层字符时存在(例如,允许abc."defghi".xyz@example.com"abcdefghixyz"@example.com。相反,abc"defghi"xyz@example.com不是;abc\"def\"ghi@example.com也不是)。但是,带引号的字符串和字符不常用。rfc5321还警告“期望接收邮件的主机应避免定义本地部分需要(或使用)引号字符串形式的邮箱”。

本地部分postmaster受到特殊对待-它不区分大小写,应该转发给域电子邮件管理员。从技术上讲,所有其他本地部分都区分大小写,因此jsmith@example.comJSmith@example.com指定了不同的邮箱;然而,许多组织将大写和小写字母视为等效。

尽管特殊字符的范围很广,但在实践中,组织、邮件服务、邮件服务器和邮件客户端通常不接受所有这些字符。例如,Windows Live Hotmail只允许使用字母数字、点(.)、下划线(_)和连字符(-)创建电子邮件地址。常见的建议是避免使用一些特殊字符,以避免电子邮件被拒绝的风险。

Gmail只允许+符号作为特殊字符,在某些情况下(.),但Gmail不允许使用任何其他特殊字符。RFC说您可以使用特殊字符,但您应该避免使用特殊字符向Gmail发送邮件。

一个很好的阅读问题

摘录:

These are all valid email addresses!
"Abc\@def"@example.com"Fred Bloggs"@example.com"Joe\\Blow"@example.com"Abc@def"@example.comcustomer/department=shipping@example.com\$A12345@example.com!def!xyz%abc@example.com_somename@example.com

答案是(几乎)ALL(7位ASCII)。
如果包含规则是“……在某些/任何/无条件下允许……”

只需查看第17页顶部rfc5322中“域文本”部分中允许文本的几种可能包含规则之一,我们就会发现:

dtext          =   %d33-90 /          ; Printable US-ASCII%d94-126 /         ;  characters not includingobs-dtext          ;  "[", "]", or "\"

此描述中仅有的三个缺失字符用于domen-litals[],以形成引号对\和空格字符 (%d32)。因此使用了整个范围32-126(十进制)。类似的要求出现在“qtext”和“ctext”中。许多控制字符也被允许/使用。此类控制字符的一个列表出现在第31页RFC 5322第4.1节中,称为obs-NO-WS-CTL。

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control%d11 /             ;  characters that do not%d12 /             ;  include the carriage%d14-31 /          ;  return, line feed, and%d127              ;  white space characters

所有这些控制字符都允许,如第3.5节开头所述:

.... MAY be used, the use of US-ASCII control characters (values1 through 8, 11, 12, and 14 through 31) is discouraged ....

因此,这种包含规则"过于宽泛",或者换句话说,预期的规则"过于简单化"。

在我的PHP中,我使用此检查

<?phpif (preg_match('/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',"tim'qqq@gmail.com")){echo "legit email";} else {echo "NOT legit email";}?>

自己试试http://phpfiddle.org/main/code/9av6-d10r

在讨论电子邮件地址的有效本地部分时,接受的答案是指维基百科文章,但维基百科不是这方面的权威。

IETF RFC 3696是一个权威关于这个问题,应该在第5页的第2节中查阅:

当代电子邮件地址由“本地部分”组成,与由at符号(“@”)组成的“域部分”(完全限定的域名)。域部分的语法对应于前面的部分。该部分中确定的关于过滤和名称列表适用于电子邮件上下文中使用的域名,如很好。域名也可以替换为IP地址方括号,但强烈反对这种形式,除非测试和故障排除目的。

本地部分可能会使用所描述的引用约定出现下面。引用的表格在实践中很少使用,但需要出于一些合法的目的。因此,它们不应在过滤例程,而是应该传递给电子邮件系统由目标主机进行评估。

确切的规则是任何ASCII字符,包括控件字符,可能会出现引号,也可能出现在引号字符串中。当引用是需要时,反斜杠字符用于引用以下内容字符。例如

  Abc\@def@example.com

是电子邮件地址的有效形式。也可能出现空格,如

  Fred\ Bloggs@example.com

反斜杠字符也可用于引用自身,例如:

  Joe.\\Blow@example.com

除了使用反斜杠字符引用外,常规双引号字符可用于包围字符串。例如

  "Abc@def"@example.com
"Fred Bloggs"@example.com

是上面前两个例子的替代形式。引用的这些形式很少推荐,在实践中也不常见,但是,作为上面讨论的,必须由正在处理的应用程序支持电子邮件地址。特别是,引用的表格通常出现在与来自其他系统的转换相关的地址上下文和背景;这些过渡要求仍然存在,因为接受用户提供的电子邮件地址的系统不能“知道”该地址是否与遗留系统相关联地址表单必须被接受并传递到电子邮件环境中。

如果没有引号,本地部分可以由以下任意组合组成字母字符、数字或任何特殊字符

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

句点(“.”)也可能出现,但不能用于开始或结束本地部分,也不得出现两个或多个连续的时期。换句话说,任何ASCII图形(打印)字符,除了at符号(“@”)、反斜杠、双引号、逗号或方括号可能会出现没有引用。如果任何该列表中的排除要显示字符,必须引用它们。形式如

  user+mailbox@example.com
customer/department=shipping@example.com
$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

是有效的,并且经常看到,但任何字符上面列出的是允许的。

和其他人一样,我提交了一个适用于PHP和JavaScript的正则表达式来验证电子邮件地址:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

为了简单起见,在验证之前,我通过删除双引号内的所有文本以及与双引号周围的文本来净化提交,根据不允许的内容对电子邮件地址提交进行禁止。仅仅因为某人可以拥有John…"The*$hizzle*Bizzle"..Doe@whatever.com地址并不意味着我必须在我的系统中允许它。我们生活在未来,获得一个免费的电子邮件地址可能比擦屁股花更少的时间。而且,电子邮件标准并不是没有贴在输入旁边,说明什么是允许的,什么是不允许的。

在删除引用的材料后,我还对各种RFC中不允许的内容进行了清理。明确禁止的字符和模式列表似乎是一个更短的测试列表。

不允许使用:

    local part starts with a period ( .account@host.com )local part ends with a period   ( account.@host.com )two or more periods in series   ( lots..of...dots@host.com )&’`*|/                          ( some&thing`bad@host.com )more than one @                 ( which@one@host.com ):%                              ( mo:characters%mo:problems@host.com )

在给出的示例中:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com
John..Doe@whatever.com --> John.Doe@whatever.com

在尝试添加或更改电子邮件地址时,向剩余结果发送确认电子邮件是查看您的代码是否可以处理提交的电子邮件地址的好方法。如果电子邮件在根据需要进行了多轮清理后通过了验证,则触发该确认。如果从确认链接返回请求,则可以将新电子邮件从持有||临时||炼狱状态或存储移动到真正的、真正的一流存储电子邮件。

如果您想考虑周全,可以将电子邮件地址更改失败或成功的通知发送到旧的电子邮件地址。未经确认的帐户设置可能会在合理的时间后完全失败,从而从系统中删除。

我不允许在我的系统上发送臭洞电子邮件,也许这只是扔掉钱。但是,99.9%的时间人们只是做了正确的事情,并且有一封电子邮件不会利用边缘案例兼容性方案将一致性限制推向边缘。小心正则表达式DDoS,这是一个你可能会遇到麻烦的地方。这与我做的第三件事有关,我限制了我愿意处理任何一封电子邮件的时间。如果它需要减慢我的机器以进行验证——它不会通过我传入的数据API端点逻辑。

编辑:这个答案一直被指责为“坏”,也许它活该。也许它仍然很糟糕,也许不是。

电子邮件地址的格式为:local-part@domain-part(最多64@255个字符,总共不超过256个)。

local-partdomain-part可以有不同的允许字符集,但这还不是全部,因为它有更多的规则。

通常,本地部分可以具有以下ASCII字符:

  • 小写拉丁字母:abcdefghijklmnopqrstuvwxyz
  • 大写拉丁字母:ABCDEFGHIJKLMNOPQRSTUVWXYZ
  • 数字:0123456789
  • 特殊字符:!#$%&'*+-/=?^_`{|}~
  • 点:.(不是第一个或最后一个字符或重复,除非引用),
  • 空格标点符号,例如:"(),:;<>@[\](有一些限制),
  • 注释:()(允许放在括号内,例如(comment)john.smith@example.com)。

领域部分:

  • 小写拉丁字母:abcdefghijklmnopqrstuvwxyz
  • 大写拉丁字母:ABCDEFGHIJKLMNOPQRSTUVWXYZ
  • 数字:0123456789
  • 连字符:-(不是第一个或最后一个字符),
  • 可以包含用方括号括起来的IP地址:jsmith@[192.168.2.1]jsmith@[IPv6:2001:db8::1]

这些电子邮件地址有效:

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com(单字母局部部分)
  • "much.more unusual"@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
  • example-indeed@strange-example.com
  • admin@mailserver1(本地域名,没有顶级域名)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org(引号之间的空格)
  • example@localhost(来自localhost)
  • example@s.solutions(见互联网顶级域名列表
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

这些无效的例子:

  • Abc.example.com(无@字符)
  • A@b@c@example.com(引号外只允许一个@
  • a"b(c)d,e:f;gi[j\k]l@example.com(此本地部分中的任何特殊字符都不允许在引号之外)
  • just"not"right@example.com(带引号的字符串必须以点分隔或构成本地部分的唯一元素)
  • this is"not\allowed@example.com(空格、引号和反斜杠只能存在于带引号的字符串中,并且前面有反斜杠)
  • this\ still\"not\allowed@example.com(即使转义(前面有反斜杠),空格、引号和反斜杠仍然必须包含引号)
  • john..doe@example.com@之前的双点);(警告:Gmail允许这样做)
  • john.doe@example..com@后的双点)
  • 带前导空格的有效地址
  • 带有尾随空格的有效地址

来源:邮箱地址 at Wikipedia


Perl的RFC2822正则表达式验证电子邮件:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*))*)?;\s*)

RFC2822地址的完整regexp只是3.7k。

另见:PHP中的RFC 822电子邮件地址解析器


电子邮件地址的正式定义如下:

  • RFC 5322(第3.2.3和3.4.1节,过时的RFC 2822)、RFC 5321、RFC 3696、
  • RFC 6531(允许的字符)。

相关:

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

很多人已经试图回答这个问题。很多人也说很多答案已经过时了。这是我的答案,就2022年的情况而言。

这个问题的答案显然并不像提出的那样简单。当涉及到邮箱名称的命名时,建议的标准,具体来说,在这种情况下,,以及对这些RFC的解释是多种多样的。

对于部分,通用验收指导小组在此处标题为UASG-028的文档中就构成电子邮件ID本地部分的内容提出了详细的指导方针。

对于部分,此处提到的所有字符“应用程序的Unicode代码点和国际化域名(IDNA)”与字符状态“PVALID”。此外,状态为“CONTEXTJ”和“CONTEXTO”的字符在某些接触条件下有效。