SQL 电子邮件字段应该有多长？
我认识到电子邮件地址基本上可以无限长，因此我在 varchar 电子邮件地址字段上施加的任何大小都是任意的。 但我想知道“标准”是什么？ 你们能做多久？ （名称字段的问题相同...）
更新： 显然，电子邮件地址的最大长度为 320（<=64 名称部分，<= 255 域）。 你用这个吗？
I recognize that an email address can basically be indefinitely long so any size I impose on my varchar email address field is going to be arbitrary. However, I was wondering what the "standard" is? How long do you guys make it? (same question for Name field...)
update: Apparently the max length for an email address is 320 (<=64 name part, <= 255 domain). Do you use this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我使用 varchar(64) 我认为没有人可以拥有更长的电子邮件
I use varchar(64) i do not think anyone could have longer email
对于电子邮件，无论规格如何，我几乎总是使用 512 (nvarchar)。 名字和姓氏很相似。
实际上，您需要考虑一下您对拥有一些额外数据的关心程度。 对我来说，大多数情况下，这并不令人担心，所以我会犯保守的错误。 但如果您通过逻辑和准确的方式决定需要节省空间，那就这样做吧。 但总的来说，对场地大小保持保守，生活就会很好。
请注意，可能并非所有电子邮件客户端都支持 RFC，因此无论它说什么，您都可能会遇到不同的情况。
For email, regardless of the spec, I virtually always go with 512 (nvarchar). Names and surnames are similar.
Really, you need to look at how much you care about having a little extra data. For me, mostly, it's not a worry, so I'll err on the conservative side. But if you've decided, through logically and accurate means, that you'll need to conserve space, then do so. But in general, be conservative with field sizes, and life shall be good.
Note that probably not all email clients support the RFC, so regardless of what it says, you may encounter different things in the wild.
以下电子邮件地址只有 94 个字符：
i.have.a.really.long.name.like.seetharam.krishnapillai@AReallyLongCompanyNameOfSomeKind.com.au
即使是 92 岁的技术恐惧症患者也会想出如何注册一个漂亮的简短 Gmail 地址，然后使用它，而不是将其输入到注册页面中。
磁盘空间可能不是问题，但允许用户输入字段比所需长度长很多倍至少存在两个问题：
我喜欢 50 个字符：
[电子邮件受保护]
如果某个用户在百万必须使用他们的其他电子邮件地址才能使用我的应用程序，就这样吧。
（统计数据显示，实际上没有人输入超过 40 个字符的电子邮件地址，请参见例如：ZZ Coder 的答案 https://stackoverflow。 com/a/1297352/87861）
The following email address is only 94 characters:
i.have.a.really.long.name.like.seetharam.krishnapillai@AReallyLongCompanyNameOfSomeKind.com.au
Even a 92-year-old technophobe would figure out how to sign up for a nice short gmail address, and just use that, rather than type this into your registration page.
Disk space probably isn't an issue, but there are at least two problems with allowing user input fields to be many times longer than they need to be:
I like 50 chars:
[email protected]
If one user in a million has to use their other email address to use my app, so be it.
(Statistics show that no-one actually enters more than about 40 chars for email address, see e.g.: ZZ Coder's answer https://stackoverflow.com/a/1297352/87861)
如果您真的对此犹豫不决，请创建用户名 varchar(60)、域 varchar(255)。 然后，您可以对域使用情况进行荒谬的统计，这比作为单个字段进行统计要快一些。 如果您对优化非常着迷，这也将使您的 SMTP 服务器能够以更少的连接/更好的批处理发送电子邮件。
If you're really being pendantic about it, make a username varchar(60), domain varchar(255). Then you can do ridiculous statistics on domain usage that is slightly faster than doing it as a single field. If you're feeling really gun-ho about optimization, that will also make your SMTP server able to send out emails with fewer connections / better batching.
RFC 5321（当前 SMTP 规范，废弃 RFC2821）指出：
这仅涉及 localpart@domain，总共 320 个 ASCII（7 位）字符。
如果您计划规范化数据，也许可以通过将本地部分和域拆分为单独的字段，则需要记住其他事项：
RFC 5321 (the current SMTP spec, obsoletes RFC2821) states:
This pertains to just localpart@domain, for a total of 320 ASCII (7-bit) characters.
If you plan to normalize your data, perhaps by splitting the localpart and domain into separate fields, additional things to keep in mind:
我过去只做过 255，因为这是根深蒂固的短输入标准，但又不能太短。 那，我是一个习惯的生物。
但是，由于最大值为 319，我会在该列上执行
nvarchar(320)。 一定要记住@！nvarchar不会使用您不需要的空间，因此如果您只有 20 个字符的电子邮件地址，它只会占用 20 个字节。 这与nchar形成对比，后者总是占据其最大值（它用空格在值的右侧填充）。我还会使用
nvarchar代替varchar，因为它是 Unicode。 考虑到电子邮件地址的波动性，这绝对是正确的选择。I've in the past just done 255 because that's the so-ingrained standard of short but not too short input. That, and I'm a creature of habit.
However, since the max is 319, I'd do
nvarchar(320)on the column. Gotta remember the@!nvarcharwon't use the space that you don't need, so if you only have a 20 character email address, it will only take up 20 bytes. This is in contrast to ancharwhich will always take up its maximum (it right-pads the value with spaces).I'd also use
nvarcharin lieu ofvarcharsince it's Unicode. Given the volatility of email addresses, this is definitely the way to go.根据本文，基于正确的 RFC 文档，它不是 320，而是 254：
http://www.eph.co.uk/resources/email-地址长度常见问题解答/
编辑：
使用 WayBack 机器：
https： //web.archive.org/web/20120222213813/http://www.eph.co.uk/resources/email-address-length-faq/
According to this text, based on the proper RFC documents, it's not 320 but 254:
http://www.eph.co.uk/resources/email-address-length-faq/
Edit:
Using WayBack Machine:
https://web.archive.org/web/20120222213813/http://www.eph.co.uk/resources/email-address-length-faq/
理论上的限制确实很长，但您真的需要担心这些长电子邮件地址吗？ 如果有人无法使用 100 个字符的电子邮件登录，您真的在乎吗？ 我们实际上更希望他们不能。
一些统计数据可能会说明这个问题。 我们分析了一个包含超过 1000 万个电子邮件地址的数据库。 这些地址未经确认，因此存在无效地址。 这里有一些有趣的事实，
我们通过丢弃任何超过 40 的内容来清理数据库。好消息是没有人抱怨，但坏消息是没有多少记录被清理。
The theoretical limit is really long but do you really need worry about these long Email addresses? If someone can't login with a 100-char Email, do you really care? We actually prefer they can't.
Some statistical data may shed some light on the issue. We analyzed a database with over 10 million Email addresses. These addresses are not confirmed so there are invalid ones. Here are some interesting facts,
We cleaned up the DB by throwing away anything longer than 40. The good news is that no one has complained but the bad news is not many records got cleaned out.