Параметры валидации email

Валидация email в Validator.js реализуется через функцию isEmail(value, options), которая позволяет контролировать набор правил проверки строкового значения на соответствие формату электронной почты. Гибкость достигается за счёт объекта параметров, расширяющего стандартную проверку RFC-формата и позволяющего адаптировать поведение под прикладные требования.

Функция имеет вид:

validator.isEmail(str [, options])

Где str — проверяемая строка, а options — объект конфигурации, влияющий на строгие и дополнительные правила валидации.

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

allow_display_name

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

Пример допустимого значения при включённой опции:

John Smith <john@example.com>

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

Особенность обработки заключается в том, что библиотека сначала выделяет email из конструкции display name, а затем применяет стандартную проверку к извлечённому адресу.

require_display_name

Параметр require_display_name задаёт противоположное поведение: email без отображаемого имени считается невалидным.

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

John Smith <john@example.com>

Недопустимая форма:

john@example.com

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

allow_utf8_local_part

Опция allow_utf8_local_part расширяет допустимые символы в локальной части email (до символа @), разрешая использование Unicode.

Без этой настройки локальная часть ограничена ASCII-символами. С включённой опцией становятся допустимыми адреса вида:

пользователь@пример.рф

или

δοκιμή@domain.com

Это важно для интернационализированных email (EAI — Email Address Internationalization), где требуется поддержка национальных алфавитов.

require_tld

Параметр require_tld управляет обязательностью доменной зоны верхнего уровня (TLD).

При true адреса без TLD считаются некорректными:

user@localhost

При false подобные значения допускаются, что полезно в тестовых окружениях или внутренних сетях.

allow_ip_domain

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

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

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

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

domain_specific_validation

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

Поведение зависит от версии библиотеки и может включать проверку:

  • ограничений длины локальной части;
  • запрещённых символов для отдельных доменов;
  • нестандартных правил формата.

blacklisted_chars

blacklisted_chars позволяет явно указать набор символов, которые запрещены в email-адресе.

Пример конфигурации:

{
  blacklisted_chars: '+*'
}

В этом случае любые адреса, содержащие указанные символы, будут отклоняться, даже если они формально соответствуют RFC-формату.

host_blacklist

Параметр host_blacklist задаёт список запрещённых доменов или хостов.

Пример:

{
  host_blacklist: ['example.com', 'test.com']
}

Адреса с такими доменами считаются недопустимыми:

user@example.com

Механизм проверки применяется после выделения доменной части email.

ignore_max_length

Опция ignore_max_length отключает проверку максимальной длины email-адреса (обычно 254 символа по стандарту RFC).

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

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

При вызове isEmail параметры обрабатываются последовательно:

  1. Извлечение display name (если разрешено)
  2. Проверка синтаксиса email
  3. Проверка локальной части (включая UTF-8, если активировано)
  4. Проверка домена (TLD, IP-адрес, blacklist)
  5. Применение дополнительных ограничений (blacklisted_chars, domain_specific_validation)

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

Комбинирование параметров

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

{
  allow_display_name: true,
  require_tld: false,
  allow_utf8_local_part: true,
  host_blacklist: ['test.com']
}

позволяет:

  • принимать email с именем отправителя;
  • разрешать локальные домены;
  • поддерживать Unicode-адреса;
  • исключать конкретные домены.

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

Особенности поведения и ограничения

Несмотря на гибкость параметров, проверка email в библиотеке остаётся синтаксической, а не семантической. Это означает отсутствие проверки:

  • существования домена;
  • наличия MX-записей;
  • доступности почтового ящика.

Параметры влияют только на формат и структуру строки, не затрагивая реальную доставляемость адреса.

Практическая модель конфигурации

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

  • базовый режим — минимальные ограничения, только синтаксис;
  • стандартный режим — добавление TLD и blacklist;
  • строгий режим — отключение display name, запрет IP-доменов, ограничение символов;
  • международный режим — включение UTF-8 локальной части и расширенных правил.

Такая градация формируется исключительно комбинацией параметров isEmail, без необходимости изменения исходного кода библиотеки.

Оглавление