我认识到电子邮件地址基本上可以无限长,所以我在varchar电子邮件地址字段上施加的任何大小都是任意的.但是,我想知道"标准"是什么？你们有多长时间制作它？(姓名字段的相同问题......)
更新:显然,电子邮件地址的最大长度为320(<= 64名称部分,<= 255域).你用这个吗？
理论上的限制真的很长,但你真的需要担心这些长的电子邮件地址吗？如果有人无法使用100-char电子邮件登录,您真的关心吗？我们实际上更喜欢他们不能.
一些统计数据可能会对这个问题有所了解.我们分析了一个拥有超过1000万个电子邮件地址的数 这些地址未得到确认,因此存在无效地址.这是一些有趣的事实,
有效期最长的是89.
我们的列(255)有数百个较长的,但它们显然是通过视觉检查伪造的.
长度分布的峰值为19.
没有长尾巴.38后,一切都急剧下降.
我们通过丢弃超过40的任何东西来清理数据库.好消息是没有人抱怨,但坏消息是没有很多记录得到清理.
我过去刚刚做了255,因为这是如此根深蒂固的短暂但不太短的输入标准.那,我是一个习惯的生物.
但是,由于最大值是319,我会nvarchar(320)在列上做.要记住了@!
nvarchar不会使用您不需要的空间,因此如果您只有20个字符的电子邮件地址,则只占用20个字节.这是相对于一个nchar将始终占据其最大(它的权利垫用空格值).
我也用它nvarchar代替,varchar因为它是Unicode.鉴于电子邮件地址的波动性,这绝对是可行的方法.
以下电子邮件地址仅为94个字符:
i.have.a.really.long.name.like.seetharam.krishnapillai@AReallyLongCompanyNameOfSomeKind.com.au
组织实际上会给你一封很长的电子邮件吗？
如果他们足够愚蠢,你真的会使用这样的电子邮件地址吗？
请问有人吗？当然不是.打字太长,难以记住.
即使是一个有着92年历史的技术专家也会想出如何注册一个不错的短邮件地址,而只是使用它,而不是在你的注册页面输入.
磁盘空间可能不是问题,但允许用户输入字段比它们需要的时间长许多至少有两个问题:
显示它们可能会弄乱你的用户界面(充其量它们会被切断,最糟糕的是它们会推动你的容器和边缘)
恶意用户可以使用您无法预料的事情(例如黑客使用免费在线API存储大量数据的情况)
我喜欢50个字符:
123456789.123456789.123456789@1234567890123456.com
如果百万用户中的一个用户必须使用他们的其他电子邮件地址来使用我的应用程序,那就这样吧.
(统计数据显示,实际上没有人为电子邮件地址输入超过40个字符,例如:ZZ Coder的答案/sf/ask/17360801/)
京公网安备 11010802040832号 | 京ICP备19059560号-6 