Regexp распознавание адреса электронной почты трудно?

Ответ 1

Для формальной спецификации электронной почты, да, это технически невозможно через Regex из-за рекурсии таких вещей, как комментарии (особенно если вы сначала не удаляете комментарии в пробелы) и различные различные форматы (e- адрес электронной почты не всегда [email protected]). Вы можете приблизиться (с некоторыми массивными и непонятными шаблонами Regex), но гораздо лучший способ проверить электронную почту - сделать очень знакомое рукопожатие:

• они сообщают вам свое электронное письмо
• вы отправляете им по электронной почте ссылку с рекомендацией

• когда они нажимают на ссылку, которую вы знаете,

  • электронное письмо верное.
  • он существует
  • им принадлежат

Гораздо лучше, чем слепо принять адрес электронной почты.

Ответ 2

Существует несколько модулей Perl (например), которые делают это. Не пытайтесь писать свое собственное регулярное выражение, чтобы это сделать. Посмотрите

Mail::VRFY будет выполнять синтаксические и сетевые проверки (и сервер SMTP где-то принимает этот адрес)

https://metacpan.org/pod/Mail::VRFY

RFC::RFC822::Address - рекурсивный синтаксический анализатор адресов электронной почты.

https://metacpan.org/pod/RFC::RFC822::Address

Mail::RFC822::Address - проверка правильности адресов на основе regexp, заслуживающая внимания только для безумного регулярного выражения

http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

Аналогичные инструменты существуют для других языков. Insane regexp ниже...

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

Ответ 3

Проверка адресов электронной почты на самом деле не очень помогает. Он не будет улавливать общие опечатки или созданные адреса электронной почты, поскольку они имеют тенденцию выглядеть синтаксически, как действительные адреса.

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

Если вы просто хотите быть уверенным, что пользователь вводит что-то похожее на электронную почту, а не просто "asdf", тогда проверьте наличие @. Более сложная проверка не дает никакой пользы.

(Я знаю, что это не отвечает на ваши вопросы, но я думаю, что это все равно стоит упомянуть)

Ответ 4

Теперь я собрал тестовые примеры от Cal Henderson, Dave Child, Phil Haack, Doug Lovell и RFC 3696. Всего 158 тестовых адресов.

Я провел все эти тесты со всеми проверками, которые я смог найти. Сравнение здесь: http://www.dominicsayers.com/isemail

Я постараюсь сохранить эту страницу в актуальном состоянии, так как люди повышают эффективность своих валидаторов. Благодаря Cal, Dave и Phil за их помощь и сотрудничество в компиляции этих тестов и конструктивной критике моего собственного валидатора.

Люди должны знать об ошибках в отношении RFC 3696. Три из канонических примеров на самом деле являются неверными адресами. И максимальная длина адреса составляет 254 или 256 символов, не 320.

Ответ 5

В BNF существует контекстная свободная грамматика, которая описывает действительные адреса электронной почты в RFC-2822. Это сложно. Например:

" @ "@example.com

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

Ответ 6

Это не всякая глупость, хотя использование символов типа "+" может быть очень полезно для пользователей, борющихся со спамом, например. [email protected](мгновенные одноразовые адреса Gmail).

Только в том случае, если сайт принимает его.

Ответ 7

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

Если вы пишете почтовый сервер, вы должны быть очень точными и мучительно правильными в том, что вы принимаете. Таким образом, приведенное выше "безумное" регулярное выражение подходит.

Для остальных из нас, однако, мы в основном просто заинтересованы в том, чтобы что-то, что пользователь вводит в виде веб-формы, выглядит разумным и не имеет какой-либо SQL-инъекции или переполнения буфера в нем.

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

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

Да, это означает, что я отклоняю действительные адреса, с которыми кто-то может зарегистрироваться на моих веб-сайтах - возможно, я "неправильно" отклоняю до 0,001% адресов в реальном мире! Я могу жить с этим.

Ответ 8

Цитата и различные другие редко используемые, но действительные части RFC затрудняют ее. Я не знаю достаточно об этой теме, чтобы комментировать окончательно, кроме "это сложно", но, к счастью, другие люди имеют написано об этом.

Что касается правильного регулярного выражения для него, модуль Perl Mail:: Rfc822:: Address содержит регулярное выражение, которое, по-видимому, будет работать - но только если какие-либо комментарии уже были заменены пробелами. (Комментарии в электронном адресе? Вы видите, почему это сложнее, чем можно было ожидать...)

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

Ответ 9

Некоторые варианты регулярных выражений могут фактически соответствовать вложенным скобкам (например, Perl-совместимым). Тем не менее, я видел регулярное выражение, которое утверждает, что правильно соответствует RFC 822, и это были две страницы текста без пробелов. Таким образом, лучший способ определить действительный адрес электронной почты - отправить ему электронное письмо и посмотреть, работает ли он.

Ответ 10

Просто добавьте регулярное выражение, которое будет менее сумасшедшим, чем тот, который указан @mmaibaum:

^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)[email protected]([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$ 

Он не является пуленепробиваемым и, конечно же, не охватывает всю спецификацию электронной почты, но он действительно подходит для покрытия большинства основных требований. Еще лучше, он несколько понятен и может быть отредактирован.

Cribbed из обсуждения на HouseOfFusion.com, ресурсе ColdFusion мирового класса.

Ответ 11

Простой и эффективный способ проверки адресов электронной почты в Java заключается в использовании EmailValidator библиотеки Apache Commons Validator.

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

Ответ 12

Это очень сложно, потому что есть много вещей, которые могут быть действительными в адресе электронной почты в соответствии с Спецификацией электронной почты, RFC 2822. Вещи, которые вы обычно не видите, такие как +, являются абсолютно допустимыми символами для адреса электронной почты.. согласно спецификации.

Здесь есть раздел, посвященный адресам электронной почты на http://regexlib.com, который является отличным ресурсом. Я бы посоветовал вам определить, какие критерии имеют значение для вас, и найти тот, который соответствует. Большинство людей действительно не нуждаются в полной поддержке всех возможностей, разрешенных спецификацией.

Ответ 13

Если вы работаете в .NET Framework, просто попробуйте создать экземпляр объекта MailAddress и поймать FormatException, если он взорвется, или вытащить Address, если он будет успешным. Не вдаваясь в какие-либо глупости о выполнении исключений ловли (на самом деле, если это только одна веб-форма, это не будет иметь особого значения), класс MailAddress в .NET Framework проходит через довольно полный процесс разбора (он не использует RegEx). Откройте рефлектор и найдите MailAddress и MailBnfHelper.ReadMailAddress(), чтобы увидеть все причудливые вещи, которые он делает. Кто-то умнее меня потратил много времени на создание этого анализатора в Microsoft, я собираюсь использовать его, когда я действительно отправляю электронное письмо на этот адрес, поэтому я мог бы также использовать его для проверки входящего адреса.

Ответ 14

Попробуйте следующее:

"(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])"

Посмотрите здесь для деталей.

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

Ответ 15

Многие пытались, и многие приходят близко. Вы можете прочитать статью wikipedia и some другие.

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

Ответ 16

Этот класс для Java имеет в нем валидатор: http://www.leshazlewood.com/?p=23

Это написано создателем Сиро (формально Ki, формально JSecurity)

Достоинства и недостатки тестирования на достоверность почтового адреса:

Существует два типа регулярных выражений, которые проверяют электронную почту:

• Они слишком свободны.
• Те, которые слишком строги.

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

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

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

Ответ 17

Может кто-нибудь дать некоторое представление о том, почему это?

Да, это чрезвычайно сложный стандарт, который позволяет много вещей, которые никто сегодня не использует. :)

Существуют ли какие-либо известные и проверенные регулярные выражения, которые действительно делают это полностью?

Вот одна попытка полностью разобрать весь стандарт...

http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

Каковы хорошие альтернативы использованию регулярных выражений для сопоставления адресов электронной почты?

Используя существующую структуру для него на любом языке, который вы используете, я думаю? Хотя они, вероятно, будут использовать регулярное выражение внутри. Это сложная строка. Регулярные выражения предназначены для синтаксического анализа сложных строк, так что это действительно ваш лучший выбор.

Изменить. Я должен добавить, что связанное с regexp связанное было просто для удовольствия. Я не поддерживаю использование такого сложного регулярного выражения, как некоторые люди говорят, что "если ваше регулярное выражение больше одной строки, у него наверняка будет ошибка". Я связан с ним, чтобы проиллюстрировать, насколько сложным является стандарт.

Ответ 18

Добавив в ответ Wayne, также есть раздел www.regular-expressions.info, посвященный электронной почте, с несколько образцов.

Вы всегда можете задать вопрос, стоит ли это, или если на самом деле любое регулярное выражение, меньшее чем 100%, только способствует ложному пониманию безопасности.

В конце концов, фактически отправка электронной почты - это то, что обеспечит реальную окончательную проверку. (вы узнаете, есть ли у вашего почтового сервера ошибки; -)

Ответ 19

Для полноты этой публикации, также для PHP есть встроенная функция языка для проверки электронной почты.

Для PHP Используйте nice filter_var со специфическим типом проверки EMAIL:)

Нет более сумасшедших регулярных выражений в php: D

var_dump(filter_var('[email protected]', FILTER_VALIDATE_EMAIL));

http://www.php.net/filter_var