URLとメールアドレスのバリデーション
URLとメールアドレスのバリデーションついての考察
URL及びメールアドレスの形式はRFCで定められています。
URL/メールアドレスのバリデーションを紹介しましたが、
完全なものではないので、エラーの形式でもエラー判定されない可能性もあります。(誤りがあるURLは大方エラー扱いとなります。)
RFCを考慮して、もっと厳密にチェックに入れてもいいかもしれませんし、紹介したチェックより簡易的なものでもいいかもしれません。
どのようなユーザがどのような場面でどのような意図で使うかによってバリデーションを厳しく(=収集しようとする情報が重要、もしくは利用するユーザが限定的なものではない)、
バリデーションを緩く(=収集しようとする情報がさほど重要ではない、もしくは利用するユーザが特定されている)と柔軟に対応すべきだと個人的には思っています。
実際、(見ず知らずの)先輩が残していったプログラムを見ると簡易的なバリデーションが大半を占めています。
また、メールアドレスのバリデーションでは、RFCに準拠していないものが存在している事実があり、非常に厄介です。
そのような例外を許可するのであれば、形式チェックを緩めておくか、非準拠対応しておかないと、弾いてしまうかもしれません。
余談
余談ですが、RFCを考慮せず、個人の独断と偏見で設定されたと思われるバリデーションで、実際に使用されているメールアドレスがエラー扱いとなる場面に遭遇したことがあります。
@と.の間が1文字だけのメールアドレスをエラー扱い
foo@a.example.com
Gmailのサブアドレス +部分をエラー扱い
foo+baz@gmail.com
誤った文字列を弾くためのバリデーションなのに、正しいものを弾いては意味がありません。
RFCを確認したことがなかったり、かなり昔から使われているものをそのまま流用したり、サイトに紹介されているものを検証せずコピペして使ったりというバリデーションは注意が必要かもしれません。