Кто-нибудь может объяснить это регулярное выражение мне в деталях?

Question

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

Строка выглядит следующим образом:

^[_a-zA-Z0-9-]+(.[_a-zA-Z0-9-]+)*@[a-zA-Z0-9-]+(.[a-zA-Z0-9-]+)*(.[a-zA-Z]{2,3})$

Заранее спасибо!

Answer 1

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

В CPAN существует множество модулей, таких как Email :: Valid , который позаботится обо всем за вас и будет проверен и протестирован.

Простой пример:

use Email::Valid;
print (Email::Valid->address('someone@example.com') ? 'yes' : 'no');

Гораздо проще, и будет просто работать.

В качестве альтернативы можно использовать Mail :: RFC822 :: Address :

if (Mail::RFC822::Address::valid('someone@example.com')) { ...}

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

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

Например, некоторые люди используют + в своем адресе, например bob+amazon@example.com - это называется «адресным тегом» или «подадресацией».Несколько наивных попыток валидации откажут в этом, и клиент в конечном итоге отправится куда-то еще.

Кроме того, в прошлом некоторые люди полагали, что TLD всегда будет состоять из 2 или 3 символов;когда, например, .info был запущен, людям с адресами в этих доменах сказали бы, что их совершенно действительный адрес электронной почты не приемлем.

Наконец, есть некоторые патологические случаи, такие как "Mickey Mouse"@example.com, bob@[1.2.3.4]которые синтаксически допустимы, но валидация валидации большинства людей откажется.

Answer 2

^[_a-zA-Z0-9-]+(.[_a-zA-Z0-9-]+)*@[a-zA-Z0-9-]+(.[a-zA-Z0-9-]+)*(.[a-zA-Z]{2,3})$

По частям

    ^  Start of the string

    [_a-zA-Z0-9-]+ One or more characters of "_" (no quotes), a letter (a-z, A-Z), a number (0-9), or "-" (no quotes)
    (.[_a-zA-Z0-9-]+)* zero or more substrings of type .something, or .123, or .a123. The substring must be formed by a . and a letter (same group of letters as before). So "." is not valid. ".a" or ".1" or ".-" is.

(до сих пор он принимает, например, my.name12 или my.name12.surname34)

    @ a "@" (like max@something)

    [a-zA-Z0-9-]+ One or more characters with the same pattern as before
    (.[a-zA-Z0-9-]+)* Zero or more substrings of type ".something"... just as before
    (.[a-zA-Z]{2,3}) A "." (dot) and 2 or 3 letters (a-z or A-Z)

    $ The end of the string

Итак, у нас есть адрес электронной почты, на котором у вас не может быть something.@somethingelse.ss (без "висячей" точки перед @) или .something@somethingelse.ss (без начальной точки). Домен должен начинаться с буквы и не может иметь точку непосредственно перед доменом первого уровня (.com / .uk / ??), поэтому нет something@x..com. Домен первого уровня должен состоять из 2 или 3 букв (без цифр)

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

Answer 3

Если я правильно понимаю, в соответствии с вашим регулярным выражением будет действовать следующее: a@a@a@a@aa
Точка является знаком для любого символа!
Кроме того, следующий действительный адрес электронной почты не будет принят, хотя он должен:
Someone%special@domain.de

Answer 4

Простой ответ: это не так.

Помимо того, что плохой адрес электронной почты не обязательно означает, что он неправильно отформатирован (this_email_address_does_not_exist@someprovider.com правильно отформатирован, но все еще плох),RegEx также примет некоторые неверные адреса.

Например, в самой правой части ((.[a-zA-Z]{2,3})$) указано, что проверенная строка должна заканчиваться точкой, а затем двумя или тремя буквами.Это позволит принять несуществующие доменные имена верхнего уровня (например, .aa ) и заблокирует четырехбуквенные TLD (например, .info )

.

Answer 5

Нет, это не исключает 100% неправильных адресов электронной почты.За исключением отклонения всех адресов, это невозможно для регулярного выражения, поскольку подавляющее большинство синтаксически допустимых адресов предназначено для несуществующих учетных записей, таких как shgercnhlch@stackoverflow.com.

Единственный способ действительно проверитьлегитимность адреса электронной почты заключается в том, чтобы пытаться отправить на него почту - и даже это скажет вам только то, что почта принимается по этому адресу, а не то, что она получена человеком (в отличие от подачи в сценарий или без уведомления)и даже если он получен человеком, вы не можете гарантировать, что это тот человек, который утверждал, что владеет им.(«Вы настаиваете на том, что я должен предоставить вам адрес электронной почты, подлежащий доставке? Хорошо. Мой адрес электронной почты president@whitehouse.gov.»)

Answer 6

[_a-zA-Z0-9-]

Означает, что вы хотите, чтобы в вашем адресе электронной почты были только эти символы (любой буквенно-цифровой символ или '-' или '_'), но он может быть действительным со всеми этими символами:! # $% & '* + - / =? ^ _ `{| } ~

Первая часть (до @) должна содержать не более 253 символов ({1,253}), а вторая часть (после @) может быть не более 64 символов ({4,64}). (Добавьте круглые скобки в первую или вторую группу, прежде чем ставить предел ({4,64}))

Если вы хотите узнать Норму адреса электронной почты, просто посмотрите википедию: Статья на вики

Answer 7

• RegEx будет принимать адреса электронной почты, начинающиеся с подчеркивания. Это (в основном) неприемлемо.
• Вы не установили какого-либо минимального ограничения на размер имени пользователя (то есть часть под символом "@"). Таким образом, односимвольные имена пользователей обойдут это. В сочетании с предыдущим исключением идентификаторы электронной почты типа _@something.com могут остаться незамеченными.
• . (точка) оператор принимает любой символ. Таким образом, после части "@" (недопустимые) домены типа @@. Com и т. Д. Могут остаться незамеченными.
• Принимаются домены только с 2 или 3 символами, остальные игнорируются.

Answer 8

возможно, это регулярное выражение подойдет?

^[_A-Za-z0-9-\+]+(\.[_A-Za-z0-9-]+)*@[A-Za-z0-9-]+(\.[A-Za-z0-9]+)*(\.[A-Za-z]{2,})$

взято из
http://www.mkyong.com/regular-expressions/how-to-validate-email-address-with-regular-expression/

Answer 9

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

(ЭТО ПРОБЛЕМА!)

Хорошо ... Давайте напишем это правильно:

^\s*([_a-zA-Z0-9]+(\\.[_a-zA-Z0-9\\-\\%]+)\*)@([a-zA-Z0-9]+(\\.[a-zA-Z0-9\\-]+)\*(\\.[a-zA-Z]{2,4}))\s*$

Сюда также входит символ % в качестве допустимого внутреннего значения. Проблема этой подпрограммы состоит в том, что, хотя она действительно выполняет неплохую работу по разбору адресов электронной почты, она также не очень эффективна, поскольку RegEx является «жадным» и завершающим условием (которое должно соответствовать таким вещам, как .com и .edu) произойдет перегрузка, после чего потребуется откат назад, что потребует значительного процессорного времени.

Реальный ответ заключается в использовании процедур, которые являются специфическими для этого, как рекомендовали другие авторы. Но если у вас нет модулей CPAN или целевой среды нет, то взломать RegEx возможно приемлемо.