web-dev-qa-db-ja.com

メールアドレスに使用できる文字は？

私は完全なEメール検証について質問していません。

電子メールアドレスのuser-nameとserverの部分に何が許されているのか知りたいだけです。これは過度に単純化されているかもしれません、おそらく電子メールアドレスは他の形をとることができますが、私は気にしません。私はこの単純な形式についてのみ質問しています：user-name@server（例えば[email protected]）そして両方の部分で文字を許可しました。

formsemailemail-validationemail-address
535
WildWezyr

RFC 5322：インターネットメッセージフォーマット 、および程度は低いものの、 RFC 5321：Simple Mail Transfer Protocol 。

RFC 822 も電子メールアドレスを扱いますが、その構造のほとんどを扱います。

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  Word *("." Word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

そして、いつものように、ウィキペディアにはメールアドレスに関する記事 があります ：

電子メールアドレスのローカル部分では、これらのASCII文字のいずれかを使用できます。

  • 大文字および小文字のラテン文字AからZおよびaからz;
  • 数字0から9;
  • 特殊文字!#$%&'*+-/=?^_`{|}~;
  • ドット.。ただし、引用符で囲まれていない限り最初または最後の文字ではなく、引用符で囲まれていない限り連続して表示されない（たとえば、[email protected]は許可されないが"John..Doe"@example.comは許可される）。
  • スペースおよび"(),:;<>@[\]文字は制限付きで許可されます（以下の段落で説明するように、引用符付き文字列内でのみ許可され、さらに、円記号または二重引用符の前に円記号が必要です）。
  • ローカル部分の両端に括弧を付けてコメントを許可します。例えばjohn.smith(comment)@example.comと(comment)[email protected]は、どちらも[email protected]と同等です。

ASCII文字に加えて、 2012 の時点で、上記の国際 文字を使用できますU+007F、 RFC 6532 spec で説明され、 ウィキペディア 。 2019年現在、これらの規格はまだ提案済みとしてマークされていますが、徐々に展開されています。この仕様の変更により、!#や@:などの許可および制限された特殊文字の規則に影響を与えることなく、基本的に有効な英数字（テキスト）として国際文字が追加されました。

検証については、 を参照してください。正規表現を使用してメールアドレスを検証します 。

domain部分は、次のように定義されます：

プロトコルのインターネット標準（Request for Comments）では、コンポーネントのホスト名ラベルには、ASCII文字aからz（大文字と小文字を区別しない）、数字0のみを含めることができます。 9、およびハイフン（-）を使用します。 RFC 952 のホスト名の元の仕様では、ラベルを数字またはハイフンで開始することはできず、ハイフンで終了することはできませんでした。ただし、後続の指定（ RFC 1123 ）では、ホスト名ラベルを数字で開始することが許可されていました。他の記号、句読点、または空白は許可されません。

727
Anton Gogolev

気を付けて！このスレッドには多くの知識の腐敗があります（以前は真実でしたが、現在はそうではありません）。

現在および将来の世界および世界のどこからでも実際の電子メールアドレスの誤検出拒否を回避するには、少なくとも RFC 3490 の高レベルの概念を知る必要があります。 、「アプリケーションのドメイン名の国際化（IDNA）」。アメリカとAの人々はしばしばこれに気付いていないことを知っていますが、すでに世界中で広く普及しており、急速に増加しています（主に非英語が支配的な部分）。

要点は、mason @日本.comやwildwezyr@fahrvergnügen.netなどのアドレスを使用できるようになったことです。いいえ、これはまだすべてのものと互換性がありません（上記の多くが嘆いているように、単純なqmailスタイルの+ identアドレスでさえ、しばしば誤って拒否されます）。しかし、RFCがあり、仕様があり、IETFとICANNに後押しされています。さらに重要なことですが、現在使用されているこの改善をサポートする実装が多数あります。

日本に戻ってhei @やる.caのような電子メールアドレスと次のようなAmazon URLを見始めるまで、私はこの開発についてあまり知りませんでした。

http://www.Amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/ b/ref = topnav_storetab_e？ie = UTF8＆node = 3210981

仕様へのリンクが必要ないことはわかっていますが、インターネットフォーラムのハッカーに関する古くからの知識だけに依存している場合、メール検証ツールは、英語を母国語としないユーザーがますます期待しているメールアドレスを拒否することになります。それらのユーザーにとって、そのような検証は、私たち全員が嫌いな普通の脳死型、+または3つの部分からなるドメイン名などを処理できないものと同じくらい迷惑です。

だから、面倒ではないとは言っていませんが、「一部/任意/なしの条件で許可される」文字の完全なリストは、（ほぼ）すべての言語のすべての文字です。 「すべての有効な電子メールアドレス（および多くの無効な電子メールアドレスも）を受け入れる」場合は、IDNを考慮する必要があります。これにより、最初に 変換しない限り、基本的に文字ベースのアプローチは役に立たなくなります（ごめん）国際化されたメールアドレス から Punycode へ。

それを行った後、あなたは上記のアドバイスのほとんどに従うことができます。

296
Mason

Eメールアドレスのフォーマットはlocal-part@domain-part（最大64 @ 255文字、合計256以下）です。

local-partとdomain-partは、許可される文字のセットが異なる場合がありますが、それ以上の規則があるため、それだけではありません。

一般に、ローカル部分はこれらのASCII文字を持つことができます。

  • 小文字のラテン文字：abcdefghijklmnopqrstuvwxyz、
  • 大文字のラテン文字：ABCDEFGHIJKLMNOPQRSTUVWXYZ、
  • 数字：0123456789、
  • 特殊文字：!#$%&'*+-/=?^_`{|}~、
  • ドット：.（引用符で囲まれていない限り、先頭または末尾の文字ではない、または繰り返されない）、
  • "(),:;<>@[\]（いくつかの制限付き）のようなスペース句読点、
  • コメント：()（(comment)[email protected]など、括弧内に使用できます）。

ドメイン部

  • 小文字のラテン文字：abcdefghijklmnopqrstuvwxyz、
  • 大文字のラテン文字：ABCDEFGHIJKLMNOPQRSTUVWXYZ、
  • 数字：0123456789、
  • ハイフン：-（最初または最後の文字ではありません）、
  • 角括弧で囲まれたIPアドレスを含めることができます：jsmith@[192.168.2.1]またはjsmith@[IPv6:2001:db8::1]。

これらの電子メールアドレスは有効です。

そしてこれらの例は無効です：

  • Abc.example.com（@文字なし）
  • A@b@[email protected]（引用符の外側には@を1つだけ指定できます）
  • a"b(c)d,e:f;gi[j\k][email protected]（このローカル部分の特殊文字は、引用符の外側には使用できません）
  • just"not"[email protected]（引用符で囲まれた文字列はドットで区切られるか、ローカル部分を構成する唯一の要素である必要があります）
  • this is"not\[email protected]（スペース、引用符、およびバックスラッシュは、引用符で囲まれた文字列内で、バックスラッシュが前にある場合にのみ存在できます）
  • this\ still\"not\[email protected]（エスケープ（前にバックスラッシュが付いていても）、スペース、引用符、およびバックスラッシュが引用符で囲まれていても）
  • [email protected]（@の前の二重ドット）; （警告付き：Gmailはこれを通過させます）
  • [email protected]（@の後の二重ドット）
  • 先頭にスペースがある有効なアドレス
  • 末尾にスペースがある有効なアドレス

出典： 電子メールアドレス ウィキペディアで

PerlのRFC2822正規表現 Eメールの検証用：

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

RFC2822アドレスの完全な正規表現はたったの3.7kでした。

PHP のRFC 822 Email Address Parserも参照してください。

電子メールアドレスの正式な定義は次のとおりです。

  • RFC 5322（セクション3.2.3および3.4​​.1、RFC 2822を廃止）、RFC 5321、RFC 3696、
  • RFC 6531（許可されている文字）.

関連する

37
kenorb

ウィキペディアにこれに関する良い記事があります 、および 公式の仕様はこちら です。ウィキペディアより

電子メールアドレスのローカル部分には、これらのASCII文字を使用できます。

  • 大文字と小文字の英字（a-z、A-Z）
  • 0から9までの数字
  • キャラクター！ ＃$％＆ '* + - /=？ ^ _ `{| 〜
  • キャラクター 。 （ドット、ピリオド、フルストップ）は、それが最初または最後の文字ではないこと、およびそれが2回以上連続して表示されないことを条件とします。

さらに、引用符で囲まれた文字列（例： "John Doe" @ example.com）が許可されているため、他の方法では禁止されている文字も許可されますが、一般的には表示されません。 RFC 5321はまた、「メールを受信することを期待しているホストは、Local-partが引用文字列形式を必要とする（または使用する）メールボックスの定義を避けるべきである」と警告している。

21
Mike Weller

ウィキペディアの記事 ：から始めることができます。

  • 大文字と小文字の英字（a-z、A-Z）
  • 0から9までの数字
  • キャラクター！ ＃$％＆ '* + - /=？ ^ _ `{| 〜
  • キャラクター 。 （ドット、ピリオド、フルストップ）は、それが最初または最後の文字ではないこと、およびそれが2回以上連続して表示されないことを条件とします。
12
Vladimir

グーグルは彼らのgmail.comアドレスでおもしろいことをする。 gmail.comのアドレスでは、文字（a〜z）、数字、およびピリオド（これらは無視されます）のみが許可されます。

たとえば、pikachu @ gmail.comは[email protected]と同じであり、両方の電子メールアドレスが同じメールボックスに送信されます。 [email protected]も同じメールボックスに配信されます。

だから質問に答えるために、時々それは彼らが従うことを望んでいるRFC規格のうちどれくらいに関する実装者に依存します。 Googleのgmail.comアドレススタイルは標準と互換性があります。彼らは、異なる人々が同じようなEメールアドレスを使うという混乱を避けるためにそうしています。

*** gmail.com accepting rules ***
[email protected]   (accepted)
[email protected]   (bounce and account can never be created)
[email protected]     (accepted)
D.Oy'[email protected]   (bounce and account can never be created)

ウィキペディアのリンクは、電子メールアドレスで一般的に許可されているものに関する優れた参考文献です。 http://en.wikipedia.org/wiki/Email_address

12
Angel Koh

名：

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

サーバ：

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.
11
ThinkingStiff

@とを確認してください。確認のためにメールを送信します。

誰かが彼らの電子メールの検証を台無しにした、またはそれが有効であることを前にしているので、私はまだインターネット上のサイトの20％で私の.name電子メールアドレスを使うことができません。

9
Richard Maxwell

受け入れられた答えは、電子メールアドレスの有効なローカル部分について議論するときのウィキペディアの記事を参照していますが、ウィキペディアはこれに関する権威ではありません。

IETF RFC 3696は権限である _この件に関しては、 3のセクションで相談すべきです。3.電子メールアドレスの制限 5ページ：

現代の電子メールアドレスはアットマーク（ "@"）で "ドメイン部分"（完全修飾ドメイン名）から分離された "ローカル部分"で構成されています。ドメイン部分の構文は、前のセクションの構文に対応しています。そのセクションで識別されたフィルタリングおよび名前のリストに関する懸念は、Eメールのコンテキストで使用されるドメイン名にも当てはまります。ドメイン名は角括弧内のIPアドレスで置き換えることもできますが、テストとトラブルシューティングの目的を除いて、その形式はお勧めできません。

ローカル部分は、下記の引用規約を使用して表示されることがあります。引用形式は実際にはめったに使用されませんが、正当な目的のために必要とされます。したがって、それらはフィルタリングルーチンで拒否されるべきではなく、代わりに宛先ホストによる評価のために電子メールシステムに渡されるべきです。

厳密な規則として、制御文字を含むすべてのASCII文字は、引用符で囲んで、または引用符で囲まれた文字列で表示できます。引用符が必要な場合は、円記号を使用して次の文字を引用符で囲みます。例えば

  Abc\@[email protected]

電子メールアドレスの有効な形式です。のように空白も表示されることがあります。

  Fred\ [email protected]

バックスラッシュ文字は、それ自体を引用するためにも使用できます。

  Joe.\\[email protected]

バックスラッシュ文字を使用した引用符に加えて、従来の二重引用符文字を使用して文字列を囲むことができます。例えば

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

上記の最初の2つの例の代替形式です。これらの引用形式はめったに推奨されず、実際には一般的ではありませんが、上記のように、電子メールアドレスを処理しているアプリケーションでサポートされている必要があります。特に、引用形式は他のシステムやコンテキストからの移行に関連するアドレスのコンテキストで現れることが多い。これらの移行要件は依然として発生し、ユーザー提供のEメールアドレスを受け入れるシステムはそのアドレスがレガシーシステムに関連付けられているかどうかを「知る」ことができないので、アドレスフォームを受け入れてEメール環境に渡す必要があります。

引用符がないと、ローカル部分は次のものの任意の組み合わせで構成されます。
英字、数字、または任意の特殊文字

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

ピリオド（ "。"）も表示されることがありますが、ローカル部分の開始または終了には使用できません。また、2つ以上の連続したピリオドが表示されることもありません。別の言い方をすると、アットマーク（ "@"）、バックスラッシュ、二重引用符、コンマ、または角括弧以外のASCIIグラフィック（印刷）文字は引用符なしで表示されることがあります。除外文字のリストが表示される場合は、引用符で囲む必要があります。のような形

  [email protected]

  customer/[email protected]

  [email protected]

  !def!xyz%[email protected]

  [email protected]

有効であり、かなり定期的に見られますが、上記の文字はすべて許可されています。

他の人がやったように、私はPHPとJavaScriptの両方に有効な正規表現を送信して、Eメールアドレスを検証します。

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i
5
Mac

matter についての良い記事。

抜粋：

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/[email protected]
\[email protected]
!def!xyz%[email protected]
[email protected]
5
Luke Madhanga

簡単な答えは2つの答えがあるということです。あなたがすべきことには一つの基準があります。すなわち賢明であなたをトラブルから守る行動。問題を起こさずに受け入れるべき振る舞いのための別の（もっと広い）標準があります。この二重性は電子メールの送受信には有効ですが、実際には幅広い用途があります。

あなたが作成したアドレスへの良いガイドとして。参照してください： http://www.remote.org/jochen/mail/info/chars.html

有効なEメールをフィルタリングするには、次のステップを見るのに十分理解できるものをすべて渡します。あるいは、たくさんのRFCを読み始めましょう。

5
Michael JAMES

わかりやすくするために、検証前に二重引用符内のテキストとそれに関連する二重引用符のテキストをすべて削除し、許可されていないものに基づいて電子メールアドレスの送信を禁止します。誰かがジョンを持つことができるという理由だけで... "* $ hizzle * Bizzle" .. [email protected]アドレスは私が私のシステムでそれを許可しなければならないという意味ではありません。私たちは将来あなたのお尻を拭く良い仕事をするよりも無料の電子メールアドレスを取得するのにかかる時間が少なくて済むように生きています。そしてそれはあたかも電子メールの基準が入力のすぐ隣に塗りつぶされていないかのようにではなく、何が許可されているのかということではありません。

また、引用された資料が削除された後で、さまざまなRFCで特に許可されていないものをサニタイズします。特に許可されていない文字やパターンのリストは、テストするにはもっと短いリストのようです。

許可しない：

    local part starts with a period ( [email protected] )
    local part ends with a period   ( [email protected] )
    two or more periods in series   ( [email protected] )
    &’`*|/                          ( some&thing`[email protected] )
    more than one @                 ( which@[email protected] )
    :%                              ( mo:characters%mo:[email protected] )

与えられた例では：

John.."The*$hizzle*Bizzle"[email protected] --> [email protected]

[email protected] --> [email protected]

電子メールアドレスを追加または変更しようとしたときに、残った結果に確認の電子メールメッセージを送信すると、送信した電子メールアドレスをコードで処理できるかどうかを確認するのに適した方法です。必要な回数のサニタイズの後に電子メールが検証に合格した場合は、その確認を無効にします。確認リンクからリクエストが戻ってきた場合は、新しいEメールを保留中の||一時的||煉獄のステータスまたは保管場所から移動して、本物の、本物のファーストクラスの保管Eメールにすることができます。

思いやりがある場合は、Eメールアドレス変更の失敗または成功の通知を古いEメールアドレスに送信できます。未確認のアカウント設定は、妥当な時間の後に完全に失敗した試みとしてシステムから外れる可能性があります。

私は自分のシステムに悪臭を放つ電子メールを許可していません。多分それはお金を捨てているだけかもしれません。しかし、99.9％の人が正しいことをして、Edgeのケースの互換性シナリオを利用して、適合性を限界に近づけない電子メールを持っているだけです。正規表現DDoSに注意してください、これはあなたが問題に巻き込まれる可能性がある場所です。そしてこれは私が3番目にすることと関係しています、私は私がどの1つのEメールを処理しても構わないと思っている時間に制限を置きます。検証を受けるために私のマシンの速度を落とす必要がある場合 - それは私の受信データAPIエンドポイントロジックを通り過ぎていません。

編集：この答えは "悪い"であるために騙され続けていた、そしておそらくそれはそれに値する。多分それはまだ悪い、多分ないです。

0
BradChesney79

その答えは（ほぼ）ALL（7-bit ASCII）です。
包含規則が「.../any/none条件で許可されています...」である場合

17ページの一番上にある RFC 5322 の「ドメインテキスト」の部分で許可されているテキストについて、いくつか考えられる包含ルールの1つを見ると、次のようになります。

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

この説明で欠けている3つの文字だけが、引用符で囲まれたペアの[]と空白文字（％d32）を形成するために、ドメインリテラル\で使用されています。それによって全体の範囲32-126（10進数）が使用されます。同様の要件は、 "qtext"および "ctext"として現れます。多くの制御文字も許可/使用されています。そのような制御文字の1つのリストは、RFC 5322のページ31 セクション4.1にあります obs-NO-WS-CTL。

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

これらの制御文字はすべて、セクション3.5の冒頭で述べたように許可されています。

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

そして、そのような包含規則は、それ故に「広すぎます」。あるいは、別の意味では、期待される規則は「単純すぎる」ということです。

0
user2350426