Метод isEmail

Метод isEmail в библиотеке validator.js предназначен для строгой или гибко настраиваемой валидации строк на соответствие формату электронного адреса. Проверка ориентирована на распространённые стандарты электронной почты (включая RFC-подобные правила), но при этом допускает настройку поведения под конкретные требования приложения.

Функция работает со строковым значением и возвращает булев результат: true, если строка считается валидным email-адресом, и false в противном случае.

Сигнатура метода

isEmail(str [, options])

Параметры

str Строка, которая проходит проверку. Любые нестроковые значения предварительно приводятся к строковому виду, однако корректность такого подхода зависит от контекста использования.

options (необязательный параметр) Объект конфигурации, позволяющий изменять поведение проверки.

Базовый принцип проверки

Проверка email в Validator.js основывается на разбиении адреса на две ключевые части:

  • локальная часть (до символа @)
  • доменная часть (после символа @)

Пример:

user.name@example.com
  • user.name — локальная часть
  • example.com — домен

Метод анализирует допустимость символов, структуру домена, наличие запрещённых последовательностей и соответствие формату.

Базовое использование

import validator from 'validator';

validator.isEmail('test@example.com'); // true
validator.isEmail('invalid-email');    // false

При отсутствии опций применяется стандартная строгая проверка, ориентированная на универсальные email-форматы.

Поддерживаемые символы и структура

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

По умолчанию допускаются:

  • латинские буквы
  • цифры
  • точка .
  • подчёркивание _
  • дефис -

Примеры допустимых значений:

john.doe@example.com
user_name@example.com
user-name@example.com

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

Доменная часть проверяется на:

  • наличие хотя бы одной точки
  • корректные доменные метки
  • отсутствие запрещённых символов
  • допустимость TLD (верхнего уровня домена)

Пример:

user@sub.domain.com

Опции метода isEmail

Метод предоставляет набор конфигурационных параметров, позволяющих адаптировать проверку под бизнес-логику.

allow_display_name

Разрешает использование отображаемого имени перед email.

validator.isEmail('John Doe <john@example.com>', {
  allow_display_name: true
});

Допустимые форматы:

John Doe <john@example.com>
"John Doe" <john@example.com>

require_display_name

Требует обязательного наличия отображаемого имени.

validator.isEmail('john@example.com', {
  require_display_name: true
}); // false

allow_utf8_local_part

Разрешает использование UTF-8 символов в локальной части.

validator.isEmail('пользователь@example.com', {
  allow_utf8_local_part: true
});

Это полезно для международных систем, где поддерживаются нелатинские алфавиты.

require_tld

Требует обязательного наличия домена верхнего уровня.

validator.isEmail('user@localhost', {
  require_tld: true
}); // false

Используется для исключения локальных или тестовых адресов.

allow_ip_domain

Разрешает использование IP-адреса вместо доменного имени.

validator.isEmail('user@[192.168.0.1]', {
  allow_ip_domain: true
});

Допустимые форматы:

user@[127.0.0.1]
user@[2001:db8::1]

domain_specific_validation

Включает дополнительные проверки, специфичные для отдельных доменов.

validator.isEmail('user@gmail.com', {
  domain_specific_validation: true
});

Такая проверка может учитывать особенности конкретных почтовых сервисов.

blacklisted_chars

Позволяет запретить определённые символы в email.

validator.isEmail('user!@example.com', {
  blacklisted_chars: '!'
});

Поведение при некорректных данных

Метод возвращает false в следующих случаях:

  • отсутствует символ @
  • пустая локальная или доменная часть
  • присутствуют недопустимые символы
  • нарушена структура домена
  • используется запрещённый формат IP или TLD

Примеры проверки различных форматов

Корректные адреса

validator.isEmail('simple@example.com');            // true
validator.isEmail('user.name+tag@example.co.uk');   // true
validator.isEmail('user_name@example.io');          // true

Некорректные адреса

validator.isEmail('plainaddress');         // false
validator.isEmail('@missinguser.com');     // false
validator.isEmail('user@.com');            // false
validator.isEmail('user@com');             // false

Особенности работы с международными доменами

Поддержка интернационализированных доменов (IDN) требует дополнительной обработки. Внутри Validator.js такие домены могут конвертироваться в punycode-представление.

Пример:

münchen.de → xn--mnchen-3ya.de

При включённых соответствующих опциях проверка учитывает преобразование и допустимость результата.

Влияние регистра символов

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

Метод isEmail не различает регистр при проверке валидности структуры.

Практические сценарии использования

Валидация формы регистрации

if (!validator.isEmail(email)) {
  throw new Error('Некорректный email');
}

Проверка корпоративных доменов

validator.isEmail(email, {
  domain_specific_validation: true
});

Ограничение тестовых адресов

validator.isEmail(email, {
  require_tld: true,
  allow_ip_domain: false
});

Ограничения метода

Несмотря на широкую применимость, метод не выполняет:

  • проверку существования почтового ящика
  • отправку тестового письма
  • DNS MX lookup
  • проверку доставки сообщений

Валидация ограничивается синтаксическим анализом строки.

Поведение при небуквенных типах входа

При передаче чисел, объектов или null происходит приведение к строке, что может привести к неожиданным результатам:

validator.isEmail(null); // false
validator.isEmail(123);  // false

Совместимость и производительность

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

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

Типичные ошибки при использовании

  • использование метода без предварительной нормализации строки
  • попытка заменить полноценную почтовую проверку (включая существование ящика)
  • игнорирование опций для специфических доменных требований
  • неправильная обработка Unicode-адресов без включения соответствующих флагов
Оглавление