メールアドレスの形式は、思っているより単純で、そして思っているより広いです。本記事では、記号ひとつで前半と後半に分かれるという基本から始め、長さの上限と、標準が認めているのに実際には通らない書き方を整理します。読み終えると、入力欄の検証をどこまで厳しくすべきかが判断できます。
メールアドレスは何でできているのか
アドレスは記号ひとつで二つに分かれます。前半は利用者を識別する部分、後半はドメインです。この二つを合わせて一つの宛先になります。前半と後半は別々の規則を持っていて、長さの上限も別々に決まっています。
ここで覚えておきたいのは、後半は必ずしも企業の名前である必要はないという点です。標準の文法では、角かっこで囲んだ数値の形も認められています。ただし、実際の登録画面でこれが通ることはほとんどありません。
長さの上限はどこで決まっているのか？
公開された標準では、前半が最大で数十バイト、後半がより大きな上限、全体でもう少し大きな上限、という三段構えになっています。具体的には、前半は六十台半ば、後半は二百五十台、全体では二百五十台の後ろのほう、という値です。
ここで大切なのは、単位が文字数ではなくバイト数だという点です。日本語やアクセント記号を含む文字は、一文字で複数バイトを占めます。見た目の文字数が少なくても、上限に近づくことがあります。
さらに、現実のサービスは標準より狭く受け取るのが普通です。全体の長さを標準の上限より少し短く切る実装は、広く見られる慣行です。これは標準の値ではなく、実装側の判断です。つまり「標準で許されている長さ」と「そのサービスが受け取る長さ」は別物です。
標準が認めても通らない書き方とは？
標準の文法は、ふだん見かけない書き方をいくつも認めています。代表的なものを挙げます。
- 引用符で囲んだ前半。空白や記号を含められます。
- 丸かっこで囲んだ注釈。表示用の補足として扱われます。
- 角かっこで囲んだ数値のドメイン。
- 国際化の拡張を使った非 ASCII 文字の前半。
いずれも、実際の登録画面では弾かれることが多いものです。したがって、標準に照らして正しいかどうかと、そのサービスが受け付けるかどうかは、別々に考える必要があります。この二つを混同すると、本来通るはずのアドレスを自分で弾いてしまいます。
厳しすぎる検証が生む問題
入力欄の検証を厳しくしすぎると、正しいアドレスを誤って拒否します。とくに起きやすいのは次の三つです。
- 記号の並びを独自の規則で禁止し、標準で許された形を弾く。
- 後半にドットが二つ続く形を一律に拒否する。標準では認められていませんが、判定の書き方を誤ると別の形まで巻き込みます。
- 大文字を一律に無効とみなす。前半の大文字と小文字は区別される建前ですが、実際には区別しない運用が広く行われています。
いずれも、利用者から見ると「正しいアドレスなのに入れられない」という体験になります。検証の目的は、明らかな誤入力を早く知らせることであって、珍しい形を排除することではありません。
長いアドレスはどこで問題になるのか
上限に近いアドレスは、入力欄そのものより後ろの工程で問題を起こします。一覧の表示幅、ログへの記録、外部の連携先へ渡すときの切り詰め。どれも、長さを想定していない場所で起きます。
とくに、外部へ渡すときに途中で切られる事故は見つけにくいです。切られた先でも形式としては成立してしまうことがあるため、エラーにならず、別の宛先へ送られる形で表面化します。長さの上限を決めるときは、入力欄だけでなく、値を扱うすべての場所を並べて、最も短い制限に合わせてください。
開発者向け: 検証と保存の設計
まず、判定の強さを段階に分けます。形式として明らかにおかしいものだけをその場で止め、それ以外は受け付けます。本当に有効かどうかは、確認メールを送って確かめるのが確実です。入力の時点で完全な判定はできません。
次に、長さの上限を項目の設計に反映します。前半と後半で別々の上限を持たせ、標準の値を超えないようにします。データベースの列の長さを、標準の上限より小さく取ると、あとで困ります。余裕を持たせてください。
第三に、非 ASCII 文字の扱いです。受け付けるかどうかを機能の設定として持ち、保存する形を統一します。同じ利用者が二つの書き方で登録できてしまうと、あとから同一人物だと判定できません。ここは、受け付けるか受け付けないかのどちらかに寄せてください。
第四に、前後の空白の扱いです。貼り付けのときに空白が混ざることはよくあります。保存の前に取り除くのか、それとも入力をそのまま扱うのかを決め、確認の送信から保存まで同じ規則を通してください。途中の段階ごとに扱いが違うと、原因の分からない不一致が生まれます。
第五に、大文字と小文字の扱いです。標準では前半は区別されますが、実際の運用では区別しないことが多いです。どちらにするかを決め、比較する場所すべてで同じ規則を使います。ここが揃っていないと、ログインできない利用者が生まれます。
次のステップ
手元の入力検証を開き、拒否している条件を一つずつ標準と照らし合わせてください。標準で許されているものを弾いている条件があれば、それが最初に直すべき箇所です。あわせて、長さの上限が前半と後半で分かれているかを確認します。
一時的な宛先の形式を確かめたいときは使い捨てメールのツールで実際に発行できます。標準と実装のずれという同じ論点は一時メールと別名アドレスの違いでも扱っています。国の識別番号の形式を確かめる考え方はマイナンバーの検査数字の読み方が参考になります。