電子メールの検証

電子メールを「正しく」検証することは、思っているよりも はるかに難しい問題です。 RFC 5322 はモンスターです。実際には、十分な パターンを選択します。 一般的なケースを受け入れ、明らかに間違っているケースを拒否します。

Pattern: ^[\w.+-]+@[\w-]+(?:\.[\w-]+)+$

• [\w.+-]+ -- ローカル部分: 文字、数字、_、.、+、-。
• @ -- 区切り文字。
• [\w-]+(?:\.[\w-]+)+ -- ドメイン + . で区切られた少なくとも 1 つの TLD。

受け入れられる内容: mario.rossi@example.com、foo+bar@sub.example.co.uk、 user_123@test-domain.io。

拒否するもの: mario@、@example.com、mario@example (TLD なし)、スペース。

トレードオフ

上記のパターンは次のものを受け入れません。

• 引用符で囲まれた文字列 "strange (things)"@example.com (RFC では許可されています)。
• Unicode 文字を含むドメイン (\u00fcber@m\u00fcnchen.de)。
• \w を通過しない非常に長い TLD (国際化されたものなど)。

必要な場合は、u フラグを使用してクラスを \p{L} に拡張するか、 専門的な図書館。

電子メール検証のトレードオフとベスト プラクティス

正規表現では、電子メール アドレスが実際に存在することを保証できません。過度に複雑なパターンはパフォーマンスを低下させ、異常ではあるが有効なドメインを除外します。単純な検証パターンを使用して、明らかなタイプミスを拒否し、検証コードを送信することをお勧めします。

試してみてください

復習演習

追加の課題