nazarpunk/email-address

Email address parse and sanitize.

1.0.6 2023-08-24 11:30 UTC

This package is auto-updated.

Last update: 2024-10-24 14:00:50 UTC


README

Многие разработчики испытывают трудности с валидацией email. Одни просто используют RegExp, другие отказываются от проверок, третьи рисуют таблицы.

Немного философии

Электронная почта прошла большой путь, который оставил на ней свои следы. Но зачастую, поддерживать весь функционал электронных адресов не требуется. В большинстве своём, пользователи пользуются почтовыми сервисами. Посему здравой идеей будет плясать от них.

Поэтому проверка будет очень проста:

  • очищаем строку от пробело
  • разбиваем по @ на две части
  • по доменной части проверяем оставшуюся строку
  • если поставщик не найдек, поступаем по вкусу

Что может пойти не так?

Точка

У некоторых почтовых сервисов, есть интересная особенность - не значащие точки. Тобишь example@gmail.com и e.x.a.m.p.l.e@gmail.com это один и тот же адрес. Соотвественно, если пользователь зарегестрирует несколько аккаунтов, а потом решить привязать oauth, то может быть очень весело.

Плюс

У некоторых почтовых сервисов, есть интересная особенность - игнорировать всё после знака +. Тобишь example@gmail.com и example+spam@gmail.com это один и тот же адрес. Соотвественно, если пользователь зарегестрирует несколько аккаунтов, а потом решить привязать oauth, то может быть очень весело.

Домены

Некоторые почтовые сервисы, игрнорирую разницу в доменах. Тобишь example@gmail.com и example@googlemail.com это один и тот же адрес. Соотвественно, если пользователь зарегестрирует несколько аккаунтов, а потом решить привязать oauth, то может быть очень весело.

Очень умные пользователи

Поднять свой сервер или использовать одноразовые почтовики не составляет большого труда. Посему неизбежно возникнут проблемы с полностью валидными адресами такого формата.

"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334]

Но эта проблема выходит за рамки данной статьи, так что продолжим.

Формат адреса

Отбросив домен, у нас осталась пользовательская часть, которую нужно проверить исходя из допустимого формата самих сервисов. Можно пойди двумя путями:

  • Собрать максимально свободную регулярку и не мучаться.
  • Или, чтоб не слать байты по заведомо не валидному адресу, проверить каждую запрещённую последовательность основываясь на таблице.

Как поступать решать вам, а таблица собственно приведена ниже.

  • min минимальная длинна
  • max максимальная длинна
  • chars допустимые символы
  • first допустимый первый символ
  • last допустимый последний символ
  • !. удалять ли точку при проверке
  • .. разрешена ли последовательность из двух точек
  • ._ могут ли символы . и _ находиться рядом
  • .- ** могут ли символы . и - находиться рядом
  • .0 может ли точка соседствовать с цифрой
  • __ разрешена ли последовательность из двух _
  • _- могут ли символы _ и - находиться рядом
  • -- разрешена ли последовательность из двух -
  • .+ может ли в строке быть больше одной точки
  • + игнорировать ли всё, что после знака +
  • l количество не буквенных символов, после которого требуется минимум одна буква
  • t тестировались ли данные руками

Домены

  • d привязаны ли все домены к одному аккаунту