Какая стандартная проверка на валидацию email?

Стандартная проверка валидации email-адреса

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

Основные критерии стандартной валидации

Стандартная проверка обычно включает следующие аспекты:

Структура email-адреса (RFC 5322):

• Локальная часть (local-part) до символа @
• Символ @ (обязательно один)
• Доменная часть (domain) после @

Конкретные проверки:

• Наличие символа @: Адрес должен содержать ровно один символ @.
• Непробельные символы: В адресе не должно быть пробелов.
• Локальная часть: Не должна быть пустой. Может содержать буквы, цифры и специальные символы . ! # $ % & ' * + - / = ? ^ _ { | } ~`.
• Доменная часть: Должна содержать как минимум одну точку ., разделяющую доменные уровни (например, example.com). Доменная часть не должна начинаться или заканчиваться точкой или дефисом.
• Длина: Общая длина email-адреса не должна превышать 254 символа (ограничение по RFC). Длина локальной части — не более 64 символов.
• Корректность домена: Доменная часть должна соответствовать формату доменного имени (DNS).

Пример регулярного выражения для базовой проверки

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

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

Разбор выражения:

• ^[a-zA-Z0-9._%+-]+ — локальная часть (один и более символов из указанного набора).
• @ — обязательный символ.
• [a-zA-Z0-9.-]+ — домен второго уровня (например, gmail, yahoo).
• \.[a-zA-Z]{2,} — точка и домен верхнего уровня (.com, .ru, .org) длиной не менее 2 символов.

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

Практический подход к тестированию валидации email

Как QA-инженер, я бы проверял не только "правильные" адреса, но и граничные случаи и некорректные данные:

Позитивные тест-кейсы (должны проходить валидацию):

• simple@example.com
• very.common@example.com
• user.name+tag@example.org (плюс в локальной части)
• user_name@example.co.uk (субдомены)
• 1234567890@example.com (только цифры в локальной части)
• email@example-one.com (дефис в домене)

Негативные тест-кейсы (должны НЕ проходить валидацию):

• plainaddress (нет символа @)
• @example.com (пустая локальная часть)
• user name@example.com (пробел в адресе)
• user@example (нет домена верхнего уровня)
• user@.com (домен начинается с точки)
• user@example..com (две точки подряд в домене)
• user@-example.com (домен начинается с дефиса)
• Адрес длиннее 254 символов
• Локальная часть длиннее 64 символов

Рекомендации по реализации

1. Не полагайтесь только на фронтенд: Валидация должна дублироваться на бэкенде, так как фронтенд-проверку можно обойти.
2. Используйте специализированные библиотеки: Для большинства языков программирования существуют хорошо протестированные библиотеки (например, для Python — email-validator, для Java — Apache Commons Validator).
3. Подтверждение через отправку кода: Самый надежный способ убедиться, что email корректен и принадлежит пользователю — отправить на него письмо с подтверждающей ссылкой или кодом.
4. Учитывайте юзабилити: Сообщения об ошибках должны быть понятными пользователю (не "Regex mismatch", а "Введите корректный email-адрес").

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