Валидация форматированной строки

Природа форматированной строки и причины необходимости валидации

Форматированная строка в AutoNumeric представляет собой числовое значение, преобразованное в человекочитаемый вид с применением разделителей тысяч, символов валюты, фиксированного количества знаков после запятой и других правил отображения. В отличие от «сырого» числового значения, такая строка перестаёт быть напрямую пригодной для математических операций и требует обратного преобразования перед использованием в бизнес-логике.

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

Ключевая особенность AutoNumeric заключается в том, что он разделяет:

  • визуальное представление числа (formatted string)
  • логическое числовое значение (raw numeric value)

Валидация всегда находится на границе этих двух представлений.

Внутренние правила формирования строки

Форматированная строка в AutoNumeric строится на основе набора параметров конфигурации:

  • decimalCharacter — символ разделителя дробной части
  • digitGroupSeparator — разделитель групп разрядов
  • currencySymbol — символ валюты (если используется)
  • currencySymbolPlacement — позиция символа валюты
  • decimalPlaces — фиксированное количество знаков после запятой
  • negativePositiveSignPlacement — положение знака минус/плюс
  • showOnlyNumbersOnFocus — изменение отображения при фокусе

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

Пример:

1 234,56 €

и

€1,234.56

— это разные строки, каждая валидна только при соответствующей конфигурации.

Основной принцип валидации: обратное преобразование

В AutoNumeric нет единственного «валидатора» в классическом смысле, как в формах или схемах JSON. Вместо этого используется принцип обратного преобразования:

  1. Форматированная строка принимается как вход
  2. Производится её очистка от визуальных символов
  3. Извлекается числовое значение
  4. Проверяется корректность результата

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

Этот процесс реализуется через внутренние механизмы, аналогичные методу unformat или getNumber.

Проверка через unformat и getNumber

Одним из базовых способов валидации является попытка преобразования строки в числовое значение.

Логика выглядит следующим образом:

  • строка проходит очистку от разделителей
  • удаляются символы валюты
  • нормализуется десятичный разделитель
  • интерпретируется знак числа
  • результат преобразуется в Number или BigDecimal-подобное представление

Если результат:

  • NaN
  • null
  • undefined
  • или выходит за допустимые границы конфигурации

строка считается некорректной.

Типичный подход:

const numericValue = autoNumericInstance.getNumber(formattedString);

if (isNaN(numericValue)) {
  // строка невалидна
}

Валидация здесь опирается не на шаблон, а на результат интерпретации.

Ограничения формата и их влияние на валидность

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

1. Разделители разрядов

Строка:

1,234.56

будет невалидной при конфигурации:

digitGroupSeparator = ' '
decimalCharacter = ','

ожидаемый формат:

1 234,56

Даже если математически число корректно, строка не проходит валидацию из-за несовпадения формата.

2. Десятичный разделитель

Одна из самых частых причин невалидности — использование неправильного символа дробной части.

Например:

1234.56

невалидно при:

decimalCharacter = ','

3. Символ валюты

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

$1,234.56

может быть невалидной, если currencySymbol = '€'.

4. Положение знака

Некоторые конфигурации требуют строго фиксированного положения минуса:

-1 234,56

или

1 234,56-

Несоответствие расположения знака приводит к невозможности корректного разбора.

Поведенческая валидация при вводе

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

Пример:

  • ввод 1
  • затем 1,
  • затем 1,2
  • затем 1,23

Промежуточное состояние может не соответствовать строгому числовому формату, но система позволяет его до завершения ввода.

Это вводит важное понятие:

валидность состояния ≠ валидность финальной строки

Строгая и мягкая валидация

В контексте AutoNumeric можно выделить два подхода к проверке строк:

Строгая валидация

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

Характеризуется:

  • обязательным соответствием формату
  • отсутствием промежуточных символов
  • проверкой диапазонов (min/max)
  • проверкой количества десятичных знаков

Используется через извлечение числового значения и его проверку.

Мягкая валидация

Применяется в процессе ввода:

  • допускает временно некорректные состояния
  • ориентирована на UX
  • не блокирует ввод при каждом несоответствии

Проверка диапазонов значений

Форматированная строка считается невалидной не только из-за синтаксиса, но и из-за нарушения числовых ограничений.

AutoNumeric поддерживает ограничения:

  • minimumValue
  • maximumValue

После преобразования строки выполняется проверка:

min <= value <= max

Пример:

formatted: "999 999,99"
max: 100 000

строка синтаксически корректна, но логически невалидна.

Обработка некорректных символов

Форматированная строка может содержать:

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

Валидация включает этап нормализации:

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

Если после нормализации строка не распознаётся как число — она считается ошибочной.

Использование регулярных выражений в валидации

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

Типичный паттерн включает:

  • разрешённые цифры 0-9
  • один десятичный разделитель
  • опциональный знак
  • допустимые разделители групп

Однако регулярное выражение не способно полностью заменить внутренний парсер, так как:

  • локали различаются
  • символы валюты произвольны
  • порядок элементов может меняться

Поэтому regex используется только как первый слой защиты.

Граничные случаи валидации

Пустая строка

Пустая строка может трактоваться как:

  • ноль (если включено соответствующее поведение)
  • невалидное значение

Нули с ведущими символами

000123,45

может быть:

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

Множественные разделители

1,,234.56

всегда невалидно, так как нарушает структуру числа.

Несовместимые локали

Если строка подготовлена под одну локаль, а парсится в другой, результат становится некорректным даже при визуальной правильности.

Валидация через состояние экземпляра AutoNumeric

Каждый экземпляр AutoNumeric хранит внутреннее состояние, включающее:

  • текущее значение
  • форматированную строку
  • конфигурацию
  • флаги валидности

Это позволяет выполнять проверку без внешнего анализа строки:

autoNumericInstance.getNumericString();
autoNumericInstance.getNumber();

Если экземпляр не может корректно интерпретировать текущее значение, он возвращает нечисловой результат.

Роль нормализации перед валидацией

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

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

Без нормализации невозможно корректно определить валидность, так как один и тот же визуальный символ может иметь разные Unicode-представления.

Практическая модель проверки

Валидация форматированной строки в AutoNumeric фактически сводится к трёхэтапной модели:

  1. Синтаксический анализ

    • соответствует ли строка допустимым символам

  2. Семантический анализ

    • можно ли интерпретировать строку как число

  3. Ограничительная проверка

    • попадает ли значение в заданный диапазон и правила формата

Только прохождение всех трёх уровней означает полную валидность строки в контексте библиотеки.

Оглавление