有效电子邮件地址的最大长度是多少？
有效电子邮件地址的最大长度是多少？ 它有任何标准定义吗？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
有效电子邮件地址的最大长度是多少？ 它有任何标准定义吗？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（8）
电子邮件地址不得超过 254 个字符。
在提交勘误后，IETF 接受了此内容。 可以在线获得任何给定地址的完整诊断。 RFC 3696 的原始版本将 320 描述为最大长度，但 John Klensin 随后接受了错误的值，因为 Path 被定义为
因此 Mailbox 元素（即电子邮件地址）周围有尖括号以形成 Path，这最大长度为 254 个字符，以将路径长度限制为 256 个字符或更少。
RFC 5321 中指定的最大长度规定：
RFC 3696 已在此处进行更正。
人们应该特别注意针对 RFC 3696 的勘误表。 三个规范示例实际上是无效地址。
我整理了数百个测试地址，您可以在 http://www.dominicsayers.com/isemail< /a>
An email address must not exceed 254 characters.
This was accepted by the IETF following submitted erratum. A full diagnosis of any given address is available online. The original version of RFC 3696 described 320 as the maximum length, but John Klensin subsequently accepted an incorrect value, since a Path is defined as
So the Mailbox element (i.e., the email address) has angle brackets around it to form a Path, which a maximum length of 254 characters to restrict the Path length to 256 characters or fewer.
The maximum length specified in RFC 5321 states:
RFC 3696 was corrected here.
People should be aware of the errata against RFC 3696 in particular. Three of the canonical examples are in fact invalid addresses.
I've collated a couple hundred test addresses, which you can find at http://www.dominicsayers.com/isemail
320
这些分段看起来像这样
{64}@{255}
64 + 1 + 255 = 320
如果您要验证电子邮件，还应该阅读以下内容：在阅读 RFC 之前我知道如何验证电子邮件地址
320
And the segments look like this
{64}@{255}
64 + 1 + 255 = 320
You should also read this if you are validating emails: I Knew How To Validate An Email Address Until I Read The RFC
RFC 2821 指定：
但是，还有进一步的限制阅读：
正如 Dominic Sayers 在其验证并接受的RFC 3696 勘误表中所解释的那样< /a>:
RFC 2821 specifies:
However, there is a further restriction reading:
As Dominic Sayers explains in his verified and accepted erratum on RFC 3696:
为了帮助像我这样困惑的菜鸟，回答“有效电子邮件地址的最大长度是多少？” 是254 个字符。
如果您的应用程序使用电子邮件，只需将您的字段设置为接受 254 个或更少的字符即可。
您可以对电子邮件进行一系列测试，看看它在这里是否有效。 http://isemail.info/
RFC（或请求评论）是互联网工程任务组的一种出版物(IETF) 将 254 个字符定义为限制。 位于此处 - https://www.rfc-editor.org/rfc/ rfc5321#section-4.5.3
To help the confused rookies like me, the answer to "What is the maximum length of a valid email address?" is 254 characters.
If your application uses an email, just set your field to accept 254 characters or less and you are good to go.
You can run a bunch of tests on an email to see if it is valid here. http://isemail.info/
The RFC, or Request for Comments is a type of publication from the Internet Engineering Task Force (IETF) that defines 254 characters as the limit. Located here - https://www.rfc-editor.org/rfc/rfc5321#section-4.5.3
根据以下文章：
https://www.rfc-editor.org/rfc/rfc3696（第6页，第3节）
提到：
因此，电子邮件地址的最大总长度为 320 个字符
（“本地部分”：64 +“@”：1 +“域部分”：255，总和为 320）
According to the below article:
https://www.rfc-editor.org/rfc/rfc3696 (Page 6, Section 3)
It's mentioned that:
So, the maximum total length for an email address is 320 characters
("local part": 64 + "@": 1 + "domain part": 255 which sums to 320)
其他答案有点把水搅浑了。
简单答案：我们控制的电子邮件总字符数为 254
256 代表整个电子邮件地址，其中包含隐含的“<” 开头和“>” 在最后。 因此，还剩下254个供我们使用。
The other answers muddy the water a bit.
Simple answer: 254 total chars in our control for email
256 are for the ENTIRE email address, which includes implied "<" at the beginning, and ">" at the end. Therefore, 254 are left over for our use.
TLDR 答案
给定一个电子邮件地址，例如...
长度限制如下：
64个字符。254个字符。来源——TLDR；
RFC 标准在不断发展，但如果您想在一行中获取 2009 年 IETF 源代码：
来源 — 历史
SMTP 最初定义了 RFC821，1982 年 8 月发布，即 官方互联网标准（大多数 RFC 只是提案）。 引用它...
RFC2821，于 2001 年 4 月发布，是已过时的标准，定义了我们当前的本地最大值- 部分、域和路径。 2008 年 10 月发布的新标准草案 RFC5321 保留了相同的限制。 在这两个日期之间，RFC3696 于 2004 年 2 月发布。它错误地引用了最大值电子邮件地址限制为
320个字符，但本文档仅供“参考”，并指出：“本备忘录为互联网社区提供信息。它不指定任何类型的互联网标准。” 所以，我们可以忽略它。引用 RFC2821，RFC5321 中确认的现代公认标准......
您会注意到，我指示的域最大值为 254，而 RFC 指示的域最大值为 255。这是一个简单的算术问题。 255 个字符的域加上“@”符号就是一个 256 个字符的路径，这是最大路径长度。 不过，空名称或空白名称是无效的，因此域实际上最多有 254 个。
TLDR Answer
Given an email address like...
The length limits are as follows:
256characters maximum.64character maximum.254characters maximum.Source — TLDR;
The RFC standards are constantly evolving, but if you want a 2009 IETF source in a single line:
Source — The History
SMTP originally defined what a path was in RFC821, published August 1982, which is an official Internet Standard (most RFC's are only proposals). To quote it...
RFC2821, published in April 2001, is the Obsoleted Standard that defined our present maximum values for local-parts, domains, and paths. A new Draft Standard, RFC5321, published in October 2008, keeps the same limits. In between these two dates, RFC3696 was published, on February 2004. It mistakenly cites the maximum email address limit as
320-characters, but this document is "Informational" only, and states: "This memo provides information for the Internet community. It does not specify an Internet standard of any kind." So, we can disregard it.To quote RFC2821, the modern, accepted standard as confirmed in RFC5321...
You'll notice that I indicate a domain maximum of 254 and the RFC indicates a domain maximum of 255. It's a matter of simple arithmetic. A 255-character domain, plus the "@" sign, is a 256-character path, which is the max path length. An empty or blank name is invalid, though, so the domain actually has a maximum of 254.
可悲的是，所有其他答案都是错误的。 其中大多数引用 RFC 2821 或更新版本，其中甚至没有定义电子邮件地址。 它所做的就是定义路径。 电子邮件地址由 RFC 2822（或更新版本）定义，并且可以更长。 有效地址但不是有效路径的示例有：
这两个都是相同的邮箱，但写法不同。 因此，如果您的目标是将电子邮件地址存储在数据库中，则 254、256 或 320 个八位字节的限制可能太低，但实际上这很少会成为问题。
Sadly, all the other answers are wrong. Most of them cite RFC 2821 or newer, which does not even define e-mail addresses. What it does do is define paths. E-mail addresses are defined by RFC 2822 (or newer) and can be much longer. Examples of valid addresses that are not valid paths are:
Both of these are the same mailbox written differently. So if your goal is to store e-mail addresses in a database, a limit of 254, 256 or 320 octets might be too low, although in practise, this is rarely going to be a problem.