メールアドレス検証の正規表現 — パターンとベストプラクティス
メールアドレス検証のための実用的な正規表現パターンと解説。基本パターンと堅牢なパターン、RFC 5322の考慮事項、正規表現 vs 他の方法の使い分けをカバー。
Common Patterns
詳細な説明
正規表現によるメールアドレス検証
メールアドレス検証は最も一般的な正規表現のユースケースのひとつですが、最も誤解されやすいもののひとつでもあります。ここでは実用的なアプローチを紹介します。
基本パターン
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}
このパターンは実際のメールアドレスの大半をカバーします：
| トークン | マッチ対象 |
|---|---|
[a-zA-Z0-9._%+-]+ |
ローカルパート（@の前） |
@ |
リテラルの@記号 |
[a-zA-Z0-9.-]+ |
ドメイン名 |
\.[a-zA-Z]{2,} |
トップレベルドメイン（.com、.orgなど） |
このパターンが処理できるもの
- 標準的なメール：
user@example.com - ドットとハイフン：
first.last@sub-domain.example.com - プラスアドレッシング：
user+tag@gmail.com - 新しいTLD：
user@example.technology
このパターンが見逃すもの
RFC 5322の完全なメール仕様は極めて複雑で、単一の正規表現でキャプチャすることは実質的に不可能です。エッジケースには以下が含まれます：
- 引用符付きローカルパート：
"user name"@example.com - IPアドレスドメイン：
user@[192.168.1.1] - 国際化ドメイン名（IDN）
ベストプラクティス
- クライアントサイド検証にはシンプルな正規表現を使用 — 明らかなタイプミスをキャッチ
- 確認メールを送信 — 唯一の真の検証方法
- 有効なアドレスを拒否しない — 過度に厳格なパターンはユーザーを困らせます
- HTML5の input type="email" の使用を検討 — 最初の検証レイヤーとして
ユースケース
送信前にタイプミスをキャッチするためにクライアントサイドのメールアドレス検証が必要なフォームを構築する場合、またはテキストブロックから正規表現検索でメールアドレスを抽出する場合。