Как все знают, один из самых удобных способов проверки e-mail адреса является регулярные выражения. Недавно пришлось столкнулся с проблемой максимально точной проверки адресов. Данная проверка была необходима в системе автоматической рассылки спама опросников, где каждый список адресов подгружался автоматически одним большим файлом. Требовалось исключить максимальное количество заведомо невалидных адресов.
Проблема заключалась в том, что все шаблоны проверки е-мэйла, которые можно встретить в интернете, МСДН и других источниках не удовлетворяли требованиям проверки. Обратившись к первоисточникам в виде RFC 2821 и RFC 2821, я выяснил как же точно и правильно валидирвоть адреса.
Е-майл адрес = local part @ domain part
Символы разрешенные в local part:
Символы НЕ разрешенные в local part
Символы, которые нежелательно использовать в local part, но которые могут присутствовать. (Требуют тестирования, принимает ли их сервер).
Причина, по которой не стоит их использовать в адресах это то, что многие относятся к группе символов «UNIX shell special characters».
— может быть, либо в виде IP адреса, IP-адреса с портом либо просто литерального выражения содержащего только строчные и прописные латинские буквы и символ черточки ( ‘-‘, но есть ограничение: черточка не может быть, ни в конце, ни в начале; по поводу ограничения на две черточки подряд ничего не сказано), разделенные точками. Соответственно выражение domain..com – невалидное.
В итоге модифицировав один из интернетовских шаблонов получил:
^[a-zA-Z0-9_'+*/^&=?~{}\-](\.?[a-zA-Z0-9_'+*/^&=?~{}\-])*\@((\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}(\:\d{1,3})?)|(((([a-zA-Z0-9][a-zA-Z0-9\-]+[a-zA-Z0-9])|([a-zA-Z0-9]{1,2}))[\.]{1})+([a-zA-Z]{2,6})))$
Ссылки:
RFC 2821: www.remote.org/jochen/rfc/rfc821.txt
RFC 2822: www.remote.org/jochen/rfc/rfc822.txt
Список валидных/невалидных символов: www.remote.org/jochen/mail/info/chars.html
Если регулярное выражение неполное или в каком-то случае неправильное пожелания и замечания приветствуются.
Хотелось бы подчеркнуть – что это частный случай в котором понадобилось использование серьезной и точной проверки (как требовал клиент). В иных случаях можно не заморачиваться :)
Проблема заключалась в том, что все шаблоны проверки е-мэйла, которые можно встретить в интернете, МСДН и других источниках не удовлетворяли требованиям проверки. Обратившись к первоисточникам в виде RFC 2821 и RFC 2821, я выяснил как же точно и правильно валидирвоть адреса.
Е-майл адрес = local part @ domain part
Local part
Символы разрешенные в local part:
- +
- -
- . ( кроме случаев local..part — две точки подряд, .localPart — точка вначале и localPart. – точка в конце )
- 0-9
- A-Z, a-z
- -
Символы НЕ разрешенные в local part
- !
- “
- #
- $
- %
- (
- )
- ,
- :
- ;
- <
- >
- [
- \
- ]
- ‘
- |
- SPACE, DEL, Control chars
Символы, которые нежелательно использовать в local part, но которые могут присутствовать. (Требуют тестирования, принимает ли их сервер).
- ?
- ‘
- *
- /
- =
- ?
- ^
- {
- }
- ~
Причина, по которой не стоит их использовать в адресах это то, что многие относятся к группе символов «UNIX shell special characters».
Domain part
— может быть, либо в виде IP адреса, IP-адреса с портом либо просто литерального выражения содержащего только строчные и прописные латинские буквы и символ черточки ( ‘-‘, но есть ограничение: черточка не может быть, ни в конце, ни в начале; по поводу ограничения на две черточки подряд ничего не сказано), разделенные точками. Соответственно выражение domain..com – невалидное.
В итоге модифицировав один из интернетовских шаблонов получил:
^[a-zA-Z0-9_'+*/^&=?~{}\-](\.?[a-zA-Z0-9_'+*/^&=?~{}\-])*\@((\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}(\:\d{1,3})?)|(((([a-zA-Z0-9][a-zA-Z0-9\-]+[a-zA-Z0-9])|([a-zA-Z0-9]{1,2}))[\.]{1})+([a-zA-Z]{2,6})))$
Ссылки:
RFC 2821: www.remote.org/jochen/rfc/rfc821.txt
RFC 2822: www.remote.org/jochen/rfc/rfc822.txt
Список валидных/невалидных символов: www.remote.org/jochen/mail/info/chars.html
Если регулярное выражение неполное или в каком-то случае неправильное пожелания и замечания приветствуются.
Хотелось бы подчеркнуть – что это частный случай в котором понадобилось использование серьезной и точной проверки (как требовал клиент). В иных случаях можно не заморачиваться :)