Проверка синтаксиса email: regex и практики

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

Понимание структуры email адреса

Каждый email адрес состоит из двух основных частей, разделённых символом "@": локальной части и доменной части. Полная структура соответствует шаблону local-part@domain. Хотя это кажется простым, правила, управляющие каждой частью — определённые в основном RFC 5321 и RFC 5322 — допускают значительные вариации, которые многие базовые регулярные выражения для валидации email не обрабатывают корректно.

Локальная часть

Локальная часть появляется перед символом "@" и идентифицирует конкретный почтовый ящик на почтовом сервере. Допустимые символы в локальной части включают:

Прописные и строчные буквы (A-Z, a-z)
Цифры (0-9)
Специальные символы: ! # $ % & ' * + - / = ? ^ _ ` { | } ~
Точки (.) когда они не находятся в начале или конце, и не идут подряд
Строки в кавычках, допускающие почти любой символ, включая пробелы и специальные символы

Эта гибкость означает, что адреса типа user+tag@domain.com, "john doe"@example.com и admin!special@company.org технически являются действительными согласно спецификации. Чрезмерно ограничительный валидатор email может неправильно отклонить эти легитимные адреса.

Доменная часть

Доменная часть следует за символом "@" и указывает, куда должен быть доставлен email. Допустимые форматы домена включают:

Стандартные доменные имена (example.com, mail.company.org)
Интернационализированные доменные имена с не-ASCII символами
IP адреса в квадратных скобках ([192.168.1.1] или [IPv6:2001:db8::1])

Доменные имена должны следовать соглашениям об именовании DNS: метки, разделённые точками, каждая метка начинается и заканчивается буквенно-цифровым символом, содержит только буквенно-цифровые символы и дефисы между ними.

Сложность регулярных выражений для валидации email

Создание регулярного выражения, которое точно проверяет email адреса, следуя спецификациям RFC, оказывается удивительно сложным. Разрыв между тем, что разработчики обычно реализуют, и тем, что стандарты фактически допускают, создаёт постоянные проблемы в системах верификации email по всему миру.

Почему простые регулярные выражения не работают

Многие руководства и примеры кода предоставляют чрезмерно упрощённые регулярные выражения для валидации email, такие как:

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

Хотя этот шаблон ловит очевидно недействительные адреса, он неправильно отклоняет действительные адреса, содержащие:

Локальные части в кавычках с пробелами
Специальные символы типа ! или # в локальной части
Домены верхнего уровня из одного символа (да, они существуют)
Доменные части в виде IP адресов

И наоборот, этот шаблон может принять недействительные адреса с:

Последовательными точками в локальной части
Точками в начале или конце локальной части
Метками домена, начинающимися или заканчивающимися дефисами

Регулярное выражение RFC 5322

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

(?:[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])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-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])+)\])

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

Практичные регулярные выражения для валидации email

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

Улучшенный шаблон с большими ограничениями

Для приложений, требующих более строгой валидации, рассмотрите:

const strictEmailRegex = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;

Этот шаблон добавляет:

Явный белый список символов для локальной части
Ограничения длины меток домена (максимум 63 символа)
Предотвращение последовательных дефисов на границах домена

Реализации для конкретных языков

Разные языки программирования обрабатывают регулярные выражения для валидации email по-разному. Вот оптимизированные шаблоны для распространённых языков:

JavaScript:

function validateEmailSyntax(email) {
  const pattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return pattern.test(email) && email.length <= 254;
}

Python:

import re

def validate_email_syntax(email):
    pattern = r'^[^\s@]+@[^\s@]+\.[^\s@]+$'
    if len(email) > 254:
        return False
    return bool(re.match(pattern, email))

PHP:

function validateEmailSyntax($email) {
    return filter_var($email, FILTER_VALIDATE_EMAIL) !== false;
}

Обратите внимание, что встроенная функция PHP filter_var обеспечивает разумную валидацию синтаксиса email без необходимости пользовательских регулярных выражений.

Помимо базового синтаксиса: ограничения длины

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

Ограничение общей длины

RFC 5321 указывает, что email адреса не могут превышать 254 символа в общей сложности. Это ограничение применяется к полному адресу, включая локальную часть, символ @ и доменную часть вместе.

Длина локальной части

Локальная часть не может превышать 64 символа. Адреса с более длинными локальными частями должны быть отклонены, даже если они в остальном соответствуют вашему регулярному выражению.

Длина домена

Отдельные метки домена не могут превышать 63 символа, а общая доменная часть не может превышать 253 символа. Эти ограничения происходят из спецификаций DNS, а не из стандартов email.

Реализация проверок длины

Всегда комбинируйте валидацию регулярными выражениями с явными проверками длины:

function validateEmail(email) {
  // Ограничения длины
  if (email.length > 254) return false;

  const [localPart, domain] = email.split('@');
  if (!localPart || !domain) return false;
  if (localPart.length > 64) return false;
  if (domain.length > 253) return false;

  // Проверка отдельных меток домена
  const labels = domain.split('.');
  for (const label of labels) {
    if (label.length > 63) return false;
  }

  // Валидация регулярным выражением
  const pattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return pattern.test(email);
}

Распространённые ошибки валидации синтаксиса email

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

Требование длины TLD

Некоторые шаблоны требуют, чтобы домены верхнего уровня были длиной не менее 2 или 3 символов. Хотя распространённые TLD типа .com, .org и .net имеют 3+ символа, существуют действительные однобуквенные TLD, а новые gTLD сильно различаются по длине.

Блокировка знаков плюс

Знак плюса (+) допустим в локальных частях email и обычно используется для тегирования email (например, user+newsletter@gmail.com). Блокировка знаков плюс мешает пользователям организовывать свою почту и разочаровывает опытных пользователей.

Требование конкретных символов

Некоторые валидаторы требуют определённых символов (например, хотя бы одной буквы) в локальной части. Адреса типа 123@domain.com совершенно действительны и иногда используются.

Предположения о чувствительности к регистру

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

Отклонение международных символов

Современные стандарты email поддерживают интернационализированные email адреса (EAI) с не-ASCII символами как в локальной, так и в доменной частях. Хотя полная поддержка EAI может быть не необходима для всех приложений, имейте в виду, что шаблоны, ограничивающиеся ASCII, могут отклонять действительные международные адреса.

Валидация синтаксиса email в разных контекстах

Соответствующий уровень валидации формата email зависит от вашего конкретного случая использования и толерантности к рискам.

Формы регистрации пользователей

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

Валидация входных данных API

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

Списки для email маркетинга

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

Приложения с высокой безопасностью

Для приложений, требующих высокой уверенности в действительности email, валидация синтаксиса служит только первым шагом. Комбинируйте её с проверкой MX записей, SMTP верификацией и профессиональными сервисами верификации email, такими как BillionVerify, для комплексной валидации email.

Роль валидации синтаксиса в верификации email

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

Иерархия верификации

Комплексный процесс верификации email обычно следует этому порядку:

Валидация синтаксиса - Проверка формата (фокус этой статьи)
Валидация домена - Подтверждение существования домена
Проверка MX записей - Проверка настройки почтовых серверов
SMTP верификация - Подтверждение существования конкретного почтового ящика
Оценка доставляемости - Проверка на catch-all домены, ролевые адреса, одноразовые email

Узнайте больше о полном процессе верификации в нашем полном руководстве по email верификации.

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

Комбинирование с профессиональными сервисами

Хотя вы можете реализовать валидацию синтаксиса внутри компании, профессиональные сервисы верификации email, такие как BillionVerify, обрабатывают полный конвейер верификации. API BillionVerify выполняет валидацию синтаксиса как часть своей комплексной верификации email, комбинируя её с проверкой домена, SMTP верификацией, обнаружением catch-all и идентификацией одноразовых email в одном вызове API.

async function verifyEmail(email) {
  // Быстрая клиентская проверка синтаксиса
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    return { valid: false, reason: 'Invalid syntax' };
  }

  // Полная верификация через API BillionVerify
  const response = await fetch('https://api.billionverify.com/v1/verify', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer YOUR_API_KEY',
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ email })
  });

  return await response.json();
}

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

Соображения производительности

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

Различия движков регулярных выражений

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

Катастрофический откат назад

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

Скомпилируйте один раз, используйте много раз

Если проверяете много email, скомпилируйте регулярное выражение один раз и используйте его повторно:

// Плохо: Компилирует регулярное выражение при каждом вызове
function validateMany(emails) {
  return emails.filter(email => /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email));
}

// Хорошо: Компилировать один раз
const emailPattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
function validateMany(emails) {
  return emails.filter(email => emailPattern.test(email));
}

Стратегии массовой валидации

Для массовой верификации email больших списков обрабатывайте адреса пакетами с валидацией синтаксиса в качестве предварительного фильтра:

async function bulkVerify(emails) {
  const syntaxPattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

  // Предварительная фильтрация валидацией синтаксиса
  const syntaxValid = emails.filter(email =>
    syntaxPattern.test(email) && email.length <= 254
  );

  // Отправить только синтаксически действительные email в API
  const results = await billionVerifyBulkCheck(syntaxValid);

  // Объединить результаты с ошибками синтаксиса
  return emails.map(email => {
    if (!syntaxPattern.test(email) || email.length > 254) {
      return { email, valid: false, reason: 'Invalid syntax' };
    }
    return results.find(r => r.email === email);
  });
}

Тестирование вашего валидатора email

Тщательное тестирование гарантирует, что ваша валидация синтаксиса email правильно обрабатывает граничные случаи.

Тестовые случаи для действительных адресов

Ваш валидатор должен принимать эти действительные адреса:

simple@example.com
very.common@example.com
disposable.style.email.with+symbol@example.com
other.email-with-hyphen@example.com
fully-qualified-domain@example.com
user.name+tag+sorting@example.com
x@example.com
example-indeed@strange-example.com
example@s.example
user-@example.org
postmaster@[123.123.123.123]

Тестовые случаи для недействительных адресов

Ваш валидатор должен отклонять эти недействительные адреса:

Abc.example.com (нет символа @)
A@b@c@example.com (несколько символов @)
a"b(c)d,e:f;g<h>i[j\k]l@example.com (специальные символы не в кавычках)
just"not"right@example.com (строки в кавычках должны быть одни)
this is"not\allowed@example.com (пробелы и кавычки)
this\ still\"not\\allowed@example.com (обратные слеши)
.user@example.com (начальная точка)
user.@example.com (конечная точка)
user..name@example.com (последовательные точки)

Автоматизированное тестирование

Реализуйте автоматизированные тесты для вашего валидатора email:

const validEmails = [
  'test@example.com',
  'user+tag@domain.org',
  'first.last@subdomain.example.co.uk',
  // Добавьте больше тестовых случаев
];

const invalidEmails = [
  'not-an-email',
  'missing@tld',
  '@no-local-part.com',
  // Добавьте больше тестовых случаев
];

describe('Email Syntax Validation', () => {
  validEmails.forEach(email => {
    it(`should accept ${email}`, () => {
      expect(validateEmail(email)).toBe(true);
    });
  });

  invalidEmails.forEach(email => {
    it(`should reject ${email}`, () => {
      expect(validateEmail(email)).toBe(false);
    });
  });
});

Пользовательский опыт валидации в реальном времени

Реализация валидации синтаксиса email в пользовательских интерфейсах требует балансирования немедленной обратной связи с хорошим пользовательским опытом.

Время валидации

Не проверяйте при каждом нажатии клавиши — это создаёт раздражающий опыт по мере того, как пользователь печатает. Вместо этого:

// Валидация при потере фокуса (когда поле теряет фокус)
emailInput.addEventListener('blur', () => {
  validateAndShowFeedback(emailInput.value);
});

// Или валидация после того, как пользователь прекращает печатать (с задержкой)
let timeout;
emailInput.addEventListener('input', () => {
  clearTimeout(timeout);
  timeout = setTimeout(() => {
    validateAndShowFeedback(emailInput.value);
  }, 500);
});

Ясность сообщений об ошибках

Когда валидация синтаксиса проваливается, предоставьте чёткое руководство:

function getValidationMessage(email) {
  if (!email.includes('@')) {
    return 'Please include an @ symbol in your email address';
  }
  const [local, domain] = email.split('@');
  if (!domain) {
    return 'Please enter a domain after the @ symbol';
  }
  if (!domain.includes('.')) {
    return 'Please enter a valid domain (e.g., example.com)';
  }
  if (email.length > 254) {
    return 'Email address is too long';
  }
  return 'Please enter a valid email address';
}

Визуальная обратная связь

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

Поддержка интернационализированных email адресов

Современные приложения всё чаще нуждаются в поддержке интернационализированных email адресов, содержащих не-ASCII символы.

Стандарты EAI

Email Address Internationalization (EAI) допускает:

Символы Unicode в локальной части
Интернационализированные доменные имена (IDN) в доменной части

Адрес типа 用户@例子.中国 является действительным согласно стандартам EAI.

Практические соображения

Хотя поддержка EAI расширяется, учитывайте эти факторы:

Не все почтовые серверы поддерживают EAI
Многие сервисы верификации email могут не полностью поддерживать международные адреса
Методы ввода пользователей для не-латинских символов различаются
Хранение и сравнение требуют нормализации Unicode

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

Заключение

Валидация синтаксиса email служит важной первой линией защиты в любой системе верификации email. Хотя задача кажется простой — проверить, соответствует ли email правильному формату — нюансы стандартов email создают удивительную сложность.

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

Помните, что одна валидация синтаксиса не может подтвердить, что email адрес на самом деле существует или может принимать сообщения. Она просто подтверждает, что адрес соответствует ожидаемому формату. Для настоящей верификации и валидации email вам нужен полный конвейер: проверка синтаксиса, верификация домена, валидация MX записей, SMTP верификация и специализированные проверки на catch-all домены, одноразовые email и ролевые адреса. Узнайте больше о полном процессе верификации в нашем полном руководстве по email верификации.

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

Создавайте свой валидатор email с учётом как точности, так и пользовательского опыта, тщательно тестируйте с разнообразными реальными адресами и интегрируйте профессиональные API верификации email, такие как BillionVerify, для полной уверенности в качестве ваших email данных. Для дополнительной уверенности в качестве ваших списков используйте очистку списков для удаления недействительных и вредоносных адресов перед развертыванием кампаний.