メールアドレスは基本的に無限に長くなる可能性があるため、varchar メールアドレスフィールドに課すサイズは任意になることを認識しています。しかし、「基準」とは何だろう?皆さん、どれくらいで出来ますか?(名前フィールドについても同じ質問...)
更新:どうやらメール アドレスの最大長は 320 です (<= 64 の名前の部分、<= 255 のドメイン)。これを使いますか?
メールアドレスは基本的に無限に長くなる可能性があるため、varchar メールアドレスフィールドに課すサイズは任意になることを認識しています。しかし、「基準」とは何だろう?皆さん、どれくらいで出来ますか?(名前フィールドについても同じ質問...)
更新:どうやらメール アドレスの最大長は 320 です (<= 64 の名前の部分、<= 255 のドメイン)。これを使いますか?
理論上の制限は非常に長いですが、これらの長いメールアドレスについて本当に心配する必要がありますか? 誰かが 100 文字のメールでログインできなくても、本当に気にしますか? 私たちは実際にはできないことを好みます。
一部の統計データは、この問題を明らかにする可能性があります。1,000 万を超える電子メール アドレスを含むデータベースを分析しました。これらのアドレスは確認されていないため、無効なものがあります。ここにいくつかの興味深い事実があります。
40 を超えるレコードを破棄して、DB をクリーンアップしました。良いニュースは誰も文句を言わなかったことですが、悪いニュースは多くのレコードがクリーンアップされなかったことです。
私は過去に 255 をやったことがあります。これは、短いが短すぎない入力の根深い標準だからです。それ、そして私は習慣の生き物です。
ただし、最大値は 319 であるためnvarchar(320)、列で行います。覚えなきゃ@!
nvarchar不要なスペースを使用しないため、20 文字のメール アドレスしかない場合でも、20 バイトしか使用しません。これは、常に最大値を使用する ancharとは対照的です(値の右側にスペースが埋め込まれます)。
Unicode であるためnvarchar、代わりに使用することもできます。varcharメールアドレスの変動性を考えると、これは間違いなく進むべき道です.
次の電子メール アドレスは 94 文字のみです。
i.have.a.really.long.name.like.seetharam.krishnapilai@AReallyLongCompanyNameOfSomeKind.com.au
92 歳の技術恐怖症でさえ、素敵な短い Gmail アドレスにサインアップする方法を理解し、登録ページにこれを入力するのではなく、それを使用するだけです。
ディスク容量はおそらく問題ではありませんが、ユーザー入力フィールドを必要以上に長くすることを許可することには、少なくとも 2 つの問題があります。
私は50文字が好きです:
123456789.123456789.123456789@1234567890123456.com
100 万人に 1 人のユーザーが私のアプリを使用するために他のメール アドレスを使用する必要があるとしたら、それはそれで構いません。
(統計によると、実際に電子メール アドレスに約 40 文字を超える文字を入力する人はいないことが示されています。たとえば、ZZ Coder の回答https://stackoverflow.com/a/1297352/87861を参照してください) 。
このテキストによると、適切な 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、ユーザー名の長さが将来 2 倍になると仮定) が提案されています。
この混乱は、「堅牢性の原則」に注意する必要があることを意味します (「開発者は、現存する RFC に厳密に従っているが、それらの RFC と一致しない可能性のあるピアからの入力を受け入れて解析するソフトウェアを慎重に作成する必要があります。」 - ウィキペディア) を扱うソフトウェアを作成する場合。メールアドレス。さらに、一部のソフトウェアは、たとえば 50 文字で十分であると考えるなど、単純な仮定によって機能しなくなる場合があります (例)。200 文字の電子メール アドレスは技術的には有効かもしれませんが、ほとんどの Web サイトやアプリケーションが拒否した場合は役に立ちません。
メールの実際の最大長は現在 254 文字です。
「RFC 3696 の元のバージョンでは、実際に 320 が最大長であると述べていましたが、John Klensin (ICANN) はその後、これは誤りであると認めました。」
「これは、ドメインの最大長 (255 文字) + メールボックスの最大長 (64 文字) + @ 記号 = 320 文字の単純な算術演算から生じます。間違っています。このカナードは、実際には RFC3696 の元のバージョンで文書化されています。正誤表で修正されました。実際には、SMTP トランザクションのパス要素は 256 文字であるという RFC5321 の制限があります。ただし、これには電子メール アドレスを囲む角括弧が含まれているため、電子メール アドレスの最大長は 254 文字です。」- ドミニク・セイヤーズ
私は varchar(64) を使用しています。
あなたが本当にそれについて懐疑的であるなら、ユーザー名 varchar(60)、ドメイン varchar(255) を作ってください。次に、単一のフィールドとして行うよりもわずかに高速な、ドメインの使用状況に関するばかげた統計を行うことができます。最適化について本当に熱心に取り組んでいる場合は、SMTP サーバーがより少ない接続数/より優れたバッチ処理でメールを送信できるようにもなります。
RFC 5321(現在のSMTP仕様、RFC2821は廃止)は次のように述べています。
4.5.3.1.1。ローカル部分
ユーザー名またはその他のローカル部分の最大全長は64
オクテットです。4.5.3.1.2。ドメイン
ドメイン名または番号の最大全長は255オクテットです。
これは、localpart @ domainのみに関係し、合計320文字のASCII(7ビット)文字になります。
ローカルパーツとドメインを別々のフィールドに分割するなどしてデータを正規化する場合は、次の点に注意してください。
メールの場合、仕様に関係なく、ほぼ常に 512 (nvarchar) を使用します。名前と苗字が似ています。
本当に、少し余分なデータを持つことをどれだけ気にするかを見る必要があります. 私にとって、ほとんどの場合、それは心配ではないので、保守的な側で誤ります. しかし、論理的かつ正確な方法でスペースを節約する必要があると判断した場合は、そうしてください。しかし、一般的には、フィールドのサイズを控えめにすれば、寿命は長くなります。
おそらくすべての電子メール クライアントが RFC をサポートしているわけではないことに注意してください。