Номера без контрольной цифры ломают привычную логику, в которой у любой проверки есть два исхода. Здесь исходов больше, и самый непривычный из них — честное признание того, что проверять значение нечем. Ниже разберём, откуда берутся такие системы, почему это не дефект, что означает вывод о формате, чем он отличается от вывода о недействительности и как выстроить четыре разных сообщения там, где раньше было два.
Какие системы не публикуют алгоритм проверки?
Представим реестр, в котором каждому новому объекту присваивают следующий свободный номер. Никакой арифметики здесь нет: номер — это просто порядковый знак, выданный регистрирующим органом. Такой номер уникален и удобен, но вычислить его последний знак из остальных невозможно, потому что он не вычисляется.
Таких систем больше, чем кажется. Причина обычно историческая: реестр завели задолго до того, как проверка контрольных знаков стала обычной практикой, и менять правила задним числом невозможно — пришлось бы переоформлять миллионы уже выданных номеров.
Вторая причина — ведомственная. Орган, ведущий реестр, может считать формат номера внутренним делом и не публиковать никаких правил, кроме самого вида записи. Даже если какая-то арифметика внутри существует, снаружи она недоступна, и для нас это равносильно её отсутствию.
Третья причина — прямо противоположная. Система может не иметь никаких внутренних правил вовсе: номер формируется как последовательность признаков, а уникальность обеспечивается централизованной выдачей, а не структурой строки. Тогда проверять нечего в принципе, кроме вида.
Почему так бывает и это не дефект?
Соблазнительно объявить такие системы неполноценными. Это неверная оценка. Контрольная цифра решает конкретную задачу — ловить ошибки при переписывании, — и нужна она не всем.
Если номер никогда не вводят руками, а всегда передают машиной от источника к потребителю, защита от опечатки теряет смысл. Если номер не выходит за пределы одного ведомства, ошибки исправляются сверкой с реестром, а не арифметикой. Если номер выдаётся один раз и проверяется запросом, арифметическая защита тоже избыточна.
Кроме того, у контрольной цифры есть цена. Она занимает знак в номере, требует строгого порядка записи и добавляет правило, которое придётся поддерживать десятилетиями. Для системы, которой защита не нужна, это чистая потеря.
Отсюда важный вывод для проектирования: отсутствие алгоритма — не пробел в чужой системе, а свойство, которое нужно уважать. Подставлять вместо него похожее правило нельзя: вы начнёте отвергать корректные номера, и пользователь не сможет ничего исправить.
Что означает вывод о формате?
Вывод о формате отвечает ровно на один вопрос: похожа ли строка на номер этого вида. Проверяются длина, разрешённый состав знаков и, если структура известна, наличие ожидаемых смысловых частей.
Этот вывод не содержит утверждения о значении. Строка с правильной длиной и правильным составом может быть номером, выданным давно, номером, выданным вчера, номером из соседней системы с такими же параметрами или вообще набором знаков, который никто не выдавал. По самой строке различить эти случаи невозможно.
Поэтому формулировка вывода должна быть ограниченной. Честные варианты звучат так: «формат соответствует», «подтверждён только вид записи», «алгоритм проверки в этой системе не опубликован». Все они описывают наши возможности, а не качество номера.
Нечестный вариант — «действителен». Это слово обещает, что значение подтверждено, хотя подтверждён только внешний вид. Пользователь прочитает его как гарантию, которой у вас нет. Такое же искажение возникает и со словами о подлинности: формат не является свидетельством подлинности ни в одной системе.
Как проверять строку, у которой нет алгоритма?
Проверка строится по шагам, и каждый шаг даёт что-то полезное, хотя ни один не заменяет арифметику.
- Очистите строку от разделителей и выровняйте регистр. Это единственная операция, которая делает сравнение осмысленным.
- Проверьте состав знаков. Посторонний символ внутри — самая грубая ошибка, и она видна сразу.
- Проверьте длину. Если система допускает несколько длин, проверьте каждую и не выбирайте одну наугад.
- Сопоставьте со всеми известными системами, у которых совпадают длина и состав. Если подошло несколько, покажите все.
- Для каждой подошедшей системы отдельно укажите, есть ли у неё опубликованный алгоритм, и приведите соответствующий вывод.
Ценность этих шагов не в том, что они подтверждают номер, а в том, что они отсекают заведомо неверный ввод и направляют строку в правильную ветку обработки. Для системы, где дальше идёт обращение к реестру, это экономит заметную часть запросов.
Отдельно скажем о качественной стороне. Если вы не уверены, есть ли у системы алгоритм, не выводите это из похожести на другие системы. Ответ берут из описания самой системы. Логика «у соседей контрольная цифра есть, значит, и здесь она есть» приводит к ложным отказам, а они дороже пропущенных ошибок.
Почему строку без алгоритма нельзя объявлять недействительной?
Потому что это подмена утверждения. Формулировка «номер недействителен» сообщает пользователю, что с его значением что-то не так. Если причина в том, что у вас нет правила, вы перекладываете собственную неполноту на пользователя и заставляете его переделывать корректные данные.
Цена такой ошибки выше, чем кажется. Пользователь, получивший отказ на верном документе, не станет искать обходной путь внутри формы — он уйдёт из неё. Если речь о регистрации или оформлении заказа, уходит и сделка. При этом никакой технической проблемы не было: строка корректна, не хватало только правила.
Второе следствие — доверие к сообщениям в целом. Если система уверенно ошибается в одном месте, пользователь начинает сомневаться и в остальных её подсказках. Поэтому различие между «мы не можем проверить» и «значение неверно» стоит закрепить не только в интерфейсе, но и в проектной документации.
Третий аспект — аналитика. Если отказы по отсутствию правила и отказы по несогласованной арифметике попадают в одну категорию, вы не сможете понять, что происходит: растёт ли число настоящих опечаток или просто расширился поток номеров из системы, для которой у вас нет правил.
Как устроить четыре разных сообщения
Практический приём — заранее определить набор состояний и не сводить их друг к другу ни в интерфейсе, ни в отчётах.
| Состояние | Что известно | Формулировка для пользователя |
|---|---|---|
| Согласовано | контрольная цифра сходится | значение непротиворечиво |
| Не сходится | формат верен, арифметика нет | проверьте ввод, возможна опечатка |
| Только формат | алгоритма в системе нет | подтверждён вид записи, значение — нет |
| Нет правила | подходящей системы не найдено | правила для этого номера у нас нет |
Обратите внимание на последнюю строку: в ней нет ни слова о номере. Это не уклонение, а точное описание ситуации. Как устроены такие состояния в общем конвейере, разобрано в материале про устройство проверки номера.
Разделение состояний полезно и внутри команды. Когда каждое состояние видно отдельно, становится понятно, куда вкладывать усилия: расширять таблицу правил, улучшать очистку ввода или разбираться с качеством источника данных.
Что делать дальше
Пройдитесь по списку систем, с которыми работает ваша форма, и честно отметьте те, где проверка значения невозможна. Затем посмотрите, что происходит с ними сейчас: скорее всего, часть отклоняется по правилу, которое к ним не относится.
После этого откройте инструмент проверки, введите несколько вымышленных строк и посмотрите, как выводятся четыре разных состояния, включая случай, когда правила нет вовсе. Сопоставьте свои подсказки с этой логикой. Если ваша форма общается с внешним сервисом, стоит отдельно разобраться, где заканчивается локальная проверка и начинается обращение к реестру, — об этом в статье про проверку на границе API. Все номера, упомянутые здесь, придуманы для объяснения и не описывают реальных записей; вывод о формате не является суждением о подлинности или существовании номера, а отсутствие правила говорит лишь об отсутствии правила.