Регулярные выражения для проверки адресов электронной почты: шаблоны для проверки адресов электронной почты

Вы создали форму регистрации, и кто-то вводит «john@» в поле электронной почты. Если проверка подлинности не включена, это значение сразу попадает в вашу базу данных, как будто ничего не произошло. Затем ваша следующая кампания отправляет письмо на этот адрес, ваш поставщик услуг рассылки регистрирует отказ в доставке, и ваша репутация отправителя немного страдает из-за ошибки, которую можно было полностью избежать.

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

Что такое регулярное выражение для email-рассылок?

Регулярное выражение (regex) — это последовательность символов, определяющая шаблон поиска. Регулярное выражение для электронной почты — это шаблон, специально написанный для сопоставления строк, соответствующих структуре допустимого адреса электронной почты.

Когда пользователь отправляет форму, регулярное выражение применяется к введенным данным. Если строка соответствует шаблону (правильные символы, символ @ в нужном месте, допустимая структура домена), проверка проходит успешно. Если же совпадения нет, форма может отклонить ввод и предложить пользователю исправить его.

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

Почему важны регулярные выражения для электронных писем

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

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

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

Тем не менее, регулярные выражения эффективны именно потому, что они легковесны; они проверяют только формат. Для всего остального требуются дополнительные уровни проверки.

Как работают регулярные выражения для электронных писем

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

Для адреса электронной почты необходимо учитывать три структурные части:

1. Местная часть: всё, что находится перед символом @ (например, john.doe)
2. Символ @: ровно один, в правильном положении
3. Домен: Доменное имя и домен верхнего уровня после символа @ (например, example.com)

Простейшее регулярное выражение для электронных писем проверяет наличие всех трех частей и допустимость символов в каждой секции. Например, шаблон ^[^\s@]+@[^\s@]+\.[^\s@]+$ читается так: начало строки, один или несколько символов, не являющихся пробелом или символом @, затем символ @, затем еще символы, не являющиеся пробелами/символами @, затем точка, затем еще символы, не являющиеся пробелами/символами @, конец строки.

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

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

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

Правила для локальных частей (перед символом @):

• Допускаются буквы (a–z, A–Z) и цифры (0–9).
• К специальным символам могут относиться точки (.), подчеркивания (_), дефисы (-) и знаки плюс (+).
• Локальная часть не может начинаться или заканчиваться точкой.
• Последовательные точки (..) не допускаются.
• Технически длина ограничена 64 символами в соответствии с соответствующими спецификациями RFC.

Правила домена (после символа @):

• Домен должен содержать как минимум одну точку, отделяющую доменное имя от домена верхнего уровня (например, example.com).
• Надписи между точками могут содержать буквы, цифры и дефисы, но не могут начинаться или заканчиваться дефисом.
• Домен верхнего уровня (TLD) должен состоять как минимум из двух символов. Большинство современных шаблонов допускают TLD различной длины для охвата новых расширений, таких как .io, .museum или .photography.

Общие ограничения по всему адресу:

• В адресе не должно быть пробелов.
• Символ @ должен встречаться ровно один раз.
• Согласно RFC 5321, общая длина адреса не должна превышать 254 символа.

Типы шаблонов регулярных выражений для электронных писем

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

Простые шаблоны охватывают основные элементы: локальную часть, символ @, домен и домен верхнего уровня (TLD). Их быстро писать, легко читать, и они хорошо подходят для большинства стандартных случаев использования, таких как формы регистрации и поля контактов. Компромисс заключается в том, что они могут принимать некоторые строки, которые технически не соответствуют правилам обработки особых случаев, а также могут случайно отклонять необычные, но допустимые адреса.

В JavaScript часто используется простой шаблон, который выглядит следующим образом:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

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

Более детальный шаблон, используемый во многих производственных системах:

/^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$/

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

Практический компромисс

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

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

Регулярные выражения работают лучше всего, когда рассматриваются как часть более широкого процесса проверки. Слишком строгий шаблон может заблокировать корректные данные, а слишком мягкий — пропустить некорректные. Цель — найти баланс, при котором проверки формата будут надежными, но не создадут проблем.

• Следите за тем, чтобы ваш узор был читаемым: Регулярное выражение, которое никто в вашей команде не сможет интерпретировать без руководства, представляет собой риск для поддержки кода. В большинстве случаев четкий и достаточно подробный шаблон более практичен, чем тот, который пытается соответствовать каждому особому случаю, определенному в стандартах RFC.

• Перед развертыванием проведите тестирование на широком диапазоне входных данных: Учитывайте крайние случаи, например, адреса с символом + в локальной части ([электронная почта защищена]), субдомены ([электронная почта защищена]), и более новые TLD ([электронная почта защищена]Шаблон, который не срабатывает при корректном вводе данных, создает неудобства для реальных пользователей.
• Объедините регулярные выражения с дополнительной проверкой: Регулярные выражения подтверждают формат; они не могут подтвердить существование адреса. Для процессов регистрации и импорта списков используйте проверку формата в сочетании с подтверждающим электронным письмом или подтверждением в режиме реального времени. подтверждение адреса электронной почты Проверка. Это позволяет обнаружить одноразовые адреса, опечатки в домене и адреса, которые отформатированы правильно, но не существуют.
• Отдайте предпочтение пользовательскому опыту: Если ваше регулярное выражение отклоняет допустимый адрес, например, адрес со знаком плюс или адрес более нового домена верхнего уровня, вы теряете реального абонента, даже не подозревая об этом. Безопаснее разрешить немного более широкий ввод на этапе форматирования и полагаться на последующие проверки для отфильтровывания неиспользуемых адресов.

Распространенные ошибки и ограничения регулярных выражений для адресов электронной почты

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

• Регулярные выражения проверяют формат, а не существование: Строка, подобная [электронная почта защищена] Большинство шаблонов регулярных выражений для электронных писем проходят проверку, но это не означает, что адрес реален, активен или доступен для доставки. Регулярные выражения не учитывают DNS, почтовые серверы или фактическое существование почтового ящика. Проверка формата и проверка доступности — это две разные вещи.
• Ложные отрицательные результаты, отклонение действительных адресов: Некоторые легитимные адреса не соответствуют слишком строгим правилам. Адреса с символом + в локальной части ([электронная почта защищена]) являются распространенными для целей фильтрации и полностью допустимы. Более новые домены верхнего уровня, такие как .museum, .io или .agency, также могут быть отклонены, если ваш шаблон устанавливает ограничение на два символа в домене верхнего уровня. Каждое ложное отклонение — это реальный человек, которому не удалось зарегистрироваться.
• Ложные срабатывания, принимаются недопустимые строки: Простые шаблоны могут передавать строки, которые выглядят правильно, но на самом деле таковыми не являются. Например, user@example проходит множество базовых проверок, но не имеет допустимого домена верхнего уровня (TLD). Шаблон, который не устанавливает минимальную длину TLD, примет его и сохранит недоставленный адрес.

• Чрезмерно сложные схемы дают сбой: Шаблоны, пытающиеся реализовать полную спецификацию электронной почты RFC 5322, могут содержать сотни символов и при этом давать сбои в крайних случаях. Их сложно тестировать, сложно отлаживать, и часто при попытке решить старые проблемы возникают новые. Сама спецификация электронной почты достаточно сложна, чтобы ни одно регулярное выражение не охватывало её идеально.
• Регулярные выражения — это первый фильтр, а не полное решение: Она быстро и недорого выявляет ошибки форматирования. Для всего, что выходит за рамки форматирования, включая действительность домена, записи MX, существование почтового ящика и обнаружение одноразовых адресов, необходим уровень проверки. Проверки, подобные этой. Поиск записей MX Полная проверка адресов электронной почты выходит за рамки регулярных выражений, подтверждая, может ли адрес действительно получать сообщения, а не просто проверяя его внешний вид.

Выводы

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

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

Загрузите свой список в DeBounce И это выходит за рамки проверки формата. DeBounce проверяет синтаксис на соответствие стандартам RFC, проверяет записи DNS и MX, проверяет существование почтового ящика и помечает одноразовые и рискованные типы адресов, выявляя то, что не могут обнаружить регулярные выражения. Начните со 100 бесплатных проверок, чтобы точно увидеть, что находится в вашем списке перед следующей отправкой.