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