Комментарии 57
Еще бы все это под кат, и вообще шикарно было бы
Хабракат пожалуйста.
внимательно читаем RFC
<local-part> ::= <dot-string> | <quoted-string>
<quoted-string> ::= """ <qtext> """
<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
где у вас обраотка quoted-string?
правильный регэксп занимаем почти страницу
<local-part> ::= <dot-string> | <quoted-string>
<quoted-string> ::= """ <qtext> """
<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
где у вас обраотка quoted-string?
правильный регэксп занимаем почти страницу
Правильный регэксп лежит здесь. Там даже если заподозришь, что есть неточности — фиг проверишь :)
paste.ly/K
вот его сокращенная для читаемости версия
вот его сокращенная для читаемости версия
Да, тестили мы правильный регекс, несколько тестов не прошло.
*уже ищу, где же эти тесты. если найду — выложу.
*уже ищу, где же эти тесты. если найду — выложу.
О раз искал этот регэксп, спасибо :)
А на пхп лучше делать так filter_var('mylo@mail.ru', FILTER_VALIDATE_EMAIL)
А на пхп лучше делать так filter_var('mylo@mail.ru', FILTER_VALIDATE_EMAIL)
НЛО прилетело и опубликовало эту надпись здесь
domain = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom
atom = 1*<any CHAR except specials, SPACE and CTLs>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.RFC822.
Потянет на кандидатскую в сфере IT :-)
А где ограничители регулярного выражения и модификаторы (если нужны)?
И что, нет никаких ограничений по длинне доменного имени?
000@000.000.000.000 в представлении вашего регэкспа — нормальный email
низачот.
Если нужна максимальная точность — достаточно простого регекспа.
Но после него в обязательном порядке должна идти функция проверки полученных данных.
Она может использовать как проверку существоания почтового сервера, к примеру на основе этой функции ru2.php.net/manual/en/function.dns-get-mx.php
Так и проверку на существование почтового адреса — отправка на него «секретной» ссылки с предложением подтвердить существование ящика.
Если нужна максимальная точность — достаточно простого регекспа.
Но после него в обязательном порядке должна идти функция проверки полученных данных.
Она может использовать как проверку существоания почтового сервера, к примеру на основе этой функции ru2.php.net/manual/en/function.dns-get-mx.php
Так и проверку на существование почтового адреса — отправка на него «секретной» ссылки с предложением подтвердить существование ящика.
Вот тут я могу с вам поспорить. Это касалось специфики проекта. Дело в том, что наш клиент брал монету с клиента за каждый адрес, на который было отправлено приглашение (ссылка на опрос). Поэтому предварительная проверка в виде «секретной» ссылки не подходит.
В остальном — я с вами полоностью согласен. Обычного регекспа — вполне достаточно.
В остальном — я с вами полоностью согласен. Обычного регекспа — вполне достаточно.
У меня сложилось впечатление, что вы меня не поняли. В вашем случае подходит второй параграф моего коммента.
Вместо проверки по регекспу, проверяется наличие и доступности почтового сервера для данного домена.
Вместо проверки по регекспу, проверяется наличие и доступности почтового сервера для данного домена.
а есть ли возможность проверить сам адрас этим сервисом?
блин :) какой еще сервис? Это стандартьный протокол отправки почты.
Можно погуглить в эту сторону:
www.google.com/search?hl=ru&client=iceweasel-a&rls=org.mozilla%3Aru%3Aunofficial&q=SMTP+VERIFY&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=lang_ru&aq=f&oq=
Но не все почтовые сервисы поддерживают такую команду.
Можно погуглить в эту сторону:
www.google.com/search?hl=ru&client=iceweasel-a&rls=org.mozilla%3Aru%3Aunofficial&q=SMTP+VERIFY&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=lang_ru&aq=f&oq=
Но не все почтовые сервисы поддерживают такую команду.
Для «серьёзной и точной» проверки использование ([a-zA-Z]{2,6}) для TLD — несерьёзно. Даже если не перечислять все двухбуквенные домены, уже получится что-то подобное:
(aero|arpa|asia|biz|cat|com|coop|edu|gov|info|int|jobs|mil|mobi|museum|name|net|org|pro|tel|travel|[a-z][a-z])
Ужас. А что в качестве доменной части указать что-то типа 77.88.0x15.010 yельзя уже? Вполне себе коректная domain part.
Да и убивать нужно за такой хард код. Вы на каждый введенные домен первого уровня будите в код лазить менять?
Да и убивать нужно за такой хард код. Вы на каждый введенные домен первого уровня будите в код лазить менять?
IP-адреса в доменной части обрабатываются отдельно (см. регэкс автора). Локальные емейлы типа «director@corporate.lan» для большинства интернет-проектов неактуальны (корпоративные — отдельная тема). Оставшийся вариант будет содержать тот или иной TLD из списка ICANN.
Претензии насчёт хард-кода не понял. Как вы по одному выражению определили, что оно записано в коде программы, а не в конфигурации?
Претензии насчёт хард-кода не понял. Как вы по одному выражению определили, что оно записано в коде программы, а не в конфигурации?
Естественно этот регексп — часть конфигурации. Как и откуда брать файл, тип файла, и Sheet/Column если это экселевский файл.
Коде программы или в конфигурации, суть не меняется.
Вот сейчас домены первого уровня будут плодиться как грибы — зачем их хардкодить, если можно просто сделать проверку соответсвия стандарту и все?
У нас же не стоит задачи проверить существует ли такой email — у нас задача проверить соответсвие его записи стандарту если я правльно понял исходные условия.
Вот смотрите — вы допустим сделаете это условия. Значит в описании функции в документации вам нужно указать — все текущие домены которые она поддерживает, опистаь как и где поменять и добавить текущий домен. Для добавления вам нужно поменить код(конфигурационный файл), документацию и прочее, прочее.
И зачем? Что это даст?
Вот сейчас домены первого уровня будут плодиться как грибы — зачем их хардкодить, если можно просто сделать проверку соответсвия стандарту и все?
У нас же не стоит задачи проверить существует ли такой email — у нас задача проверить соответсвие его записи стандарту если я правльно понял исходные условия.
Вот смотрите — вы допустим сделаете это условия. Значит в описании функции в документации вам нужно указать — все текущие домены которые она поддерживает, опистаь как и где поменять и добавить текущий домен. Для добавления вам нужно поменить код(конфигурационный файл), документацию и прочее, прочее.
И зачем? Что это даст?
Задача была
Да, на поддержание актуальности списка потребуются дополнительные усилия (к счастью, список актуальных TLD меняется далеко не каждый месяц). В некоторых случаях эти усилия оправданы, в некоторых — нет. Для вышеприведённой задачи — оправданы.
Исключить максимальное количество заведомо невалидных адресов.Например, адрес mail@mail.mail — заведомо невалидный. Выражение автора его пропустит, а проверка по существующим доменам первого уровня — забракует.
Да, на поддержание актуальности списка потребуются дополнительные усилия (к счастью, список актуальных TLD меняется далеко не каждый месяц). В некоторых случаях эти усилия оправданы, в некоторых — нет. Для вышеприведённой задачи — оправданы.
НЛО прилетело и опубликовало эту надпись здесь
Кто-то мне сможет ответить в чем смысл настолько дотошной проверки e-mail'а?
Mail::RFC822::Address: regexp-based address validation
www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
Самая точная проверка email'a — отправьте на него сообщение вида:
«Для подтверждения эл.почты перейдите по ссылке»
«Для подтверждения эл.почты перейдите по ссылке»
Ох уж мне эти сказочники… :-)
Тут автору уже указали на многие недочёты. Могу добавить, что автор не учёл комментарии (см RFC). Но дело даже не в этом. Автор, почитайте что-нибудь по регекспам (рекомендую Фридла), в любой хорошей книжке вам напишут, что нельзя написать регексп, разбирающий e-mail в полном согласии с RFC (e-mail — это классический пример задачи, неразрешимой с помощью регекспов). Вернее, такой регексп написать можно, но только используя рекурсию, а при этом регексп становится небезопасным, так как можно подсунуть ему такие даные, что он начнёт жрать слишком много ресурсов или даже будет циклиться и виснуть.
Вот популярное объяснение, почему if you need a 100% rock solid check for e-mail, don't use a regex.
Тут автору уже указали на многие недочёты. Могу добавить, что автор не учёл комментарии (см RFC). Но дело даже не в этом. Автор, почитайте что-нибудь по регекспам (рекомендую Фридла), в любой хорошей книжке вам напишут, что нельзя написать регексп, разбирающий e-mail в полном согласии с RFC (e-mail — это классический пример задачи, неразрешимой с помощью регекспов). Вернее, такой регексп написать можно, но только используя рекурсию, а при этом регексп становится небезопасным, так как можно подсунуть ему такие даные, что он начнёт жрать слишком много ресурсов или даже будет циклиться и виснуть.
Вот популярное объяснение, почему if you need a 100% rock solid check for e-mail, don't use a regex.
А айпишники с числами более 255 тоже проходят?
А где проверка номера порта?
А если айпишник IPv6?
А где проверка номера порта?
А если айпишник IPv6?
И вообще бедный заказчик… получит абсолютно не читаемый и не поддерживыемый код.
Ответьте — вот если бы вы сами получили бы такой кусок кода и просьбу проверить корректность работы? Думаеться первое чтобы вы сделали это бы выкинули его и написали новый с нуля.
Есть все же мнение что для больших проектов использование регэкспов в таком вот виде нужно запрещать.
Ответьте — вот если бы вы сами получили бы такой кусок кода и просьбу проверить корректность работы? Думаеться первое чтобы вы сделали это бы выкинули его и написали новый с нуля.
Есть все же мнение что для больших проектов использование регэкспов в таком вот виде нужно запрещать.
Ваши предложения? Написать без регекспа?
Да, я бы как заказчик или как code support предпочел бы получить код виде явно реализованного конечного автомата.
В крайнем случае в виде ряда отдельных функций, как минимум фукция выделения local part и domain part и две функции проверки local и domain парт.
Внутри них подфункции проверки отдельных условий по RFC с указанием в комментариях какое именно условие проверяет эта функция.
Получиться больше кода, но зато он будет поддерживаемым и читабельным. Что на мой взгляд сильно важнее чем размер исходников.
В крайнем случае в виде ряда отдельных функций, как минимум фукция выделения local part и domain part и две функции проверки local и domain парт.
Внутри них подфункции проверки отдельных условий по RFC с указанием в комментариях какое именно условие проверяет эта функция.
Получиться больше кода, но зато он будет поддерживаемым и читабельным. Что на мой взгляд сильно важнее чем размер исходников.
A-Z, a-z — ну фиг знает, домены перестают быть только в латинице, как и мейлы.
Мне кажется, если очень хочется сделать формально правильную проверку, надо использовать парсер.
Точно не скажу что подойдёт для BNF, но есть подозрение что любой парсерогенератор.
Точно не скажу что подойдёт для BNF, но есть подозрение что любой парсерогенератор.
Откройте вами же приведенную ссылку и внимательно прочтите пункт 6.1. Когда же, наконец, писатели регулярных выражений узнают, что remal <mail@domain.com> является валидным мылом?
Когда я прочитал название топика (в «Прямом эфире»), я подумал, что зайдя сюда, найду в качестве содержимого одно слово: «Невозможна»… ну или по крайней мере что-то в таком духе.
Кстати, даже если не касаться конкретно e-mail адресов, известно, что «если у вас есть проблема и вы собрались использовать для её решения регулярные выражения, то теперь у вас две проблемы» :)
Кстати, даже если не касаться конкретно e-mail адресов, известно, что «если у вас есть проблема и вы собрались использовать для её решения регулярные выражения, то теперь у вас две проблемы» :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Точная проверка Email адреса регулярным выражением