メールアドレスの正規表現認識は難しいですか？
私は最近、標準のすべてのバリエーションと可能性を考慮に入れて、正規表現を電子メールアドレスと一致するように書くことは非常に難しく、最初に想定するよりもはるかに複雑であるとどこかで読みました。
誰かがそれがなぜであるかについていくつかの洞察を提供できますか？
実際にこれを完全に行う既知の実証済みの正規表現はありますか？
電子メールアドレスの照合に正規表現を使用する優れた代替手段は何ですか？
formal電子メール仕様の場合、はい、コメントなどの再帰（特に最初に空白へのコメントを削除しない場合）やさまざまな形式のため、正規表現では技術的に不可能です（電子メールアドレスは、常に[email protected]とは限りません）。あなたは（いくつかの巨大で理解できない正規表現パターンで）近づくことができますが、電子メールをチェックするはるかに良い方法は、非常に馴染みのあるハンドシェイクを行うことです：
- 彼らはあなたに彼らの電子メールを伝えます
- gUIDを使用して確認リンクを電子メールで送信します
彼らがリンクをクリックすると、あなたはそれを知っています：
- 電子メールは正しいです
- それが存在します
- 彼らはそれを所有しています
電子メールアドレスを盲目的に受け入れるよりもはるかに優れています。
これを行うPerlモジュールは（たとえば）いくつかあります。それを行うために独自の正規表現を作成しようとしないでください。見る
Mail::VRFY構文とネットワークチェックを行います（SMTPサーバーはどこかでこのアドレスを受け入れます）
https://metacpan.org/pod/Mail::VRFY
RFC::RFC822::Address-再帰下降メールアドレスパーサー。
https://metacpan.org/pod/RFC::RFC822::Address
Mail::RFC822::Address-正規表現ベースのアドレス検証、非常識な正規表現だけを探す価値があります
http://ex-parrot.com/~pdw/Mail-RFC822-Address.html
他の言語にも同様のツールが存在します。以下の非常識な正規表現...
(?:(?:\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*)
とにかく、電子メールアドレスの検証はあまり役に立ちません。構文的に有効なアドレスのように見える傾向があるため、一般的なタイプミスや作成された電子メールアドレスは検出されません。
アドレスが有効であることを確認したい場合は、確認メールを送信するしかありません。
ユーザーが「asdf」だけでなく電子メールのようなものを入力したことを確認したい場合は、@を確認してください。より複雑な検証では、実際には何のメリットもありません。
（これはあなたの質問に答えないことを私は知っていますが、とにかく言及する価値があると思います）
RFC-2822 の有効な電子メールアドレスを説明する文脈自由文法がBNFにあります。複雑です。例えば：
" @ "@example.com
有効なメールアドレスです。私はそれを完全に行う正規表現を知りません。通常与えられる例では、最初にコメントを削除する必要があります。私はそれを完全に一度行うために再帰下降パーサーを書きました。
Cal Henderson、Dave Child、Phil Haack、Doug Lovell、RFC 3696のテストケースを照合しました。全部で158のテストアドレス。
私はこれらすべてのテストを、見つけたすべてのバリデーターに対して実行しました。比較はここにあります： http://www.dominicsayers.com/isemail
人々がバリデーターを強化するので、私はこのページを最新の状態に保つように努めます。これらのテストのコンパイルと 私自身のバリデーター に対する建設的な批判に協力してくれたCal、Dave、Philに感謝します。
特に RFC 3696に対する正誤表 に注意する必要があります。正規の例のうち3つは、実際には無効なアドレスです。また、アドレスの最大長は254文字または256文字、not320です。
「+」などの文字を許可することは、スパムなどと闘うユーザーにとって非常に役立ちます。 [email protected]（ インスタント使い捨てGmailアドレス ）。
ただし、サイトがそれを受け入れる場合のみ。
奇妙で珍しい電子メールアドレス形式を受け入れるかどうかは、私の意見では、それらをどうしたいかによって異なります。
メールサーバーを作成している場合、受け入れる内容は非常に正確で、耐え難いほど正確でなければなりません。したがって、上記で引用した「非常識な」正規表現が適切です。
ただし、残りのユーザーは、主に、ユーザーがWebフォームに入力したものが妥当に見え、SQLインジェクションやバッファオーバーフローが発生しないようにすることに関心があります。
率直に言って、メーリングリスト、ニュースレター、またはWebサイトにサインアップするときに、誰かがコメント、改行、引用符、スペース、括弧、またはその他の意味不明なものを含む200文字のメールアドレスを入力できるようにすることを本当に気にしている人はいますか。このようなピエロへの適切な対応は、「[email protected]のようなアドレスを持っているときに後で戻ってくる」です。
私が行う検証は、@が1つだけあることを確認することです。スペース、ヌル、または改行がないこと。 '@'の右側の部分に少なくとも1つのドットがあります（ただし、2つのドットが連続していないこと）。また、引用符、括弧、コンマ、コロン、感嘆符、セミコロン、またはバックスラッシュがないこと。これらはすべて、実際の電子メールアドレスの一部よりもハッカーの試みである可能性が高いです。
はい、これは、誰かが私のWebサイトに登録しようとする可能性のある有効なアドレスを拒否していることを意味します。おそらく、実際のアドレスの0.001％を「誤って」拒否します。私はそれと一緒に暮らすことができます。
引用やその他のめったに使用されないがRFCの有効な部分は、それを困難にします。 「難しい」以外は、このトピックについて明確にコメントするのに十分な知識はありませんが、幸いなことに その他 人々は 書かれた それについて詳しく説明しています。
その有効な正規表現に関しては、Perl Mail :: Rfc822 :: Addressモジュールに 明らかに機能する正規表現 -が含まれていますが、コメントがすでに空白に置き換えられている場合に限ります。 （メールアドレスにコメントがありますか？予想以上に難しい理由がわかります...）
もちろん、他の場所にたくさんある単純化された正規表現は、実際に使用されているほぼすべての電子メールアドレスを検証します...
正規表現の一部のフレーバーは、ネストされた大括弧と実際に一致できます（Perl互換の大括弧など）。そうは言っても、RFC 822に正しく一致すると主張する正規表現を見たことがあり、空白のない2ページのテキストでした。したがって、有効な電子メールアドレスを検出する最良の方法は、それに電子メールを送信して、それが機能するかどうかを確認することです。
@mmaibaumによってリストされたものよりもクレイジーではない正規表現を追加するだけです：
^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)?@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$
それは防弾ではなく、確かに電子メールの仕様全体をカバーしているわけではありませんが、ほとんどの基本的な要件をカバーするというまともな仕事をしています。さらに良いことに、それはやや理解しやすく、編集することができます。
世界クラスのColdFusionリソースである HouseOfFusion.com でのディスカッションから削除されました。
Javaで電子メールアドレスをチェックする簡単で良い方法は、Apache Commons Validator ライブラリのEmailValidatorを使用することです。
私は、メールを送信する前に、入力フォームのメールアドレスをこのようなものと常に照合します。タイプミスがいくつかある場合でも同様です。 「配信に失敗しました」という通知メール用の自動スキャナーを作成したくない場合があります。 :-)
電子メールの仕様、 RFC 2822 に従って、電子メールアドレスで有効にできることがたくさんあるので、それは本当に難しいです。 +など、通常は表示されないものは、電子メールアドレスに対して完全に有効な文字です。仕様によると。
http://regexlib.com には、電子メールアドレスに関するセクション全体があり、優れたリソースです。自分にとって重要な基準を決定し、一致する基準を見つけることをお勧めします。ほとんどの人は、仕様で許可されているすべての可能性を完全にサポートする必要はありません。
.NET Frameworkで実行している場合は、MailAddressオブジェクトをインスタンス化し、それが爆発した場合はFormatExceptionをキャッチし、成功した場合はAddressを引き出してみてください。例外をキャッチするパフォーマンスについてナンセンスに陥ることなく（実際には、これが単一のWebフォーム上だけにある場合、それほど大きな違いはありません）、. NETフレームワークのMailAddressクラスは非常に完全な解析プロセス（RegExは使用しません）。 Reflectorを開いてMailAddressおよびMailBnfHelper.ReadMailAddress()を検索し、Reflectorが実行するすべての機能を確認します。私よりも賢い誰かがMicrosoftでパーサーを作成するのに多くの時間を費やしたので、実際にそのアドレスに電子メールを送信するときにそれを使用するので、受信アドレスの検証にも使用する可能性があります。
これを試してください：
"(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])"
詳細は こちら をご覧ください。
ただし、RFC822標準を実装するのではなく、別の視点から見た方がよいでしょう。メールサーバーが標準をミラーリングしない場合、標準が何を言っているかは重要ではありません。したがって、電子メールアドレスを検証するときに最も人気のあるメールサーバーが行うことを模倣する方がよいと私は主張します。
多くの人が試してみましたが、多くの人が近づいています。 ウィキペディアの記事 、および 一部その他 をお読みください。
具体的には、多くのWebサイトや電子メールサーバーが電子メールアドレスの検証を緩和しているため、基本的に標準を完全に実装していないことを覚えておく必要があります。ただし、電子メールが常に機能するのに十分です。
Javaのこのクラスにはバリデータが含まれています： http://www.leshazlewood.com/?p=2
これはShiroの作成者（正式にはKi、正式にはJSecurity）によって書かれました。
電子メールアドレスの有効性をテストすることの長所と短所：
電子メールを検証する正規表現には2つのタイプがあります。
- 緩すぎるもの。
厳しすぎるもの。
一部の文字列は有効な電子メールアドレスのように見えても実際には誰の受信トレイにも届かないため、正規表現がすべての有効な電子メールアドレスと一致し、無効な電子メールアドレスと一致することはありません。電子メールが実際に有効かどうかをテストする唯一の方法は、そのアドレスに電子メールを送信して、何らかの応答が返されるかどうかを確認することです。そのことを念頭に置いて、電子メールの照合が厳しすぎる正規表現は、実際にはあまり目的がないようです。
電子メールの正規表現を要求するほとんどの人は、最初のオプションである緩すぎる正規表現を探していると思います。彼らは文字列をテストして、それが電子メールのように見えるかどうかを確認したいと思っています。それが間違いなく電子メールではない場合は、ユーザーに次のように言うことができます。有効な電子メールではありません。このフィールドが電子メール用であるか、タイプミスがある可能性があることに気づかなかった可能性があります。」.
ユーザーが有効な電子メールのように見える文字列を入力しても、実際にはそうでない場合、それはアプリケーションの別の部分で処理する必要がある問題です。
Wayneの回答に加えて、電子メール専用の www.regular-expressions.info に関するセクションもあり、いくつかのサンプル。
それが価値があるかどうか、または実際にいずれか100％未満の正規表現をカバーすることは誤った安心感にのみ寄与するかどうかをいつでも疑問に思うことができます。
最後に、実際にsending電子メールは、実際の最終検証を提供するものです。 （-メールサーバーにバグがあるかどうかがわかります;-)
なぜそうなのかについて誰かが洞察を提供できますか？
はい、それは非常に複雑な標準であり、今日誰も実際に使用していない多くのものを許可します。 :)
実際にこれを完全に実行する既知の実証済みの正規表現はありますか？
これは、標準全体を完全に解析する1つの試みです...
http://ex-parrot.com/~pdw/Mail-RFC822-Address.html
メールアドレスの照合に正規表現を使用する代わりに良い方法はありますか？
使用している言語で既存のフレームワークを使用していると思いますか？それらはおそらく内部で正規表現を使用しますが。複雑な文字列です。正規表現は複雑な文字列を解析するように設計されているため、これが最善の選択です。
編集：リンクした正規表現はただの楽しみのためだったことを付け加えておきます。私はそのような複雑な正規表現の使用を推奨していません-一部の人々は「あなたの正規表現が複数行である場合、どこかにバグがあることが保証されている」と言います。標準がどれほど複雑かを説明するためにリンクしました。
この投稿を完全にするために、PHPには、電子メールを検証するための言語組み込み関数もあります。
PHP特定のEMAIL検証タイプでNicefilter_varを使用します:)
Phpでこれ以上の非常識な電子メール正規表現はありません：D
var_dump(filter_var('[email protected]', FILTER_VALIDATE_EMAIL));