Pull to refresh

Comments 57

Еще бы все это под кат, и вообще шикарно было бы
Не видел ваш коммент, но присоединяюсь камментом ниже.
внимательно читаем RFC

<local-part> ::= <dot-string> | <quoted-string>
<quoted-string> ::= """ <qtext> """
<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>

где у вас обраотка quoted-string?

правильный регэксп занимаем почти страницу
Правильный регэксп лежит здесь. Там даже если заподозришь, что есть неточности — фиг проверишь :)
Да, тестили мы правильный регекс, несколько тестов не прошло.
*уже ищу, где же эти тесты. если найду — выложу.
О раз искал этот регэксп, спасибо :)
А на пхп лучше делать так 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.
Что это Вы тут показали? Поясните, пожалуйста.
domain состоит из sub-domain, который может быть domain-ref. domain-ref это atom.

atom состоит из любых ASCII символов, кроме specials, SPACE и CTL. Подчёркивание в эти множества не входит, соответственно atom может содержать подчёркивания.
RFC822 — это устаревший RFC. Более актуален RFC2822
www.faqs.org/rfcs/rfc2822.html
Правда, содержимое RFC2822 читается так, что в домене получаются разрешенными вообще поголовно все символы, что еще более запутывает дело.

При этом, однако, есть более авторитетный в вопросах именования доменов RFC952
www.ietf.org/rfc/rfc952.txt
в котором русским по белому сказано:

>A «name» (Net, Host, Gateway, or Domain name) is a text string up
>to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
>sign (-), and period (.).

Ну и в других связанных RFC подчеркивание в домене запрещено.

Плюс, истина в последней инстанции BIND считает, что подчеркивания в домене быть не должно.

В общем, допускать подчеркивание в email'e не следует ни в коем разе.
А как насчёт того, что MTA может производить rewriting почтовых адресов, и поэтому domain не обязан быть реально существующим доменом?
А где ограничители регулярного выражения и модификаторы (если нужны)?
И что, нет никаких ограничений по длинне доменного имени?
А зачем?
У меня например есть qwertymegamailqwerty@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
Я его конечно для фана зарегал, но провайдер предупреждает что могу возникнуть проблемы у некоторых.
Ну да, всё верно, потому что максимальная длина доменного имени согласно RFC 1035 составляет 63 символа.
Именно поэтому последняя буква в вашем домене k, 63-я по счету
000@000.000.000.000 в представлении вашего регэкспа — нормальный email
ну как бы на ip это не очень похоже, и на домен не тянет
низачот.
Если нужна максимальная точность — достаточно простого регекспа.
Но после него в обязательном порядке должна идти функция проверки полученных данных.

Она может использовать как проверку существоания почтового сервера, к примеру на основе этой функции ru2.php.net/manual/en/function.dns-get-mx.php

Так и проверку на существование почтового адреса — отправка на него «секретной» ссылки с предложением подтвердить существование ящика.
Вот тут я могу с вам поспорить. Это касалось специфики проекта. Дело в том, что наш клиент брал монету с клиента за каждый адрес, на который было отправлено приглашение (ссылка на опрос). Поэтому предварительная проверка в виде «секретной» ссылки не подходит.

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

Вместо проверки по регекспу, проверяется наличие и доступности почтового сервера для данного домена.
а есть ли возможность проверить сам адрас этим сервисом?
Прошу прощения, думал это ссылка на сервис (которые мы тоже рассматривали как вариант).

Что касается функции протокола — мы рассматривали и это тоже и как раз из-за того что не все почтовые сервисы поддерживают такую команду — отказались.
я промолчу что регексп не гарантирует ничего :)
Для «серьёзной и точной» проверки использование ([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 — у нас задача проверить соответсвие его записи стандарту если я правльно понял исходные условия.

Вот смотрите — вы допустим сделаете это условия. Значит в описании функции в документации вам нужно указать — все текущие домены которые она поддерживает, опистаь как и где поменять и добавить текущий домен. Для добавления вам нужно поменить код(конфигурационный файл), документацию и прочее, прочее.

И зачем? Что это даст?
Задача была
Исключить максимальное количество заведомо невалидных адресов.
Например, адрес mail@mail.mail — заведомо невалидный. Выражение автора его пропустит, а проверка по существующим доменам первого уровня — забракует.

Да, на поддержание актуальности списка потребуются дополнительные усилия (к счастью, список актуальных TLD меняется далеко не каждый месяц). В некоторых случаях эти усилия оправданы, в некоторых — нет. Для вышеприведённой задачи — оправданы.
UFO landed and left these words here
Кто-то мне сможет ответить в чем смысл настолько дотошной проверки e-mail'а?
Судя по отсутствию ответов понял что это искусство ради любви к искусству. Что же, тоже неплохо :)
Хотелось бы подчеркнуть – что это частный случай в котором понадобилось использование серьезной и точной проверки (как требовал клиент). В иных случаях можно не заморачиваться :)

Последние строки статьи
Самая точная проверка email'a — отправьте на него сообщение вида:
«Для подтверждения эл.почты перейдите по ссылке»
Так Вы подтвердите не только существование ящика, но и желание получать от вас письма :)
Уже вижу, как приходит письмо — «Примите участие в опросе. Для подтверждения — перейдите по этой ссылке. После этого вам придет письмо с сылкой на опрос.» :)
Ребята, читайте комент выше. :)
Ох уж мне эти сказочники… :-)
Тут автору уже указали на многие недочёты. Могу добавить, что автор не учёл комментарии (см RFC). Но дело даже не в этом. Автор, почитайте что-нибудь по регекспам (рекомендую Фридла), в любой хорошей книжке вам напишут, что нельзя написать регексп, разбирающий e-mail в полном согласии с RFC (e-mail — это классический пример задачи, неразрешимой с помощью регекспов). Вернее, такой регексп написать можно, но только используя рекурсию, а при этом регексп становится небезопасным, так как можно подсунуть ему такие даные, что он начнёт жрать слишком много ресурсов или даже будет циклиться и виснуть.
Вот популярное объяснение, почему if you need a 100% rock solid check for e-mail, don't use a regex.
спасибо за информацию, учту!

черт возьми, приятно тут посты публиковать! и на ошибки укажут. и что то новое расскажут

спасибо.
А айпишники с числами более 255 тоже проходят?
А где проверка номера порта?
А если айпишник IPv6?
И вообще бедный заказчик… получит абсолютно не читаемый и не поддерживыемый код.

Ответьте — вот если бы вы сами получили бы такой кусок кода и просьбу проверить корректность работы? Думаеться первое чтобы вы сделали это бы выкинули его и написали новый с нуля.

Есть все же мнение что для больших проектов использование регэкспов в таком вот виде нужно запрещать.
Да, я бы как заказчик или как code support предпочел бы получить код виде явно реализованного конечного автомата.

В крайнем случае в виде ряда отдельных функций, как минимум фукция выделения local part и domain part и две функции проверки local и domain парт.
Внутри них подфункции проверки отдельных условий по RFC с указанием в комментариях какое именно условие проверяет эта функция.

Получиться больше кода, но зато он будет поддерживаемым и читабельным. Что на мой взгляд сильно важнее чем размер исходников.
Безусловно вы правы. К сожалению, как я ответил каментом выше — это всего лишь часть конфигурационного файла. Написать собственный код у меня не было возможности. Уж простите.
A-Z, a-z — ну фиг знает, домены перестают быть только в латинице, как и мейлы.
Мне кажется, если очень хочется сделать формально правильную проверку, надо использовать парсер.
Точно не скажу что подойдёт для BNF, но есть подозрение что любой парсерогенератор.
Откройте вами же приведенную ссылку и внимательно прочтите пункт 6.1. Когда же, наконец, писатели регулярных выражений узнают, что remal <mail@domain.com> является валидным мылом?
Когда я прочитал название топика (в «Прямом эфире»), я подумал, что зайдя сюда, найду в качестве содержимого одно слово: «Невозможна»… ну или по крайней мере что-то в таком духе.

Кстати, даже если не касаться конкретно e-mail адресов, известно, что «если у вас есть проблема и вы собрались использовать для её решения регулярные выражения, то теперь у вас две проблемы» :)
Only those users with full accounts are able to leave comments. Log in, please.