Корректность написания адреса email

[CD_Eater]

Так, чисто поржать.
Видели ли Вы когда-нибудь, как выглядит регулярное выражение для проверки правильности адреса email?
Думаете, что-нибудь вроде такого?
\w+@(\w+\.)+\w+

А теперь посмотрите правильный ответ

@темы: тяжела и неказиста жизнь простого программиста, RFC

Comments

[Скептичный циник]

Теперь осталось понять зачем вообще проверять почту регулярками (о.0)

[CD_Eater]

а как ещё её проверять?
имеется в виду проверка правильности адреса, введённого человеком, перед отсылкой ему письма на этот адрес

(ну, или для роботов, собирающих адреса для спама)

[Скептичный циник]

Во-первых, зачем вообще проверяется почта? Чтобы указать человеку на очепятку. Если он забыл собаку/точку или поставил пробел – это легко проверяется фактом наличия данных символов в строке.
Если юзер осознанно не хочет давать реальное мыло, то регулярка не спасёт от [email protected].
Следовательно, любые сложные валидации адреса не нужны.

Но, допустим, для некоторого сервиса это очень приоритетная задача, на грани жизни и смерти. Даже в этом случае есть много способов:
1. input type="email". Юзеры с мобилок ещё и спасибо скажут за собаку на главной стороне клавиатуры. Ну и плюс валидация в браузере.
2. В PHP тоже делается лаконично: filter_var($email, FILTER_VALIDATE_EMAIL). Для других языков тоже есть свои аналоги.
3. Есть куча бесплатных почтовых сервисов с апи не только для отсылки, но и для проверки почты. Ну, хотя бы MailGun.
4. Можно ловить коллбеки SMTP-сервера. Он явно лучше знает существует почта или нет, доставлено письмо или ошибка произошла (и какая).

[Kot Dymok]

Скептичный циник, А ловля коллбэков, действительно, один из самых простых методов... если сервер в спамеры/ботнеты не запишет.
А по поводу сложности проверки - всё в порядке, правил там, действительно достаточно много. А если еще и ориентироваться на особенности известных сервисов.
И, если не ошибуюсь, на Хабре должна висеть популярная статья на этот счет. Если кому интересно, она там должна еще висеть.

[Kot Dymok]

И да, проверка обычно ведется еще во время ввода/проверки данных, отправка со всеми возможными результатами отклика совершаются позже.

[Скептичный циник]

Kot Dymok, да, со сложностью действительно всё в порядке (:
Отсюда и вопрос: зачем оверхедить и что-то выдумывать (особенно затачивать под какие-то особенности конкретных сервисов или хотя бы вести руками список TLD), если единственный способ узнать существует мыло или нет это послать туда письмо?
Насчёт отклика, сейчас всё проще. По крайней мере, у серверов широкий и шустрый канал для обработки в пределах секунды-двух.

[Kot Dymok]

Скептичный циник, а всё просто - если проверять отдельным дополнительным письмом, в спамеры запишут. Если же отправлять письмо с подтверждением письма... Первая же проблема, которую я вижу - собственные ящики, которые могут игнорировать всякие просьбы о подтверждении.
А обязывать сразу подтверждать мыло нельзя, пользователи уйдут.
P.S.
Учтите, мои рассуждения на эту тему попахивают делетантством - моя тематика совсем иная. Потому, если видите, что я абсолютно не прав, так и говорите.

[CD_Eater]

Вообще, задачка кажется очень простой и часто (в книжках) используется как простое упражнение на тему "использование регулярных выражений"
Однако...

[Скептичный циник]

Kot Dymok, зачем дополнительное? Просто шлёте нужное письмо и всё. Если не словили fail от почтового сервера, значит, всё хорошо. Никто не гарантирует, что inbox валидного ящика будет хоть кто-то читать. Можно ещё использовать знания других, прокачанных в теме людей.
Если регулярки работают и вам потом не надо будет это поддерживать, то ок. Оверхед сложными в поддержке регекспами (а если не оверхедить, то можно отхватить много ложных срабатываний) мне кажется такой же бесперспективной затеей как парсинг ими же html. Но это имхо. Кажется, тут холивар.

CD_Eater, ну если в учебных целях разве что (:

[mikluho]

С одной стороны, "\w+@(\w+\.)+\w+" - конечно не годится совсем.
С другой - то, что по ссылке - это не более, чем формализация в виде регулярки того, что вообще может оказаться в заголовке "адрес" электронного письма. Т.е. это не проверка валидности самого почтового адреса, и может пригодиться только для проверки технического заголовка письма. Хуже всего то, что эта регулярка устарела, равно как и тот rfc, по которому она написана, а значит в реальной жизни бесполезна.
С третьей стороны, конечно, на уровне пользовательского интерфейса (да и вообще для бизнес приложений) имеет смысл лишь грамматическая проверка адреса. Но пользуясь готовой реализацией, стоит посмотреть на неё и убедить в том, что она подходит под условия. Например, поддерживает национальные домены

А так, да, хорошая обучающая задачка по регуляркам (коих стоит избегать по мере сил ).

[Kot Dymok]

Если не словили fail от почтового сервера,

Значит сервера-то могло и не быть совсем. А всем этим "жутко-важным" сервисам он почему-то очень нужен.

[Скептичный циник]

> Если не словили fail от почтового сервера, Значит сервера-то могло и не быть совсем.
Про какой сервер речь? Если нет вашего сервера, то и письмо не пройдёт даже на валидный адрес.
Если про тот, что на домене, то понять живое ли оно можно просто проверкой MX NS'ки. Или, если хочется поизвращаться, то телнетнуть его 25/110/443 порт. Самый быстрый способ, как мне кажется.

А ещё есть feedback loop, это чуть дольше, зато надёжнее. И, если используете готовое решение (по API или SMTP), то можно довольно быстро получить статус доставлено/не существует. Опять же, извращенцы могут проверять свой inbox на наличие ошибок от почтовиков о кривых адресах. Секунд в пять проверка уложится, наверное.

С другой стороны, там, где я не хочу светить мыло, использую dropmail.me и ни одна из всех перечисленных в треде проверок не помогут.

Плюсую mikluho (:

CD_Eater,
> I did not write this regular expression by hand. It is generated by the Perl module by concatenating a simpler set of regular expressions that relate directly to the grammar defined in the RFC.
Эта генерированная регулярка, думаю если какой-то норкоман задастся целью, то думаю смогёт покороче.

[CD_Eater]

Скептичный циник,
Во-первых, зачем вообще проверяется почта? Чтобы указать человеку на очепятку.
Да, корретность адреса обычно проверяется сразу при вводе, чтобы помочь человеку не ошибиться. Чтобы он узнал об ошибке через пару секунд, а не через 5 минут, когда он устанет ждать письма, которое никак не приходит.
Нет такой цели - выявить обман. Пусть пишет [email protected], если хочет. Помогаем только добросовестным.

Если он забыл собаку/точку или поставил пробел – это легко проверяется фактом наличия данных символов в строке.

Ну и нафига городить огород из кода с какими-то эвристическими методами (типа предложенного вами поиска собаки, точки и пробела), если ту же самую хрень, но только более надёжно и короче можно выразить регуляркой?
Для "быстрой и грязной" офф-лайн валидации email-а регулярка более чем оправдана.

твой фаворит,

думаю если какой-то норкоман задастся целью, то думаю смогёт покороче.

не родила мать-земля ещё таких наркоманов. )))

[Скептичный циник]

> Нет такой цели - выявить обман. Пусть пишет [email protected], если хочет. Помогаем только добросовестным.
Тогда чем не устраивает input type="email"? Никакого js не нужно (:

[CD_Eater]

Скептичный циник,

Тогда чем не устраивает input type="email"?

а вы не думаете, что внутрях реализации input type="email" как раз и спрятана регулярка?
Просто изначально речь шла не только о js (а что, js реально проглотит тот огромный regex и не подавится?).
Например, в одном реальном проекте в ТЗ присутствовало требование офф-лайн валидации email-адресов для всех хранящихся в БД клиентов. Решалось как раз регуляркой. Правда, что они потом делали с кучей найденных невалидных адресов - я без понятия. ))

[Скептичный циник]

CD_Eater, а мне не важно что спрятано внутри input/filter_var/чего-нибудь-ещё. Главное, чтобы оно работало и не добавляло геморроя. Если языке будет кривая поддержка, её быстрее найдут и исправят, чем в велосипедной самописной/скопированной регулярке, про которую все забыли и не поддерживают.

[CD_Eater]

Скептичный циник, какое-то у вас "пользовательское" отношение к софту, а не "программистское"
типа, работает, и ладно, мне меньше гемора

а как же захватывающий акт творчества?
"я сделал это сам и полностью понимаю, что там происходит, поэтому могу точно предсказать поведение на любых входных данных (чётко вижу потенциально опасные места) и могу легко изменить поведение, если это потребуется в будущем"
по крайней мере для меня лично это и является главным стимулом что-то программировать: мне нравится полный контроль над происходящим

разве жизнь не научила вас, что если надеешься на кого-то или чего-то, не очень понимая как там что-то устроено внутри, то очень скоро наступает такой момент, когда выясняется, что ваши ожидания не оправдались?
что кажущаяся лёгкость пользоваться чем-то готовым была обманчивой и на деле вдруг оборачивается сильными неудобствами?
что шаг вправо-шаг влево от прямого пути и вы попадаете в ситуацию, когда халява пропадает?
это справедливо не только в программировании (Leaky Abstractions), но и в жизни вообще

ну, вот конкретный пример: пользователю разрешили (напр., внезапно законодательным порядком) вводить не один email, а несколько (от 1 до 10)
я просто добавлю ещё несколько символов в свою регулярку, и пользователь будет верифицированно вводить в то же самое поле уже не один email, а несколько через точку с запятой.
а что вы будете делать со своим уже неприменимым input type="email"? или вы тупо перерисуете форму, сделав 10 окошек ввода вместо одного? )))
так у кого будет больше геморроя при поддержке? )))

[Скептичный циник]

CD_Eater, слишком много информации в it, чтобы не только всё знать, но и держать эти знания актуальными. Если добавляется зависимость от библиотеки, то там понятно что и с какими последствиями может "протечь". Для защиты от такой фигни есть много идей проектирования и best practices вроде закона Деметра или простого DI, что снимает большинство последствий таких проблем.
И акт творчества гораздо приятнее (лично мне по крайней мере, не претендую на истину) когда пишешь что-то своё, а не думаешь о каких-то полях ввода шестой год подряд опыта разработки, интереснее подниматься уровнем выше и программировать там.
Если юзер может вводить несколько опциональных мыл, то сделаю несколько полей, что намного логичнее. Но это уже дизайнерский вопрос. Если нужно только одно поле, то split/explode по разделителю будет более читабельным и удобным для дальнейшей обработки адресов по отдельности.

[CD_Eater]

Скептичный циник,

когда пишешь что-то своё, а не думаешь о каких-то полях ввода шестой год подряд опыта разработки

да, некоторые задачи встречаются разработчику постоянно, и чтобы их не решать каждый раз, у каждого имеются наработки в виде часто используемых функций, чтобы не писать их повторно. думаю, что функция валидации email у любого дизайнера точно есть
ах, вам не нравится, что зависимость от библиотеки усложняет поддержку кода, и вы были бы не против, если бы кто-нибудь другой отвечал за валидацию email, и вы даже ссылаетесь на dependency injection как на отговорку?
ну что тут можно сказать? признаю, вы крайне изобретательны в поисках оправданий для своей лени ))

но несмотря на отговорки, ваша задача так и осталась пока нерешённой:

Если нужно только одно поле, то split/explode по разделителю будет более читабельным и удобным для дальнейшей обработки адресов по отдельности.

Для дальнейшей обработки чем? Использованная вами раньше фича уже неприменима. Вы вернулись к тому, от чего пытались убежать )))

а 10 полей ввода - это удар по юзабилити. ну нафига юзеру 10 окошек, когда 99% пользователей введут только один адрес?
или отток пользователей от вашего сервиса к конкурентам вы тоже будете оправдывать, ссылаясь на шаблоны проектирования? )))

[Скептичный циник]

> вы крайне изобретательны в поисках оправданий для своей лени
Спасибо (: Лучше использовать встроенные в язык возможности, которые проверены намного более тщательно, чем любой самописный код. Меньше кода – меньше точек отказа. Но это субъективный выбор, личный "почерк" и холивар (:

> Для дальнейшей обработки чем?
Чем угодно.
Если на сервере было

$mailer->send($request->get('email'), /* ... */);

, то после добавления опциональных полей стало

foreach ($request->get('email') as $email) $mailer->send($email, /* ... */);

(ну, или

foreach (explode(',', $request->get('email')) as $email) $mailer->send($email, /* ... */);

, если выбрали всё-таки разделители). Вместо рассылки можно подставить любую другую обработку, это просто пример.
Заметьте, что какой бы путь для решения задачи "доступно много адресов ко вводу" не выбрали, код сервера меняется одинаково и эти изменения касаются только количества обрабатываемых адресов (код валидации не трогается вообще) и ничего лишнего, DRY и S из SOLID соблюдаются.
В коде вёрстки изменения точно такие же – вместо одного input[type=email] стало два/три/десять/сколько_нужно.

> отток пользователей от вашего сервиса к конкурентам вы тоже будете оправдывать, ссылаясь на шаблоны проектирования?
Конверсия, юзабилити и лояльность юзеров это работа UX-специалистов и маркетологов. Если юзеры уходят из-за плохого UX, то почему в ответе за это должен быть программист?

> нафига юзеру 10 окошек, когда 99% пользователей введут только один адрес?
Это вопрос не кода, даже не технический и никак к теме не относится. Ну, дадут в работу макет с одним полем и кнопкой плюса для добавления ещё адресов или будет что-то типа x-editable с а-ля тегами, тупо полотно окошек ввода или что там ещё придумают дизайнеры для удобства юзеров – всё-равно нужно будет добавлять эту логику в клиентский код.

[Скептичный циник]

> некоторые задачи встречаются разработчику постоянно, и чтобы их не решать каждый раз, у каждого имеются наработки в виде часто используемых функций, чтобы не писать их повторно
Никто не идеален. Если ты написал код сейчас, который считаешь самым лучшим, то, обычно, через год ты видишь в нём ошибки и недоработки ибо за этот год ты вырос. К тому же, твои личные наработки видят от силы пара человек.
Если это настолько частая задача, значит, кто-то ещё уже решил ранее и поделился с сообществом. Миллион глаз, проверивших код, гораздо объективнее двух, соответственно, шанс появления бага в том коде ниже. Почему бы не использовать это вместо траты сил и времени на создание велосипеда гораздо худшего качества?

[CD_Eater]

Скептичный циник,

> Для дальнейшей обработки чем?
Чем угодно.
Если на сервере было

при чём тут сервер?
вы вынуждаете объяснять вам простые вещи. но я попробую объяснить доступно

есть такие зверьки - юзеры. видимо, вы с ними никогда не сталкивались и лишь теоретически допускаете их существование
но люди, более знакомые с реальностью, говорят, что эти самые зверьки довольно важны в природе и более того, они являются основой финансового благополучия всей сферы IT.
юзеры работают через "юзер интерфейсы" (это как раз там, где вводится email)
причём работа юзеров с этими интерфейсами происходит обычно нелегко для них самих: они часто ошибаются при вводе строк и чисел, нервничают, по невнимательности не там нажимают, и местами долго тормозят
вот как юзер заполняет форму с данными о своей фирме: перед ним длинная страница с полями ввода, он идёт последовательно: сначала пишет верхнюю строку (название фирмы) по памяти, потом ИНН (заглядывает в шпаргалку, лежащую на столе), потом ФИО контактного лица (пишет своё ФИО), email контактного лица (ищет на компе файлик "моя почта, логины и пароли.txt", сначала мучительно вспоминая, в какой же он лежит папке), потом разная информация о фирме (лезет в шкаф за ксерокопиями учредительской документации), потом паспортные данные представителей (лезет в портфель, где лежат недавно переданные ему ксерокопии паспортов директора и главбуха), потом остальную хренотень, жмакает "отправить", а компьютер, потормозив секунд 5, ему говорит о неправильном email. Юзер в ужасе - email он заполнял минут 15 назад и уже успел забыл, в какой же папке лежит тот файл, и снова начинает его искать...
Поэтому все сайты выполняют МГНОВЕННУЮ проверку правильности email, ИНН, пенсионных свидетельств и т.п. Как только курсор выходит из поля ввода, юзер уже видит, что он тут ошибся, и сразу исправляет ошибку. Это намного удобнее, чем исправлять её потом.

Так вот, если вы не сделаете такое удобство для пользователя, то ваш продукт не будет конкурентоспособен, и всем будет абсолютно наплевать на то, сколько букв из слова SOLID у вас там реализовано )))
Так что надо за деревьями иногда видеть лес.

Конверсия, юзабилити и лояльность юзеров это работа UX-специалистов и маркетологов. Если юзеры уходят из-за плохого UX, то почему в ответе за это должен быть программист?

не хотите мыслить системно?
встали в позу тупого кодера: "я отвечаю только за свой код, а остальные проблемы меня не волнуют"?
ну тогда вам как тупому кодеру тупо дадут ТЗ, где будет написано "проверку вводимых данных выполнять на стороне клиента"
как видите, мы вернулись к первоначальной задаче ))

так как же вы будете её решать?
регулярку вы не любите, поэтому будете делать 10 окошек, точнее, "макет с одним полем и кнопкой плюса для добавления ещё адресов"
а теперь прикиньте сложность вот этой вот конструкции с "кнопкой плюса" и сравните со сложностью поддержки регулярки в одну строку.
вот к этому сравнению я и хотел вас подвести: регулярка в этой задаче обойдётся дешевле

[FaintEmber]

ну тогда вам как тупому кодеру тупо дадут ТЗ

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

регулярку вы не любите, поэтому будете делать 10 окошек, точнее, "макет с одним полем и кнопкой плюса для добавления ещё адресов" а теперь прикиньте сложность вот этой вот конструкции с "кнопкой плюса" и сравните со сложностью поддержки регулярки в одну строку.

Оригинальный довод для того, кто выше упоминал об удобстве пользователя. Доводилось мне видеть перегруженные полями формы, ничего удобного в них для юзеров нет. Уж лучше кнопка добавления, вызывающая подчинённую форму, нужно будет - нажмут, не понадобится - обойдутся полем на главной форме.

По сабжу, есть забавная фраза:
"Некоторые люди, столкнувшись с проблемой, думают: «О, а использую-ка я регулярные выражения». Теперь у них есть две проблемы."

[Скептичный циник]

CD_Eater, САБЖ, вроде как, технического содержания. Ну ладно, оффтоп так оффтоп.

[offtop]
У вас лет пять и разработки, и UX? Тогда снимаю шляпу, вы крут! Однако, найти такого человека очень сложно, их очень мало, и смысл найма их не очень понятен – прорабатывать дизайн и писать код можно параллельно без снижения качества. Это и быстрее, и дешевле. Значит, гораздо лучше взять двух спецов, если вы, конечно, не квартет-Анатолий-один-разработчик-в-компании.
Если компания предпочитает экономить на специалистах и отдавать всё на откуп тем, кто в теме не разбирается или максимум прочитал книгу типа "UX за 21 день", то что ж.. это её выбор. Я понимаю, что в UX разбираюсь сильно хуже, чем UX-спец и да, я готов отдать дизайн ему на откуп дабы оконечный продукт был хорош со всех сторон.
В конкретном случае с полями ввода, я уверен, что дизайнер сделает так, чтобы пользователю было максимально удобно с ними работать. А я, в свою очередь, напишу код так, чтобы оно работало максимально быстро и поддерживаемо. В этом плане, мне без разницы как именно дизайнер решит свою задачу.
Тот же SOLID – один из многих критериев качества кода, который спасает время, душевное спокойствие и делает код более поддерживаемым, тестируемым и лаконичным. Если вы не улучшаете его и другие критерии качества там, где они не приносят вреда, то не хотел оказаться в ситуации, где нужно поддерживать ваш код.
[/offtop]

> "проверку вводимых данных выполнять на стороне клиента"
Во-первых, это плохая формулировка для ТЗ, гораздо лучше была бы "осуществлять проверку вводимого адреса в процессе ввода не дольше чем за 1 секунду" или вроде того.
Во-вторых, сервер в любом случае обязан делать проверку всех входящих данных от клиента и на своей стороне тоже, вне зависимости от любых других факторов.
В-третьих, пространство адресов, принятых как корректные, на клиенте должно быть заведомо шире, чем на сервере или равным ему, но никак не наоборот. В целях оптимизации и, в частности, уменьшения false positive.
В-четвёртых, чем сложнее регулярка, тем сложнее оценить валидируемое ею пространство. Следовательно, усложняется поддержка, увеличиваются тесты (которые тоже надо поддерживать). Игра не стоит свеч в данном случае.

Как правильно заметил FaintEmber, "Некоторые люди, столкнувшись с проблемой, думают: «О, а использую-ка я регулярные выражения». Теперь у них есть две проблемы" (:

[CD_Eater]

FaintEmber,

Доводилось мне видеть перегруженные полями формы, ничего удобного в них для юзеров нет.

Полностью согласен.
Вы, видно, невнимательно читали. Я против перегруженных полями форм.
Не я предложил 10 окошек, а Скептичный циник (поищите выше по тексту).

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

Виноват. Но человек и правда прикинулся тупым кодером, который кроме своего кода ничего не видит и не понимает очевидных целей проекта.
Он видит только свою "хату с краю", и брезгливо отзывается о проектировании юзер интерфейсов.
Он думает, что решил проблему, просто спихнув её на дизайнера интерфейса. ))
Неважно, кто пишет интерфейсы: он или не он.
Стоимость поддержки проекта - это сумма стоимости поддержки ВСЕХ его частей, включая все эти формочки и плюсики.
Доведите, пожалуйста, эту мысль до него, если сможете ))

«О, а использую-ка я регулярные выражения». Теперь у них есть две проблемы."

Да, есть такая фраза, весьма распространённая среди нелюбителей регулярки.
Да, это здорово - всем дружно что-то охаять и чувствовать себя единой стаей (долбоёбов, видимо).
Однако я ещё не видел ни одного разумного аргумента против использования регулярки там, где она уместна.
"Быстрый и грязный" поиск опечаток в email - как раз такой случай.

[mikluho]

Ну вы разошлись...
Тема-то давно обсосана со всех сторон. Единственно, меж кем ещё вызывает холивар - это между перфекционистами и практиками
Я, дай бог памяти, первую регулярку на мыло написал ещё в 2000-м. И уже тогда было ясно, что она нужна только на синтаксическую проверку того, что пользователь может указать в качестве своей почты. Вполне лаконичная, она не покрывала и 90% возможностей от rfc, но пережила без нареканий сотню тысяч регистраций пользователей. И всё. Тот же подход работает в моей практике до сих пор, в десятке проектов разной направленности.
Споры о том, как и когда вводить несколько мыл вообще ниочём, ибо практика показывает что это почти никогда не нужно, а если и нужно, то дизайнеры (и прочие ux-эксперты) решают, как это рисовать, архитекторы решают как это хранить, а всё та же регулярка проверят адреса поштучно.
И да, ни разу в своём опыте работы я не встречал ощутимой пользы от _сложных_ регулярок. Их сложно анализировать/развивать/поддерживать. Чем она сложнее, тем больше шанс, что при попытке очередного изменения/исправления её придёт переписать заново


ps
если кто продолжит переход на личности в грубой форме - я эту дискуссию прикрою

[CD_Eater]

mikluho,

дизайнеры (и прочие ux-эксперты) решают, как это рисовать, архитекторы решают как это хранить

да, в этом и кроется причина разногласий в этой ветке: большинство людей уверены, что за них всё продумают и решат другие, увидеть самому ситуацию вцелом - это сложно и ненужно )

[mikluho]

CD_Eater,

большинство людей уверены, что за них всё продумают и решат другие

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

Кстати, про 10 полей - я знаю случаи, когда это наиболее верное решение.

регулярки там, где она уместна

- вот это разумно. Но не надо решать несвойственные задачи. Проверить синтаксическую годность - гут. Валидность - уже вряд ли. Парсить универсально один адрес или пачку - вот это уже плохо пахнет.