メールアドレスのフォーマットチェックは調べれば調べるほど「正しいメールアドレス」って何？究極なんでもいけんじゃね？と諦めたいですが、そのシステムの運用や使い方に適合すればいいんだと思います。毎回悩むのが面倒くさいので、いろいろな種類を集めておきます。
超ふわっと
@があればいける
^(.+)@(.+)$
それなりに
"とかIPアドレスとか無理だけどよく見るメアドはいける
^[\w.!#$%&'*+\/=?^_`{|}~-]+@[\w-]+(?:\.[\w-]+)*$
^(?:[\w!#$%&'*+\/\-=?^`{|}~]+(?:\.[\w!#$%&'*+\/\-=?^`{|}~]+)*)@(?:[a-zA-Z]+[a-zA-Z0-9-]*[a-zA-Z0-9](?:\.[a-zA-Z]+[a-zA-Z0-9-]*[a-zA-Z0-9])*(?:\.[a-zA-Z0-9]+))$
RFC822
- 英語のRFC822(Standard for the Format of Arpa Internet Text Messages)
- 日本語のRFC822
- 日本語のRFC2822(Internet Message Format)
- RFC 822 と RFC 2822 - あどけない話
- RFC822の正規表現(長い・・)
RFC822
address = mailbox ; one addressee
;または
phrase ":" [#mailbox] ";" ; named list
mailbox = local-part "@" domain ; simple address
;または
phrase "<" [route] local-part "@" domain ">" ; name & addr-spec
route = 1#("@" domain) ":" ; path-relative
local-part = word *("." word) ; uninterpreted 大文字小文字を区別しない
domain = sub-domain *("." sub-domain)
sub-domain = 1*<any CHAR except(除外する) specials, SPACE and CTLs>
; または
domain-literal
domain-literal = "[" *(dtext / quoted-pair) "]" ; DOMAIN-LITERALSの使用はあまり薦められません。
dtext = <any CHAR excluding(除く) "[", ; => may be folded
"]", "\" & CR, & including(を含む) linear-white-space>
addr-spec = local-part "@" domain ; global address
domain-ref = 1*<any CHAR except(除外する) specials, SPACE and CTLs>
group = phrase ":" [#mailbox] ";"
quoted-pair = "\" CHAR ; 任意の文字を引用できます
route-addr = "<" [route] addr-spec ">"
specials = ()<>@,;:\".[] ; 単語内で使用するには、quoted-stringで囲まれた文字列でなければなりません。
「RFC5321」「RFC5322」準拠
RFC5321とRFC5322で違反(ローカル部を「"」で囲むとOK)
# 先頭に「.」がある
.localPart@domain.co.jp
# 「@」の直前に「.」がある
localPart.@domain.co.jp
# ローカル部に「.」が連続している
localPart..@domain.co.jp
local..Part@domain.co.jp
# 半角英数字と「.!#$%&‘*+–/=?^_{|}~」以外を使っている
local[Part@domain.co.jp
local@Part@domain.co.jp
携帯電話のアドレスは準拠していないことがあります = 実際にはあるけど弾くかもね
- 日本語のRFC5321(Simple Mail Transfer Protocol)
- 日本語のRFC5322(Internet Message Format)
- 【Java初心者向け】メールアドレスの正規表現の書き方まとめ
「..@」はだめ？「"」でローカル部を囲んだらOKにする？ドメインはIPアドレスOK?コメントはNG?
ドメイン部分
ICANNは、ドット無しを前提としたトップレベルドメインの登録は現時点で認めていない。例えば、Googleが申請した search というドット無しトップレベルドメインの申請は棄却した。
ドット無しトップレベルドメイン
- 日本語のRFC1034(ドメイン部分)
- 「ドメインが正しい=テスト用じゃない」と考える場合は
example.comexample.netexample.orgはテスト用なので正しくなくなる
RFC1034
<domain> ::= <subdomain> | " " ;ドメイン名には大文字も小文字も許されるが、それには重要な違いがないことに注意してほしい。つまり、同じつづりで大文字・小文字の異なる二つの名前は同じ物として扱われるということである。
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] ;ラベルは ARPANET のホスト名の規則にしたがわなければならない。ラベルは文字で始まり、文字または数字で終わり、間には文字・数字・ハイフンだけが含まれなければならない。ラベルの長さにも制約があり、63 文字以下でなければならない。
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= 大文字の A から Z と小文字の a から z の、アルファベット52 文字の内の任意の一文字
<digit> ::= 0 から 9 までの 10 個の数字の内の任意の一文字
ドメイン部分にIPアドレスを書くときの決まり
RFC5321
IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str
; Standardized-tag はスタンダードトラック RFC に ; おいて規定され、IANA に登録されなければならない
; (MUST)
dcontent = %d33-90 / ; Printable US-ASCII
%d94-126 ; excl. "[", "\", "]"
Snum = 1*3DIGIT ; 0 ～ 255 までの 10 進整数値を表す
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG ;HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"小文字の "a", "b", "c", "d", "e", "f"もOKなので[1-9a-fA-F]的な感じ by RFC2234のCore Rules
IPv6-full = IPv6-hex 7(":" IPv6-hex)
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::"
[IPv6-hex *5(":" IPv6-hex)] ; "::" は、値ゼロの 16 ビットグループが少なくとも2 つあることを表す。"::" に加えて高々 6 グループが現れる可能性がある。
;IPv4 マップ式 IPv6 アドレス------------------------------------------------------------
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
[IPv6-hex *3(":" IPv6-hex) ":"]
IPv4-address-literal ; "::" は、値ゼロの 16 ビットグループが少なくとも2 つあることを表す。"::" と IPv4-address-literalとに加えて高々 4 グループが現れる可能性がある。
正規表現がわからなすぎるときは誰かに頼ってみる
- 正規表現がわからないから見たいリンク集 - Qiita
- HTML5ならRFC完全準拠じゃないけどに頼ってみる
- Javaなら「RFC822」だけどInternetAddressに頼ってみる
- PHPなら「RFC822」だけどmailparse_rfc822_parse_addressesに頼ってみる
- C#ならMailAddressに頼ってみる
入力チェック以外も気にしておく
入力チェックができても他のところでハジケルこともあります。
- メールアドレスをCSV出力することがある？「,」「"」は気になるところ
- DBのカラムサイズに合っている？
- メールを送信する処理で何を使うかによって入力チェックOKでも送信できないこともあります。
メールアドレスのフォーマットを考えるときに参考にしたいサイト
- RFC違反メールアドレスを知っていますか？ : ビジネスとIT活用に役立つ情報
- 結局 "メールアドレスの規格" ってどこ？ - Qiita
- 「メールアドレスのルール」なんて使ってはいけない3つの理由 - めもおきば
- 入力バリデーションはセキュリティ対策として＊あてにする＊ものではありません – yohgaki's blog
- 正規表現によるメールアドレスチェックの正解がわからないので、自己責任で。 | doli blog
- 正しいメールアドレスを入力させるのは至難