ぼくのかんがえたさいきょうのメールアドレス正規表現

Microsoft Purview
スポンサーリンク

目的

正規表現でメールアドレスを判別するための表記方法は明確に定まっている標準規格が無い(と思っている)。 妥当な表記方法を検討するため、メールアドレスの仕様と主要なメールサービスの運営状況を鑑みて最適な方法を検討する。

調査対象

  • メールアドレスの構成を定めた規格
  • 一般メールサービスにおけるメールアドレスの構成

結論

ぼくのかんがえたさいきょうのメールアドレス正規表現

これだ。

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

調査内容

メールアドレスに関するRFC

メールアドレスのフォーマットはRFCで定義されており、次の表記で示される。 送信目線(RFC 5321)では メールボックス と呼ばれ、受信目線(RFC 5322)では addr-spec と呼ばれる。

local-part @ domain

メールアドレスのフォーマットを規定するRFC

RFCで定めるメールアドレス文字数の制限

  • 全体の文字数: 最大254文字
  • local-partの文字数: 最大64文字
  • domainの文字数: 最大253文字

local-partに使える文字の種類

local-partでは次の種類の文字を使用できる。

  1. どの位置でも使える文字:81文字
    1. 半角英字(52文字): A~Z, a~z
    2. 数字(10文字): 0~9
    3. 記号(19文字): ! # $ % & ' * + - / = ? ^ _ ` { | } ~
  2. 先頭と末尾以外、かつ連続しなければ使える文字:1文字
    1. 記号(1文字): . (ドット)
  3. "" で括った形式(quoted-string)と使える文字:92文字
    1. 1.のどの位置でも使える文字:81文字
    2. . (ダブルクォート内では連続で使用可能)
    3. 記号(10文字): ( ) , : ; < > @ [ ]
  4. quoted-string、かつバックスラッシュ \ を直前に付けると使える文字:95文字
    1. 3.のダブルクォート (") で括ると使える文字:93文字
    2. 記号(2文字): " (スペース)

domainに使える文字の種類

domain部は一般的なドメインを示すため、ドメイン名の構成ルールに従う。 ドメイン名の構成では. (ドット)で区切られた部分を ラベル と呼ぶ。

一番右側のラベルは TDL(トップレベルドメイン) と呼ばれる、国際標準化されているドメインが入る。 それ以降の左にあるラベルは、順に”第2レベルドメイン”・”第3レベルドメイン”・”第4レベルドメイン”と続いていく。

では次の種類の文字を使用できる。 なお、一般的なドメインの構成に従うため、末尾にはトップレベルドメインとして2文字以上の英字が続く。

  1. 半角英数字
  2. . (ドット)
  3. - (ハイフン)

なお、一般的なドメインとしては全角文字も利用できるが、一般的な利用として普及はしていないためメールアドレスの判定としては考慮しないものとする。

一般メールサービスでの実装

一般的なメールサービスが上述のようなRFCに準拠した実装となっているのか調査した。

結果として、厳格に準拠しているものはなく、独自の制限を設けていることが多かった。

Yahoo!メール

Yahoo!メール(メールアカウント)で利用可能な文字は次のとおりである。

  • 使用可能な文字
    • 半角英字:A~Z、a~z(先頭は小文字のみ)
    • 数字:0~9
    • 記号:_ (先頭および末尾では使用できない)
  • 文字数の制限:4~31文字
参考リンク

Gmail

Gmail(Googleアカウント)で利用可能な文字は次のとおりである。

  • 使用可能な文字
    • 半角英字:A~Z、a~z
    • 数字:0~9
    • 記号:. (連続しての使用は不可)
  • 文字数の制限:6~30文字

なお、Gmailではメールアドレスのユーザー名部分にピリオドがあっても無視して判定されるほか、+でエイリアスを追加もできる。

参考リンク

local-part部の検討

RFCではlocal-part部で使える文字として広く利用されている文字以外も許容されている。

しかしながら、一般的なメールサービスではセキュリティ等の観点からRFCに沿ってすべての記号文字を許容していることは少ない。 また、quoted-string形式の表記は相互運用性を妨げるため、利用を避けるべきであるとRFCでも記載される。

そのため、local-part部としては使える文字種類であげた1.と2.を考慮すれば最低限の一般利用範囲をカバーできると考える。 よって、次の正規表現を検討する。

^[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+(\.[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+)*

詳細解説

local-part部の正規表現について、各部分を解説する。

前半部分は、local-part部の先頭が.(ドット)以外の文字になるための表記である。

^[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+

後半部分は、.(ドット)が連続せず、かつ末尾にも出現しないように考慮した表記である。

(\.[a-zA-Z0-9!#$%&'*+\/=?^_`{|}~-]+)*

domain部の検討

domain部は、一般的なドメインの表記を検知できるよう検討する。 また、全角文字の表記は考慮しないものとする。

([a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*\.)*[a-zA-Z]{2,}$

詳細解説

domain部の正規表現について、各部分を解説する。 大きくTLDと第2レベルドメイン以降の構成で分けて検討する。

末尾はTLDを示す。 TLDは国際標準で管理されており、英字2文字以上で構成される。

[a-zA-Z]{2,}$

第2レベルドメイン以降は- (ハイフン)が連続せず、かつラベルの先頭末尾にも出現しないように考慮した表記である。

([a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*\.)*

検証

正規表現

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

OKなメールアドレス

hoge@example.com
hoge.foo@example.com
hoge!foo@example.com
-hoge-@example.com
hoge@test.example.com
hoge@test-demo.example.com

NGなメールアドレス

.hoge@example.com
hoge.@example.com
hoge..foo@example.com
hoge@exa--mple.com
hoge@.example.com

こちらのサイトをお借りして正規表現の動作を確認する。

正規表現チェッカー

結び

今回はメールアドレスを検出するための正規表現を検討した。 メールアドレスはインターネット黎明期から運用されているものの、厳格な仕様に沿った実装をされているケースは少なく、メールサービスプロバイダーによって制限された実装内容に従う必要があるという実状であった。

日本国内でもDocomoやauが2000年代初頭までRFC違反のメールアドレスを許容していた経緯があり、それらのビジネスニーズを損なわないように過度なシステム的拒否は忌避されていたが、2010年代後半からそういった事情を鑑みてもサービス単位で送受信を受容しないケースが多くなってきた。

そのため、今後は例外的な場合(=当事者)を除き広く利用されているケースのみをターゲットとし、RFC違反などのケースは考慮しない運用の方がリーズナブルであると考える。

コメント

タイトルとURLをコピーしました