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

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

Валидация с учетом регионов строится вокруг идеи, что формат данных определяется не только синтаксисом, но и локальными стандартами. Например, запись даты 01/02/2026 может означать 1 февраля или 2 января в зависимости от региона. Аналогично, телефонные номера, денежные значения и почтовые индексы имеют разную структуру.

Основная задача при использовании validator.js в многонациональных приложениях — не просто проверить корректность строки, а интерпретировать её в контексте локали.

Локали в телефонных номерах

Функция isMobilePhone поддерживает список регионов, что позволяет учитывать национальные форматы.

import validator from 'validator';

validator.isMobilePhone('8 (707) 123-45-67', 'ru-KZ');
validator.isMobilePhone('+1 202-555-0125', 'en-US');
validator.isMobilePhone('+44 7700 900123', 'en-GB');

Особенности региональной валидации телефонов

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

Поддерживаемые локали включают десятки вариантов: ru-RU, ru-KZ, en-US, en-GB, de-DE, fr-FR и другие.

Числовые форматы и разделители

В разных регионах различается использование запятой и точки в числах:

  • США: 1,234.56
  • Европа: 1.234,56
  • Казахстан и Россия: чаще используется 1 234,56 или 1234,56

В validator.js числовая валидация частично учитывает это через методы:

validator.isDecimal('1234.56', { locale: 'en-US' });
validator.isDecimal('1234,56', { locale: 'de-DE' });

Важный аспект региональной обработки чисел

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

Даты и региональные форматы

Хотя validator.js не является полноценной библиотекой для работы с датами, некоторые проверки могут учитывать формат ISO или локальные представления при кастомной валидации.

Типичные региональные форматы:

  • США: MM/DD/YYYY
  • Европа: DD/MM/YYYY
  • ISO: YYYY-MM-DD

Пример пользовательской проверки:

const isValidDateEU = (value) => {
  return /^\d{2}\/\d{2}\/\d{4}$/.test(value);
};

Для реальных проектов часто используется комбинирование с moment.js или date-fns, а validator.js применяется только как слой первичной фильтрации строки.

Почтовые индексы и региональные шаблоны

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

  • США: 12345 или 12345-6789
  • Великобритания: SW1A 1AA
  • Казахстан: 010000
  • Германия: 10115

В validator.js отсутствует универсальный метод для всех стран, поэтому используется регулярная валидация:

const postalCodeValidators = {
  'US': /^\d{5}(-\d{4})?$/,
  'GB': /^[A-Z]{1,2}\d[A-Z\d]? \d[ABD-HJLNP-UW-Z]{2}$/i,
  'KZ': /^\d{6}$/
};

function isPostalCode(value, country) {
  return postalCodeValidators[country]?.test(value) || false;
}

Локализация email и доменных проверок

Формат email стандартизирован (RFC 5322), однако региональные особенности проявляются в доменных зонах:

  • национальные домены: .kz, .ru, .de
  • многоязычные домены (IDN): почта.рф

validator.js предоставляет базовую проверку:

validator.isEmail('user@domain.kz');
validator.isEmail('пользователь@домен.рф');

Однако Unicode-домены требуют предварительной обработки (punycode-конвертации), поскольку внутренняя проверка работает с ASCII-форматом.

Валидаторы с параметром locale

Многие методы библиотеки принимают параметр локали:

  • isMobilePhone(value, locale)
  • isDecimal(value, options)
  • isFloat(value, options)

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

validator.isFloat('1 234,56', {
  locale: 'de-DE'
});

Это позволяет учитывать различия:

  • разделители тысяч
  • десятичные символы
  • допустимые пробелы

Региональные особенности URL и IDN

URL-адреса также зависят от локализации доменов:

validator.isURL('https://пример.рф');
validator.isURL('https://example.com');

Однако внутренне такие адреса могут требовать преобразования в Punycode:

  • пример.рф → xn--e1afmkfd.xn--p1ai

Валидация в validator.js проверяет структуру URL, но не выполняет полноценную международную нормализацию.

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

В реальных приложениях validator.js используется как слой первичной фильтрации, а региональная логика выносится отдельно:

  1. Определение региона пользователя
  2. Выбор набора правил (regex, locale)
  3. Валидация через validator.js
  4. Постобработка и нормализация

Пример архитектуры:

function validateUserInput(input, region) {
  switch (region) {
    case 'KZ':
      return validator.isMobilePhone(input, 'ru-KZ');
    case 'US':
      return validator.isMobilePhone(input, 'en-US');
    default:
      return validator.isEmail(input);
  }
}

Ограничения регионального подхода в validator.js

Несмотря на поддержку локалей, validator.js не является полноценной i18n-библиотекой. Основные ограничения:

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

Это приводит к необходимости комбинировать библиотеку с внешними инструментами:

  • библиотеки локализации (i18n)
  • парсеры дат
  • нормализаторы Unicode
  • кастомные регулярные выражения

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

В формах регистрации или финансовых системах региональная валидация часто объединяет несколько уровней:

function validatePaymentForm(data, locale) {
  return (
    validator.isEmail(data.email) &&
    validator.isMobilePhone(data.phone, locale) &&
    validator.isDecimal(data.amount, { locale })
  );
}

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

Оглавление