Регулярка для проверки email: Как проверять email адрес на валидность правильно
Регулярное выражение проверки email
От автора: приветствую вас друзья. В этой статье мы рассмотрим различные варианты регулярных выражений для валидации emai, а также составим собственное регулярное выражение проверки email. Приступим?
Валидация адреса email — это, пожалуй, одна из наиболее распространенных задач при работе с регулярными выражениями. Это и не удивительно, поскольку email в современном вебе используется сплошь и рядом. Без него практически не обходятся при регистрации пользователей. И вот здесь нам нужно проверить, а соответствует ли введенная пользователем в поле строка формату email.
Сразу отмечу, что наиболее точный ответ даст только вариант с обратной связью. Суть его заключается в том, что по введенному адресу отправляется письмо со ссылкой, по которой пользователь должен перейти для подтверждения регистрации. Соответственно, регистрация будет завершена только в том случае, если пользователь ввел реальный email.
Это единственный 100% способ проверки email. Все прочие нам дадут лишь проверку на соответствие формату, не более. Но поскольку у нас есть задача составить регулярное выражение — давайте его составим. Тем более что его вполне можно использовать на стороне клиента, тем самым улучшив юзабилити вашей формы регистрации.
Итак, начать стоит с того, что в сети вы можете встретить массу различных вариантов регулярок для проверки email. Как вам такой вариант?
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
В курсе 39 уроков | 15 часов видео | исходники для каждого урока
Получить курс сейчас!
Страшно, не правда ли? Это шаблон для валидации email согласно стандарту. Я, конечно же, ни в коем разе не советую вам использовать такие шаблоны. Советую подыскать что-то попроще или составить шаблон самому. Собственно, пойду дальше — советую использовать максимально простой шаблон.
@]+
Вероятно, вы также захотите отклонить пробелы – в них, вероятно, есть допустимые адреса электронной почты с пробелами, но я их никогда не видел, поэтому вероятность того, что это ошибка пользователя, на вашей стороне.
Если вам нужна полная проверка, взгляните на этот вопрос .
Обновление. Вот как вы можете использовать любое такое регулярное выражение:
import re if not re.match(r"... regex here ...", email): # whatever Обратите внимание на r перед строкой; таким образом, вам не нужно будет избегать вещей дважды.
Если у вас есть большое количество регулярных выражений для проверки, возможно, быстрее скомпилировать регулярное выражение:
import re EMAIL_REGEX = re.compile(r"... regex here ...") if not EMAIL_REGEX.match(email): # whatever Стандартная библиотека Python поставляется с функцией разбора электронной почты: email.utils.parseaddr() .
Он возвращает двухкортеж, содержащий настоящее имя и фактические адреса электронной почты:
>>> from email.utils import parseaddr >>> parseaddr('[email protected]') ('', '[email protected]') >>> parseaddr('Full Name <[email protected]>') ('Full Name', '[email protected]') >>> parseaddr('"Full Name with quotes and <[email protected]>" <[email protected]>') ('Full Name with quotes and <[email protected]>', '[email protected]') И если синтаксический анализ не увенчался успехом, он возвращает два кортежа пустых строк:
>>> parseaddr('[invalid!email]') ('', '') Проблема с этим парсером заключается в том, что он принимает все, что считается действительным адресом электронной почты для RFC-822 и друзей, включая многие вещи, которые явно не адресуются в широком Интернете:
>>> parseaddr('invalid@example,com') # notice the comma ('', 'invalid@example') >>> parseaddr('invalid-email') ('', 'invalid-email') Таким образом, как сказал @TokenMacGuy, единственный окончательный способ проверки адреса электронной почты – отправить электронное письмо на ожидаемый адрес и дождаться, когда пользователь будет воздействовать на информацию внутри сообщения.
Тем не менее, вы можете проверить, по крайней мере, наличие @ -сигнала для второго элемента кортежа, поскольку @bvukelic предлагает:
>>> '@' in parseaddr("invalid-email")[1] False Если вы хотите сделать еще один шаг, вы можете установить проект dnspython ( или этот для Python 3 ) и разрешить почтовые серверы для домена электронной почты (часть после «@»), только пытаясь отправить e -mail, если есть реальные серверы MX :
>>> from dns.resolver import query >>> domain = 'foo@[email protected]'.rsplit('@', 1)[-1] >>> bool(query(domain, 'MX')) True >>> query('example.com', 'MX') Traceback (most recent call last): File "<stdin>", line 1, in <module> [...] dns.resolver.NoAnswer >>> query('not-a-domain', 'MX') Traceback (most recent call last): File "<stdin>", line 1, in <module> [...] dns.resolver.NXDOMAIN Вы можете поймать как NoAnswer и NXDOMAIN , dns.exception.DNSException .
И да, foo@[email protected] – синтаксически действительный адрес. Следует учитывать только последнее значение @ для определения того, где начинается домен.
Адреса электронной почты не так просты, как кажется! Например, Bob_O’[email protected] – действительный адрес электронной почты.
Мне повезло с пакетом lepl ( http://www.acooke.org/lepl/ ). Он может проверять адреса электронной почты, как указано в RFC 3696: http://www.faqs.org/rfcs/rfc3696.html
Нашел старый код:
import lepl.apps.rfc3696 email_validator = lepl.apps.rfc3696.Email() if not email_validator("[email protected]"): print "Invalid email" Я не видел ответа уже здесь среди беспорядка пользовательских ответов Regex, но …
У Python есть модуль под названием validate_email, который имеет 3 уровня проверки подлинности электронной почты, включая запрос действительного SMTP-сервера, если адрес электронной почты действителен (без отправки электронной почты).
Проверьте правильность формата электронной почты:
from validate_email import validate_email is_valid = validate_email('[email protected]') Проверьте, имеет ли сервер SMTP-сервер:
is_valid = validate_email('[email protected]',check_mx=True) Проверьте, есть ли у хоста SMTP-сервер, и действительно ли письмо существует:
is_valid = validate_email('[email protected]',verify=True) Для тех, кто интересуется грязными деталями, validate_email.py ( источник ) стремится быть верным RFC 2822 .
Все, что мы действительно делаем, это сравнение входной строки с одним гигантским регулярным выражением. Но создание этого регулярного выражения и обеспечение его правильности облегчается путем сборки его из «токенов», определенных RFC. Каждый из этих токенов проверяется в прилагаемом файле тестового файла.
Чтобы установить с помощью pip
pip install validate_email и вам понадобится модуль pyDNS для проверки SMTP-серверов
pip install pyDNS Обычно это решается с помощью регулярного выражения. Однако существует множество вариантов решений. В зависимости от того, насколько строго вы должны быть, и если у вас есть пользовательские требования к валидации или принимаете действительный адрес электронной почты.
См. Эту страницу для справки: http://www.regular-expressions.info/email.html
Здесь я вижу много сложных ответов. Некоторые из них, не знают простого, истинного адреса электронной почты или имеют ложные срабатывания. Ниже приведен самый простой способ проверки того, что строка будет действительным адресом электронной почты. Он тестирует 2 и 3 буквы TLD. Теперь, когда вы технически можете иметь более крупные, вы можете увеличить 3 до 4, 5 или даже 10.
import re def valid_email(email): return bool(re.
[a-zA-Z0-9_.+-]+@[a-zA-Z0-9]+\.[a-zA-Z0-9.]*\.*[com|org|edu]{3}$)",email) if match: return 'Valid email.' else: return 'Invalid email.' 
[a-zA-Z0-9_.+-]+@[a-zA-Z0-9]+\.[a-zA-Z0-9.]*\.*[com|org|edu]{3}$)",email) if match: return 'Valid email.' else: return 'Invalid email.' Единственный действительно точный способ отличить реальные, действительные адреса электронной почты от недействительных – это отправить ему письмо . То, что считается электронной почтой, удивительно запутанно ( "John Doe" <[email protected]>" действительно является допустимым адресом электронной почты), и вы, скорее всего, хотите, чтобы адрес электронной почты фактически отправил ему письмо позже. некоторые основные проверки здравомыслия (например, в ответе Томаса, имеют @ и по крайней мере один . после @ ), вы, вероятно, должны просто отправить письмо с подтверждением электронной почты на адрес и дождаться, когда пользователь выполнит ссылку, встроенную в сообщение чтобы подтвердить, что письмо действительно.
Регулярное выражение для проверки E-mail
Прежде чем составлять регулярное выражение для проверки адреса электронной почты, нужно определить символы, которые допускаются в названии почтовых ящиков.
Таблица допустимых символов в названии E-mail
| Почтовый сервис | Допустимые символы | Количество символов | Первый символ | Последний символ | Два спецсимвола подряд1 | Регистр |
|---|---|---|---|---|---|---|
| AOL | [.0-9a-z_] | {3,32} | [a-z] | [0-9a-z] | Запрещено | Не учитывается |
| FASTMAIL2 (домены) | [0-9a-z_] | {3,30} | [a-z] | [0-9a-z_] | Разрешено | Только строчные |
| GMAIL | [.0-9a-z] | {6,30} | [0-9a-z] | [0-9a-z] | Запрещено | Не учитывается |
HUSHMAIL
| [-.0-9a-z_] | {1,45} | [0-9a-z] | [0-9a-z] | Нельзя повторять одинаковые спецсимволы, однако можно их чередовать | Не учитывается |
| LYCOS | [-.0-9a-z_] (между цифрами точка не допускается) | {1,32} | [a-z] | [0-9a-z] | Разрешено использовать два и более идущих подряд знаков подчёркивания и его чередование с дефисом (чередование с точкой запрещено) | Не учитывается |
MAIL.RU
| [-.0-9a-z_] | {4,31} | [0-9a-z] | [0-9a-z] | Запрещено | Не учитывается |
| META.UA | [-.0-9a-z_] | {4,20} | [a-z] | [0-9a-z] | Разрешено | Не учитывается |
MICROSOFT
| [-.0-9a-z_] | {1,64} | [a-z] | [-0-9a-z_] | Разрешается последовательность из «_» или «-», однако использование двух точек подряд запрещено | Не учитывается |
RAMBLER
| [-.0-9a-z_] | {3,32} | [0-9a-z] | [0-9a-z] | Запрещено | Не учитывается |
YAHOO
| [.0-9a-z_] (точку разрешается использовать один раз) | {4,32} | [a-z] | [0-9a-z] | Запрещено | Не учитывается |
YANDEX
| [-.0-9a-z] | {1,30} | [a-z] | [0-9a-z] | Запрещено | Не учитывается |
| ИТОГО | [-.0-9a-z_] | {1,64}3 | [0-9a-z] | [-0-9a-z_] | Разрешено | +/-2 |
comИсходя из данных таблицы, подобрать необходимое регулярное выражения, учитывая возможный контингент (русскоязычные, англоязычные и так далее) посетителей сайта, труда не составит.
Как вариант, можно ограничить выбор почтового домена или доменной зоны, предоставляя пользователю возможность выбрать его из выпадающего списка:
@
gmail.commail.ruya.ru
@
.
comru
Готовое выражение
Итак, прежде чем составлять «регулярку», рекомендую прочитать эту статью, вывод которой в том, что не стоит проверять E-mail громоздким регулярным выражением, создавая себе, тем самым, дополнительную головную боль; достаточно использовать один из следующих вариантов, а основную проверку проводить, посылая на введённый пользователем адрес письмо с подтверждением:
=@=
=.+?@.+?\..+=i
Чтобы не потерять мысль, которая пришла мне в голову при написании данного поста, отмечу один из вариантов проверки E-mail, который 100% пропустит только корректный адрес: 1) разделяем имя ящика и почтовый домен; 2) по почтовому домену выбираем регулярное выражение, которым проверяем имя. Я не рекомендую использовать этот метод, однако могут быть случаи, когда в этом будет необходимость. Протестировать скрипт можно здесь.
регулярное выражение для проверки Email
Задача проверки введенного Email-адреса на валидность используется практически на каждом сайте, который предполагает взаимодействие с пользователем. Поле Email при вводе комментариев в блоге, при оформлении заказа в интернет-магазине, при регистрации пользователя.
(?:[A-Z0-9-]+\.)+[A-Z]{2,6}$/i
upd:
http://habrahabr.ru/blogs/personal/74206/
http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html
http://habrahabr.ru/blogs/regex/55820/
http://www.gskinner.com/RegExr/
сервис с возможностью тестирования регулярных выражений
Опубликовано
Понедельник, Сентябрь 7, 2009 в 07:34 в следующих категориях: Без рубрики.
Вы можете подписаться на комментарии к этому сообщению через RSS 2.0.
Вы можете добавить комментарий, или trackback со своего сайта.
— ~ \ t] | (\\ [\ t — ~])) + «) @ [0-9A-Za-z] ([0-9A-Za-z -] {0,61} [0-9A -Za-z])? (\. [0-9A-Za-z] ([0-9A-Za-z -] {0,61} [0-9A-Za-z])?) +
Адреса, соответствующие этому регулярному выражению:
- имеют локальную часть (то есть часть перед знаком @), которая строго соответствует RFC 5321/5322,
- есть доменная часть (то есть часть после знака @), которая представляет собой имя хоста, по крайней мере, с двумя метками, каждая из которых имеет длину не более 63 символов.
У
Второе ограничение — это ограничение RFC 5321/5322.
Использование регулярного выражения, которое распознает адреса электронной почты, может быть полезно в различных ситуациях: например, для сканирования адресов электронной почты в документе, для проверки ввода данных пользователем или в качестве ограничения целостности в репозитории данных.
Однако следует отметить, что если вы хотите узнать, действительно ли адрес относится к существующему почтовому ящику, нет замены отправке сообщения на этот адрес. Если вы хотите только проверить грамматически правильный адрес, вы можете использовать регулярное выражение, но обратите внимание, что "" @ [] — это грамматически правильный адрес электронной почты, который определенно не относится к существующему почтовому ящику.
Синтаксис адресов электронной почты был определен в различных RFC, в первую очередь RFC 822 и RFC 5322. RFC 822 следует рассматривать как «исходный» стандарт, а RFC 5322 как последний стандарт. Синтаксис, определенный в RFC 822, является наиболее мягким, и последующие стандарты все больше и больше ограничивали синтаксис, когда новые системы или службы должны распознавать устаревший синтаксис, но никогда его не создавать.
В этом ответе я буду понимать, что «адрес электронной почты» означает addr-spec , как определено в RFC (т.е.е. [email protected] , но не "John Doe" , ни some-group: jdoe @ example.org, mrx @example.org; ).
Есть одна проблема с преобразованием синтаксиса RFC в регулярные выражения: синтаксис не является правильным! Это связано с тем, что они допускают необязательные комментарии в адресах электронной почты, которые могут быть бесконечно вложенными, в то время как бесконечное вложение не может быть описано регулярным выражением. Чтобы сканировать или проверять адреса, содержащие комментарии, вам понадобится синтаксический анализатор или более мощные выражения.(Обратите внимание, что такие языки, как Perl, имеют конструкции для описания контекстно-свободных грамматик в виде регулярных выражений.) В этом ответе я проигнорирую комментарии и буду рассматривать только правильные регулярные выражения.
RFC определяют синтаксис для сообщений электронной почты, а не для адресов электронной почты как таковых. Адреса могут появляться в различных полях заголовков, и именно здесь они в основном определяются. Когда они появляются в полях заголовков, адреса могут содержать (между лексическими токенами) пробелы, комментарии и даже разрывы строк. Однако семантически это не имеет значения.Удалив этот пробел и т. Д. Из адреса, вы получите семантически эквивалентное каноническое представление . Таким образом, каноническое представление первое. — это last (comment) @ [3.5.7.9] first.last @ [3.5.7.9] .
Для разных целей следует использовать разные синтаксисы. Если вы хотите сканировать адреса электронной почты в (возможно, очень старом) документе, может быть хорошей идеей использовать синтаксис, определенный в RFC 822. С другой стороны, если вы хотите проверить ввод данных пользователем, вы можете использовать синтаксис, как определено в RFC 5322, вероятно, принимает только канонические представления.\ r])) * (\\\ r) *])) *
Я считаю, что он полностью соответствует RFC 822, включая исправления. Он распознает только адреса электронной почты в их канонической форме. Для регулярного выражения, распознающего (сворачивающего) пробелы, см. Вывод ниже.
Вывод показывает, как я пришел к выражению. Я перечисляю все соответствующие грамматические правила из RFC в том виде, в котором они появляются, за которым следует соответствующее регулярное выражение. Если была опубликована ошибка, я даю отдельное выражение для исправленного грамматического правила (помечено как «erratum») и использую обновленную версию как часть выражения в последующих регулярных выражениях.
Как указано в п. 3.1.4. RFC 822 между лексическими токенами может быть вставлен необязательный линейный пробел. Где это применимо, я расширил выражения, чтобы учесть это правило, и пометил результат как «opt-lwsp».
CHAR = <любой символ ASCII>
= ~.
CTL = <любой управляющий символ ASCII и DEL>
= ~ [\ x00- \ x1F \ x7F]
CR =
= ~ \ r
LF =
= ~ \ n
ПРОБЕЛ =
= ~
HTAB =
= ~ \ t
<"> = <Кавычки ASCII>
= ~ "
CRLF = CR LF
= ~ \ r \ n
LWSP-char = ПРОБЕЛ / HTAB
= ~ [\ t]
линейный-пробел = 1 * ([CRLF] LWSP-char)
= ~ ((\ r \ n)? [\ t]) +
specials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> /". - ~]
точка-атом-текст = 1 * текст * (".- ~] *])
Обратите внимание, что некоторые источники (особенно w3c) утверждают, что RFC 5322 слишком строг в отношении локальной части (т.е. части перед знаком @). Это потому, что «..», «а..б» и «а». являются , а не действительными точечными атомами, хотя они могут использоваться как имена почтовых ящиков. RFC, однако, не допускает использования таких локальных частей, за исключением того, что они должны быть указаны в кавычках. Поэтому вместо a..b @ example.net вы должны написать "a..b"@example.net «, что семантически эквивалентно.
Дополнительные ограничения
SMTP (как определено в RFC 5321) дополнительно ограничивает набор действительных адресов электронной почты (или фактически: имена почтовых ящиков). Кажется разумным ввести эту более строгую грамматику, чтобы совпавший адрес электронной почты действительно можно было использовать для отправки электронного письма.
RFC 5321 в основном оставляет в покое «локальную» часть (то есть часть перед знаком @), но строже относится к части домена (то есть части после знака @). Он позволяет использовать только имена хостов вместо точечных атомов и адресные литералы вместо доменных литералов.- ~ \ t] | (\\ [\ t — ~])) + «) @ ([0-9A-Za-z] ([0-9A-Za-z -] {0,61} [0- 9A-Za-z])? (\. [0-9A-Za-z] ([0-9A-Za-z -] {0,61} [0-9A-Za-z])?) * | \ [((25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9]) (\. (25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9])) {3} | IPv6: ((( (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {6} | :: ((0 | [1-9A-Fa-f] [0 -9A-Fa-f] {0,3}):) {5} | [0-9A-Fa-f] {0,4} :: ((0 | [1-9A-Fa-f] [0 -9A-Fa-f] {0,3}):) {4} | ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) 🙂 ? (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? :: ((0 | [1-9A-Fa-f] [0-9A- Fa-f] {0,3}):) {3} | (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {0, 2} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? :: ((0 | [1-9A-Fa-f] [0-9A -Fa-f] {0,3}):) {2} | (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {0 , 3} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3})) ?: 🙁 0 | [1-9A-Fa-f] [0-9A -Fa-f] {0,3}): | (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {0,4} ( 0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? ::) ((0 | [1-9A-Fa-f] [0-9A-Fa -f] {0,3}) 🙁 0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) | (25 [0-5] | 2 [0- 4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9]) (\.
— ~] + из регулярного выражения, если вы хотите убрать всю часть «General-address-literal».
Вот вывод:
Let-dig = АЛЬФА / ЦИФРА = ~ [0-9A-Za-z] Ldh-str = * (АЛЬФА / ЦИФРА / "-") Let-dig = ~ [0-9A-Za-z -] * [0-9A-Za-z] (регулярное выражение обновлено, чтобы обеспечить длину поддоменов не более 63 символов - RFC 1034, раздел 3.5) субдомен = Let-dig [Ldh-str] = ~ [0-9A-Za-z] ([0-9A-Za-z -] {0,61} [0-9A-Za-z])? Домен = поддомен * ("."субдомен) = ~ [0-9A-Za-z] ([0-9A-Za-z -] {0,61} [0-9A-Za-z])? (\. [0-9A-Za-z] ([0-9A-Za-z -] {0,61} [0-9A-Za-z])?) * Snum = 1 * 3D ЦИФРА = ~ [0-9] {1,3} (предложена замена на "Snum") ip4-octet = DIGIT /% x31-39 DIGIT / "1" 2DIGIT / "2"% x30-34 DIGIT / "25"% x30-35 = ~ 25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9] Литерал-адрес-IPv4 = Snum 3 ("." Snum) = ~ [0-9] {1,3} (\. [0-9] {1,3}) {3} (предлагается замена на "литерал-адрес-IPv4") ip4-адрес = ip4-октет 3 ("."ip4-октет) = ~ (25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9]) (\. (25 [ 0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9])) {3} (предлагается замена на "IPv6-hex") ip6-h26 = "0" / ((% x49-57 /% x65-70 /% x97-102) 0 * 3 (% x48-57 /% x65-70 /% x97-102)) = ~ 0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3} (не из RFC) ls32 = ip6-h26 ":" ip6-h26 / ip4-адрес = ~ (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) :( 0 | [1-9A-Fa-f] [0-9A-Fa-f] ] {0,3}) | (25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9]) (\.(25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9])) {3} (предлагается замена "IPv6-addr") ip6-адрес = 6 (ip6-h26 ":") ls32 / "::" 5 (ip6-h26 ":") ls32 / [ip6-h26] "::" 4 (ip6-h26 ":") ls32 / [* 1 (ip6-h26 ":") ip6-h26] "::" 3 (ip6-h26 ":") ls32 / [* 2 (ip6-h26 ":") ip6-h26] "::" 2 (ip6-h26 ":") ls32 / [* 3 (ip6-h26 ":") ip6-h26] "::" ip6-h26 ":" ls32 / [* 4 (ip6-h26 ":") ip6-h26] "::" ls32 / [* 5 (ip6-h26 ":") ip6-h26] "::" ip6-h26 / [* 6 (ip6-h26 ":") ip6-h26] "::" = ~ (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {6} | :: ((0 | [1-9A-Fa- f] [0-9A-Fa-f] {0,3}):) {5} | [0-9A-Fa-f] {0,4} :: ((0 | [1-9A-Fa- f] [0-9A-Fa-f] {0,3}):) {4} | ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3 }):)? (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? :: ((0 | [1-9A-Fa-f] [ 0-9A-Fa-f] {0,3}):) {3} | ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}): ) {0,2} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? :: ((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {2} | (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) :) {0,3} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3})) ?: :( 0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}): | (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {0 , 4} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? ::) ((0 | [1-9A-Fa-f] [0 -9A-Fa-f] {0,3}) :( 0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) | (25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9]) (\.Я не рекомендую дополнительно ограничивать локальную часть, например исключая строки в кавычках, поскольку мы не знаем, какие имена почтовых ящиков допускают некоторые хосты (например,
"a..b"@example.netили даже"a b" @ example.net).Я также не рекомендую явно проверять соответствие списку буквальных доменов верхнего уровня или даже налагать ограничения по длине (помните, как ".- ~ \ t] | (\\ [\ t - ~])) + ") @ ([0-9A-Za-z] ([0-9A-Za-z -] {0,61} [0- 9A-Za-z])? \.) * (Net | org | com | info | и т.д ...
)Обязательно обновляйте свое регулярное выражение, если вы решите пойти по пути явной проверки домена верхнего уровня.
Дополнительные сведения
Если в доменной части (после знака @) принимаются только имена хостов, регулярные выражения выше принимают только метки, содержащие не более 63 символов, как и должно быть.
Еще одно соображение, особенно при использовании регулярных выражений для проверки ввода, - это обратная связь с пользователем. Если пользователь вводит неправильный адрес, было бы неплохо дать немного больше отзывов, чем простой «синтаксически неправильный адрес». С "ванильными" регулярными выражениями это невозможно.
Эти два соображения можно решить, проанализировав адрес.Ограничение дополнительной длины для имен хостов в некоторых случаях также может быть устранено с помощью дополнительного регулярного выражения, которое проверяет его и сопоставляет адрес с обоими выражениями.
Ни одно из регулярных выражений в этом ответе не оптимизировано для производительности. Если производительность является проблемой, вы должны посмотреть, можно ли (и как) оптимизировать регулярное выражение по вашему выбору.
python - регулярное выражение для адреса электронной почты
Трудно сказать, о чем здесь спрашивают.Этот вопрос двусмысленный, расплывчатый, неполный, чрезмерно широкий или риторический, и на него нельзя разумно ответить в его нынешней форме. Чтобы прояснить этот вопрос и открыть его повторно, посетите Справочный центр.Закрыт 9 лет назад.
Вот странное регулярное выражение для писем.
У нас могут быть разные адреса электронной почты
строка1 @ somemail.com
Следующее регулярное выражение может найти любое из писем выше
email2 = "santa.Это кажется слишком сложным, правда ...
Я немного обобщил ....
x = re.search ('(\ w + [. | \ W]) * @ (\ w + [.]) * \ W +', email4) x.group () '[email protected] 'Вышеупомянутое регулярное выражение теперь может определять любой тип комбинации ...
Теперь, если вам нужен только адрес электронной почты, заканчивающийся на '.in' или '.com'
тогда вы можете добавить вариацию ...x = re.search ('(\ w + [. | \ W]) * @ (\ w + [.]) * (Com $ | in $)', электронная почта)Вы можете попробовать это в различных комбинациях ....
Если выражение никуда не подходит, скажите мне.Некоторые предположения, которые я использовал: адрес электронной почты (имя пользователя) не будет содержать специальных символов, только слова или числа.\ [\] \ r \\] | \\.) * \] (?: (?: \ r \ n)? [\ t]) *)) * \> (? 🙁
?: \ r \ n)? [\ t]) *)) *)?; \ s *)
Нет, я не шучу: http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
Сводка проверки электронной почты
— почти идеальное регулярное выражение электронной почты
Вот список основных текстов RFC об адресах электронной почты и стандарте SMTP:
Краткое изложение в значительной степени основано на RFC 2822.
Начало строки или начало строки в многострочном шаблоне
\ A
Начало строки
$
Конец строки или конец строки в многострочном шаблоне
\ Z
Конец строки
\ б
Граница слова
\ В
Не граница слова
\ <
Начало слова
\>
Конец слова
Классы символов
(25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9])) {3}) | (( (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {0,5} (0 | [1-9A-Fa-f] [0-9A -Fa-f] {0,3})) ?: :( 0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) | (((0 | [1 -9A-Fa-f] [0-9A-Fa-f] {0,3}):) {0,6} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? ::
IPv6-address-literal = "IPv6:" ip6-адрес
= ~ IPv6: ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {6} | :: ((0 | [1-9A -Fa-f] [0-9A-Fa-f] {0,3}):) {5} | [0-9A-Fa-f] {0,4} :: ((0 | [1-9A -Fa-f] [0-9A-Fa-f] {0,3}):) {4} | ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] { 0,3}):)? (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? :: ((0 | [1-9A-Fa- f] [0-9A-Fa-f] {0,3}):) {3} | (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3 }):) {0,2} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? :: ((0 | [1-9A-Fa -f] [0-9A-Fa-f] {0,3}):) {2} | ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0, 3}):) {0,3} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3})) ?: :( 0 | [1-9A-Fa -f] [0-9A-Fa-f] {0,3}): | (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}): ) {0,4} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? ::) ((0 | [1-9A-Fa-f] ] [0-9A-Fa-f] {0,3}) :( 0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) | (25 [0- 5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9]) (\.- ~] +
адрес-литерал = "[" (литерал-адрес-IPv4 / литерал-адрес-IPv6 / литерал-общий-адрес) "]"
= ~ \ [((25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9]) (\. (25 [0-5] | 2 [0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9])) {3} | IPv6 :( (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {6} | :: ((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {5} | [0-9A-Fa-f] {0,4} :: ((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {4} | ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) :)? (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? :: ((0 | [1-9A-Fa-f] [0- 9A-Fa-f] {0,3}):) {3} | ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) { 0,2} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? :: ((0 | [1-9A-Fa-f] [0 -9A-Fa-f] {0,3}):) {2} | ((((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) :) {0,3} (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3})) ?: :( 0 | [1-9A-Fa-f] [0 -9A-Fa-f] {0,3}): | (((0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}):) {0,4 } (0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}))? ::) ((0 | [1-9A-Fa-f] [0-9A -Fa-f] {0,3}) :( 0 | [1-9A-Fa-f] [0-9A-Fa-f] {0,3}) | (25 [0-5] | 2 [ 0-4] [0-9] | 1 [0-9] {2} | [1-9]? [0-9]) (\.
Однако они не предписывают тот факт, что полное имя хоста должно состоять не более чем из 253 символов (включая точки).Хотя это ограничение, строго говоря, по-прежнему является обычным, создать регулярное выражение, включающее это правило, невозможно. 
\ с | Управляющий символ |
\ с | Пустое пространство |
\ S | Не пробел |
\ д | цифра |
\ D | Не цифра |
\ w | Слово |
\ Вт | Не слово |
\ х | Шестнадцатеричная цифра |
\ O | Восьмеричная цифра |
POSIX
[: верх:] | Заглавные буквы |
[: нижний:] | Строчные буквы |
[: alpha:] | Все буквы |
[: alnum:] | Цифры и буквы |
[: цифра:] | цифр |
[: xdigit:] | Шестнадцатеричные цифры |
[: punct:] | Пунктуация |
[: пусто:] | Пробел и табуляция |
[: пробел:] | Пустые символы |
[: cntrl:] | Управляющие символы |
[: график:] | Печатные символы |
[: print:] | Печатные символы и пробелы |
[: word:] | Цифры, буквы и знак подчеркивания |
Утверждения
? = | Утверждение опережающего просмотра |
?! | Отрицательный прогноз |
? <= | Утверждение просмотра назад |
?! = Или? | Отрицательный взгляд назад |
?> | Единовременное подвыражение |
? () | Условие [если то] |
? () | | Условие [if then else] |
? # | Комментарий |
Квантификаторы
* | 0 или более | {3} | Ровно 3 |
+ | 1 или более | {3,} | 3 и более |
? | 0 или 1 | {3,5} | 3, 4 или 5 |
Добавить? к квантификатору, чтобы сделать его нелицеприятным.
Последовательности побега
\ | Побег следующего персонажа |
\ Q | Начало буквальной последовательности |
\ E | Конечная буквальная последовательность |
«Экранирование» — это способ буквально обрабатывать символы, которые имеют особое значение в регулярных выражениях, а не как специальные символы.
[
.
$
{
*
(
\
+
)
|
?
<
>
Экранирующий символ обычно \
.
Специальные символы
\ п | Новая линия |
\ r | Возврат каретки |
\ т | Вкладка |
\ в | Вертикальная табуляция |
\ ф | Подача формы |
\ ххх | Восьмеричный символ xxx |
\ xhh | Шестнадцатеричный символ hh |
Группы и диапазоны
. | |
$ ` | Строка до совпадения |
$ | После сопоставленной строки |
$ + | Последняя совпавшая строка |
$ и | Вся согласованная строка |
(?: abc) (xyz) $ /В некоторых реализациях регулярных выражений используется \ вместо $.
Четыре регулярных выражения для проверки адресов электронной почты
Как узнать, ввел ли пользователь действительный адрес электронной почты? Вы проверяете наличие знака at или это сложнее? Для многих разработчиков ответ — регулярное выражение, небольшой фрагмент кода, который может описывать текстовые шаблоны с помощью подстановочных знаков и других специальных символов. Если вы новичок в этой теме, у нас есть отличный учебник по регулярным выражениям.
Вот четыре регулярных выражения (часто называемых регулярными выражениями ), каждое из которых проверяет формат адреса электронной почты.Они имеют возрастающую степень сложности. Чем сложнее, тем точнее каждый из них сопоставляет только адреса электронной почты.
1. Грязь-простой подход
Вот регулярное выражение, которое требует только очень простого [email protected] :
Плюс: грязно просто.
Оборотная сторона: даже недействительные адреса электронной почты, такие как [email protected] или даже [email protected], пройдут.
2. Чуть более строгий (но все же простой) подход
Регулярные выражения.Info предоставляет базовое регулярное выражение проверки электронной почты, которое пытается быть немного умнее:
[A-Z0-9 ._% + -] + @ [A-Z0-9 .-] + \. [AZ] {2, 4}
Плюс: разрешены только символы, понятные для адреса электронной почты, расширение домена ограничивается двумя-четырьмя символами.
Оборотная сторона: он по-прежнему допускает множество недействительных адресов электронной почты и пропускает некоторые более длинные доменные расширения (например, .museum).
3. Укажите подход всех расширений домена.
Пользователь Reddit указывает на свое регулярное выражение, которое разрешает только существующие расширения домена:
([a-z0-9] [- a-z0-9_ \ + \.] * [a-z0-9]) @ ([a-z0-9] [- a-z0-9 \.] * [a-z0-9] \. (arpa | root | aero | biz | cat | com | coop | edu | gov | info | int | jobs | mil | mobi | museum | name | net | org | pro | tel | travel | ac | ad | ae | af | ag | ai | al | am | an | ao | aq | ar | as | at | au | aw | ax | az | ba | bb | bd | be | bf | bg | bh | bi | bj | bm | bn | bo | br | bs | bt | bv | bw | by | bz | ca | cc | cd | cf | cg | ch | ci | ck | cl | cm | cn | co | cr | cu | cv | cx | cy | cz | de | dj | dk | dm | do | dz | ec | ee | eg | er | es | et | eu | fi | fj | fk | fm | fo | fr | ga | gb | gd | ge | gf | gg | gh | gi | gl | gm | gn | gp | gq | gr | gs | gt | gu | gw | gy | hk | hm | hn | hr | ht | hu | id | ie | il | im | in | io | iq | ir | is | it | je | jm | jo | jp | ke | kg | kh | ki | km | kn | kr | kw | ky | kz | la | lb | lc | li | lk | lr | ls | lt | lu | lv | ly | ma | mc | md | mg | mh | mk | ml | mm | mn | mo | mp | mq | mr | ms | mt | mu | mv | mw | mx | my | mz | na | nc | ne | nf | ng | ni | nl | no | np | nr | nu | nz | om | pa | pe | pf | pg | ph | pk | pl | pm | pn | pr | ps | pt | pw | py | qa | re | ro | ru | rw | sa | sb | sc | sd | se | sg | sh | si | sj | sk | sl | sm | sn | so | sr | st | su | sv | sy | sz | tc | td | tf | tg | th | tj | tk | tl | tm | tn | to | tp | tr | tt | tv | tw | tz | ua | ug | uk | um | us | uy | uz | va | vc | ve | vg | vi | vn | vu | wf | ws | ye | yt | yu | za | zm | zw) | ([0-9] {1,3} \.{3} [0-9] {1,3}))
Плюс: это не позволяет [email protected]!
Даунсайд: с этим может быть тяжело содержать. Вам придется обновлять каждый раз, когда объявляют о новых расширениях домена. Фактически, вам уже нужно будет добавить расширение .me.
4. Сложный подход
Модуль Perl имеет длинное регулярное выражение, основанное на стандартном описании адреса электронной почты. Он настолько длинный (почти 6500 символов!), Что я не буду включать его здесь.
Плюс: Готово.
Оборотная сторона: это очень сложно.
Встреча по центру
Вам нужно будет решить, если вы еще этого не сделали, какое регулярное выражение использовать. Скорее всего, вы выберете где-нибудь в середине приведенных нами примеров. Regular-Expressions.Info содержит хороший обзор компромиссов различных подходов.
Вы уже решили, как проверять адреса электронной почты? Как ты это делаешь?
[через Reddit]
См. Также:
Как проверить адреса электронной почты в VBA для MS Access или Excel
Проверка адреса электронной почты с помощью регулярных выражений с использованием VBA
Если ваше приложение в MS Access или Excel должно иметь дело с адресами электронной почты, вам может потребоваться способ их проверки.Эти адреса электронной почты могут быть введены либо пользователями этих приложений, либо путем импорта из других источников.
Лучший способ проверить адреса электронной почты — использовать регулярные выражения, поскольку они соответствуют
шаблоны для допустимого формата адреса электронной почты.
Чтобы использовать регулярные выражения в VBA, вам сначала нужно добавить ссылку в редактор кода VBA.
Откройте файл Access или Excel, затем откройте редактор VBA. В зависимости от вашей версии Microsoft Office, есть разные способы открыть редактор кода VBA.
Когда редактор кода VBA открыт, в строке меню вверху нажмите Инструменты -> Ссылки …
Затем в списке доступных ссылок найдите Microsoft VBScript Regular Expressions 5.