SQL 电子邮件字段应该多长？ [复制]

Posted 2023-02-22

【中文标题】SQL 电子邮件字段应该多长？ [复制]

【英文标题】：How long should SQL email fields be? [duplicate]

【发布时间】：2010-11-20 19:14:55

【问题描述】：

我认识到电子邮件地址基本上可以无限长，因此我对 varchar 电子邮件地址字段施加的任何大小都是任意的。但是，我想知道“标准”是什么？你们多久能做到？ （名称字段的相同问题...）

更新： 显然，电子邮件地址的最大长度为 320（

【问题讨论】：

您对这些值使用什么 RFC？

***.com/questions/386294/…

【参考方案1】：

根据此文本，根据正确的 RFC 文档，它不是 320 而是 254： http://www.eph.co.uk/resources/email-address-length-faq/

编辑： 使用 WayBack 机器： https://web.archive.org/web/20120222213813/http://www.eph.co.uk/resources/email-address-length-faq/

电子邮件地址的最大长度是多少？

254 个字符

似乎对最大有效电子邮件地址有些混淆 地址大小。大多数人认为它是 320 个字符（64 用户名字符 + 域 255 个字符 + 1 @ 符号的字符）。其他来源建议 129 (64 + 1 + 64) 或 384（128+1+255，假设用户名在 未来）。

这种混淆意味着您应该注意“稳健性原则” （“开发人员应该仔细编写严格遵守 现存的 RFC，但接受并解析来自可能不是的对等方的输入 与那些 RFC 一致。” - ***）在编写软件时 处理电子邮件地址。此外，某些软件可能会瘫痪 通过天真​​的假设，例如认为50个字符就足够了 （例子）。您的 200 个字符的电子邮件地址在技术上可能是有效的 但是，如果大多数网站或应用程序拒绝它，那将无济于事。

目前电子邮件的实际最大长度为 254 个字符：

“RFC 3696 的原始版本确实说 320 是最大值 长度，但 John Klensin (ICANN) 随后接受了这是 错了。”

"这源于域最大长度的简单算术 （255 个字符）+ 邮箱的最大长度（64 个字符）+ @ 符号 = 320 个字符。错误的。这个鸭子实际上记录在 RFC3696 的原始版本。它在勘误表中得到纠正。 实际上 RFC5321 对路径元素的限制 256 个字符的 SMTP 事务。但这包括尖括号 围绕电子邮件地址，因此电子邮件地址的最大长度为 254 个字符。” - Dominic Sayers

【讨论】：

该链接不再有效。这就是为什么建议粘贴相关信息的原因。

【参考方案2】：

以下电子邮件地址只有 94 个字符：

[e-mail]

一个组织真的会给你一封这么长的电子邮件吗？ 如果他们足够愚蠢，您真的会使用这样的电子邮件地址吗？ 会有人吗？当然不会。太长打不出来，太难记住了。

即使是一个 92 岁的技术恐惧症患者也会想出如何注册一个漂亮的短 gmail 地址，然后直接使用它，而不是在您的注册页面中输入它。

磁盘空间可能不是问题，但允许用户输入字段的长度比所需的长很多倍至少存在两个问题：

显示它们可能会弄乱你的 UI

（最好的情况是它们会被截断，最坏的情况是它们会推动你的容器和边距）

恶意用户可以用他们做你无法预料的事情

（比如黑客使用免费的在线 API 来存储大量数据的情况）

我喜欢 50 个字符：

[e-mail]

如果百万分之一的用户必须使用他们的其他电子邮件地址来使用我的应用程序，那就这样吧。

（统计显示，实际上没有人输入超过 40 个字符的电子邮件地址，例如：ZZ Coder 的回答 https://***.com/a/1297352/87861）

【参考方案3】：

我使用 varchar(64) 我认为没有人可以拥有更长的电子邮件

【讨论】：

投了反对票，因为即使您认为接受您建议的人不可能将错误编码到他们的代码中。

【参考方案4】：

RFC 5321（当前的 SMTP 规范，已废弃 RFC2821）声明：

4.5.3.1.1。本地部分

一个用户的最大总长度 名称或其他本地部分为 64 八位字节。

4.5.3.1.2。域

a 的最大总长度 域名或号码是 255 个八位字节。

这仅与 localpart@domain 相关，总共 320 个 ASCII（7 位）字符。

如果您打算规范化您的数据，也许通过将本地部分和域拆分为单独的字段，请记住其他事项：

一种称为 VERP 的技术可能会为自动生成的邮件生成完整的本地部分（可能与您的用例无关） 域不区分大小写；建议将域部分小写 localparts 区分大小写；根据规范，[e-mail] 和 [e-mail] 在技术上是不同的地址，尽管 domain.com 的策略可能将这两个地址视为等效地址。最好将 localpart 大小写折叠限制在已知这样做的域中。

【参考方案5】：

我过去刚刚完成了 255，因为这是一个根深蒂固的标准，即简短但不是太短的输入。那，我是个习惯性动物。

但是，由于最大值为 319，我会在该列上使用 nvarchar(320)。一定要记住@！

nvarchar 不会使用您不需要的空间，因此如果您只有 20 个字符的电子邮件地址，它只会占用 20 个字节。这与nchar 形成对比，nchar总是占据其最大值（它用空格右填充值）。

我也会使用nvarchar 代替varchar，因为它是Unicode。鉴于电子邮件地址的波动性，这绝对是要走的路。

【讨论】：

255+64 = 319, 320 算@

我正在使用 phpMyAdmin 设置数据库，但我在任何地方都看不到 nvarchar...我需要使用 SQL 语句手动设置它，还是我只是在某个地方错过了它?

thismailaddressisonly160charslong-thatishalfofwhatyousuggest-iknowperformancewont通常[e-mail]

【参考方案6】：

理论上的限制确实很长，但您真的需要担心这些长电子邮件地址吗？如果有人无法使用 100 字符的电子邮件登录，您真的在乎吗？我们实际上更喜欢他们不能。

一些统计数据可能会说明这个问题。我们分析了一个包含超过 1000 万个电子邮件地址的数据库。这些地址未确认，因此存在无效地址。以下是一些有趣的事实，

最长有效的是 89。 有数百个更长的，直到我们列的限制 (255)，但通过目视检查它们显然是假的。 长度分布的峰值在 19 处。 没有长尾。 38 岁后一切都急剧下降。

我们通过丢弃任何超过 40 条的数据来清理数据库。好消息是没有人抱怨，但坏消息是清理掉的记录并不多。

【讨论】：

感谢上帝的一些常识。每个人都说“让它成为 320！”拜托，please 输入一个 320 个字符的电子邮件地址，仔细查看它，然后问问自己，地球上是否有人会在您的应用中使用这样的地址。

40？猜猜你在一个正式讨厌 Facebook 代理电子邮件的开发者俱乐部（又名 - 应用程序 [e-mail]）。我实际上宣扬 90 的大小...有趣的是，它与您列表中的第一名很相配。

取决于电子邮件的用途。如果是针对用户，我同意，40，也许 50 就足够了。我刚做了一个测试，发现大多数在 17 到 25 岁之间。很少超过 40 岁。

多年来我使用了 120 个可变字符。现实世界的逻辑是，即使有人准备好填写您的 320 varchar 字段......我敢打赌他们有一个 40 字符的替代电子邮件就在旁边

【参考方案7】：

对于电子邮件，无论规范如何，我几乎总是使用 512 (nvarchar)。名字和姓氏相似。

确实，您需要看看您对拥有一点额外数据的关心程度。对我来说，大多数情况下，这不是一个担心，所以我会在保守的一面犯错。但是，如果您已通过合乎逻辑且准确的方式决定您需要节省空间，那么就这样做。但总的来说，对字段大小保持保守，生活应该会很好。

请注意，可能并非所有电子邮件客户端都支持 RFC，因此无论它说什么，您都可能会遇到不同的情况。

【参考方案8】：

如果您真的对此持怀疑态度，请创建用户名 varchar(60)、域 varchar(255)。然后，您可以对域使用情况进行荒谬的统计，这比将其作为单个字段执行要快一些。如果您对优化感到非常兴奋，那也将使您的 SMTP 服务器能够以更少的连接/更好的批处理发送电子邮件。

【讨论】：

s/gung?-ho(?:\s*about)?/dedicated to/