Настройка строгости проверки

Строгость проверки в Validator.js определяется совокупностью выбранных правил, параметров функций и предварительной нормализации входных данных. Библиотека не навязывает единую модель валидации, предоставляя гибкость настройки поведения под разные уровни требований: от мягкой проверки пользовательского ввода до жёсткого соответствия формальным спецификациям.

Под строгостью понимается степень допустимых отклонений входных данных от ожидаемого формата. В Validator.js это выражается через:

выбор конкретных валидаторов (например, isEmail, isNumeric, isLength);
параметры функций (например, опции строгого режима в isEmail);
предварительную нормализацию строк;
комбинирование нескольких проверок;
использование регулярных выражений;
постобработку входных значений.

Разные уровни строгости формируют разные сценарии применения: от пользовательских форм до системной валидации API.

Нормализация входных данных как основа строгой проверки

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

Удаление лишних символов

validator.trim('  example@email.com  ');

Удаление пробелов по краям снижает количество ложных ошибок при проверке строк.

Приведение регистра

Для некоторых типов данных (например, email) регистр не имеет значения:

validator.normalizeEmail('Example@Email.Com');

Нормализация email может включать:

приведение домена к нижнему регистру;
удаление точек в Gmail-адресах (опционально);
удаление субадресации (плюс-алиасы).

Эти параметры напрямую влияют на строгость обработки.

Строгость проверки email

Наиболее гибкая конфигурация реализуется через isEmail.

validator.isEmail(email, options);

Основные параметры строгого режима

{
  allow_display_name: false,
  require_display_name: false,
  allow_utf8_local_part: false,
  require_tld: true,
  allow_ip_domain: false,
  domain_specific_validation: true,
  blacklisted_chars: '',
  host_blacklist: []
}

Значение ключевых параметров

require_tld Указывает обязательность доменной зоны (.com, .ru). При включении повышает строгость, исключая локальные домены.
allow_utf8_local_part При false запрещает Unicode в локальной части email, что соответствует более строгим RFC-ограничениям.
allow_display_name Отключение исключает формат "Имя <email@domain.com>", оставляя только чистый адрес.
domain_specific_validation Включает дополнительные проверки для отдельных почтовых провайдеров.

Пример строгой проверки:

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

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

Строгость числовых проверок

isNumeric

validator.isNumeric(str, options);

Параметры:

{
  no_symbols: true
}

При no_symbols: true допускаются только цифры без знаков, пробелов и разделителей.

isInt и диапазоны

validator.isInt(str, {
  min: 0,
  max: 100
});

Строгость увеличивается при:

ограничении диапазона;
запрете ведущих нулей через дополнительную проверку;
исключении знаков + и -.

isFloat

validator.isFloat(str, {
  locale: 'en-US'
});

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

Строгость длины строк

isLength

validator.isLength(str, { min: 10, max: 20 });

Строгая настройка обычно предполагает:

фиксированный диапазон;
предварительный trim;
запрет невидимых символов.

Дополнительное усиление:

const normalized = validator.trim(str);
validator.isLength(normalized, { min: 10, max: 20 });

Регулярные выражения как механизм максимальной строгости

Validator.js включает matches, позволяющий задавать полностью кастомные правила.

validator.matches(str, /^[a-z0-9_-]{3,16}$/);

Использование регулярных выражений обеспечивает:

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

Типичные сценарии:

логины;
идентификаторы;
коды подтверждения;
технические ключи.

Комбинирование проверок для усиления строгости

Один валидатор редко обеспечивает достаточную точность. На практике используется цепочка проверок.

Пример:

const value = validator.trim(input);

const isValid =
  validator.isLength(value, { min: 8, max: 20 }) &&
  validator.matches(value, /^[a-zA-Z0-9]+$/) &&
  !validator.contains(value, ' ');

Комбинации позволяют:

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

Строгость и интернационализация

Некоторые валидаторы учитывают локаль:

isMobilePhone
isPostalCode
isFloat

Пример:

validator.isMobilePhone(number, 'ru-RU');

Строгая проверка предполагает фиксацию конкретного региона, без использования универсального режима.

validator.isMobilePhone(number, 'any', { strictMode: true });

При включении строгого режима:

отключаются слабые совпадения;
требуется точное соответствие формату страны.

Отключение допустимых «гибких» сценариев

Многие функции Validator.js допускают мягкие совпадения по умолчанию. Усиление строгости достигается отключением таких возможностей:

разрешения символов локализации;
поддержки альтернативных форматов;
нестрогого сравнения.

Пример ослабленного поведения:

validator.isAlphanumeric(str, 'en-US');

Более строгий вариант:

validator.isAlphanumeric(str, 'en-US', {
  ignore: ''
});

Или дополнительная фильтрация через регулярное выражение.

Слой предварительной валидации

Строгая система часто включает предварительные проверки до вызова Validator.js:

удаление HTML-тегов;
нормализация пробелов;
исключение управляющих символов;
приведение кодировки.

Пример:

const cleaned = input
  .replace(/<[^>]*>/g, '')
  .replace(/\s+/g, ' ')
  .trim();

validator.isLength(cleaned, { min: 5, max: 50 });

Построение уровней строгости

В практических системах выделяются уровни:

Мягкий уровень

допускаются альтернативные форматы;
минимальные ограничения;
ориентация на UX.

Средний уровень

базовая нормализация;
ограничение диапазонов;
частичная фильтрация символов.

Жёсткий уровень

строгие регулярные выражения;
отключение локальных исключений;
фиксированные форматы;
отсутствие альтернативных интерпретаций.

Архитектура строгой валидации

Типовая структура:

Предобработка (trim, normalize)
Базовая проверка типа (isString, isInt)
Форматная проверка (isEmail, matches)
Контекстная проверка (длина, диапазоны)
Бизнес-правила (уникальность, зависимости)

Validator.js закрывает в основном шаги 2–4, тогда как шаг 5 реализуется прикладной логикой.

Типичные ошибки при настройке строгости

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

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

Баланс между строгостью и устойчивостью

Чрезмерная строгость может приводить к:

отклонению корректных данных;
ухудшению пользовательского опыта;
увеличению количества ошибок на клиенте.

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