Нормализация перед валидацией

Начнём с перечня, потому что «чистить всё подряд» — тоже болезнь. Пробелы по краям: TrimSpace на каждом строковом поле, что приходит от людей — имена, заголовки, поисковые запросы; машины-клиенты это тоже оценят. Регистр: почтовые домены безусловно в нижнем регистре, ники и слаги — по правилу проекта; для секретов см. ниже. Телефоны: единая форма хранения — обычно только цифры без пробелов и дефисов; «+7 (916) 123-45-67» после чистки станет «79161234567», а «89161234567» — самим собой, и свести оба к одной строке можно, лишь отдельным правилом заменив восьмёрку на код страны. Юникодная пустота: неразрывные пробелы U+00A0 и NEL U+0085, приехавшие из копипасты, — про них отдельный разговор ниже. Чего нормализация данных go не делает: не исправляет опечатки, не расшифровывает намерения, не меняет смысл поля. Граница простая: если операцию можно повторить дважды с одинаковым результатом и она не теряет информации — это нормализация; всё остальное — бизнес-решение, и оно живёт после валидации. Место операции — граница API, один раз: данные канонизируются на входе и дальше путешествуют по системе чистыми, а не подчищаются в каждом слое заново. Аргумент «почистим в каждом слое на всякий случай» вежливо отклоняйте: у каждого слоя своя трактовка пробела и регистра, и через два релиза данные проходят через три разные чистки. Канон задаётся одной функцией на границе — и именно в эту функцию смотрят тесты.

strings.TrimSpace режет не только ASCII-пробел: под определение юникодного whitespace попадают табуляция, переводы строк, U+00A0 (неразрывный пробел) и U+0085 — всё то, чем мессенджеры и текстовые редакторы щедро снабжают скопированный текст. Поэтому trim перед валидацией решает проблему невидимого мусора, о которой пользователь не знает и которую никогда не отловите ручным тестом: строки «ada@example.com» и «ada@example.com » выглядят одинаково, а валидатору email видно разницу. Но у трима есть граница, о которой забывают: он работает только по краям строки. Неразрывный пробел в середине — «Иван Петров» — останется как был, и для таких полей нужна своя замена через strings.Map или ReplaceAll по месту. С регистром так же честно: strings.ToLower приводит к нижнему регистру по юникодным правилам, доменная часть почты канонична в нижнем, а вот локальная часть формально чувствительна к регистру по RFC — практика практически везде складывает её тоже, но решите это правилом проекта и запишите в документацию поля. Телефоны — своя история: замените всё нецифровое на пустоту и решите, храните ли вы код страны. Все три операции дешёвые — но дело не в цене, а в порядке: после них теги видят то, что имеет смысл проверять.

В Echo и chi порядок bind → normalize → validate пишется руками, и нормализация встаёт между шагами естественно — конвейер из тринадцатого урока принимает её без переделок. В Gin сложнее: ShouldBindJSON декодирует и валидирует одним вызовом, между половинками не вставить ни строчки. Если оставить правила в binding-тегах, проверка случится на грязных данных внутри ShouldBindJSON, и нормализация после неё бессмысленна — ошибки уже уехали. Рабочих рецепта два, и оба честные. Первый: правила живут в теге validate, ShouldBindJSON выполняет только декод (валидационных ошибок не будет), затем Normalize(), затем ручной validate.Struct — конвейер разлеплён руками, а ответ 400 собирается как в двенадцатом уроке. Второй: правила остаются в binding, а нормализация переезжает внутрь вашего валидатора — реализации интерфейса, который gin дергает перед проверкой; это путь для проектов, где binding-теги уже расставлены по всему коду. Выбирайте один рецепт на проект: два способа в одном репозитории гарантируют, что однажды кто-то почистит данные дважды или не почистит вовсе.

Зачем всё это, если required и email и так отработали? Каноническая форма — обязательство перед хранилищем и поиском. Уникальный индекс на email различает регистр посимвольно: без lower-case у вас появятся Ada@example.com и ada@example.com — два пользователя, одна почта, и поддержке придётся разгребать, чей аккаунт настоящий. Поиск по нику без трима не найдёт строку с краевым пробелом. Отчёты, дедупликация, сравнение строк — всё опирается на канон, и канон задаётся один раз на границе. Отсюда и проверка того, что нормализация сработала: тесты на уровне валидации должны гонять грязные входы — с NBSP, с регистром, с пробелами — и фиксировать, что до правил доходит чистое значение; это тот же табличный каркас из урока про тесты, только колонка входа грязная. Заметьте и эффект на сообщения: после нормализации тексты ошибок говорят о деле — «минимум 8 символов» вместо загадочного провала формата на строке, в которой пользователь пробелов не видел. Честное сообщение начинается с честных данных. Альтернатива «пусть база сама различает без учёта регистра» существует — в Postgres есть citext и регистронезависимые коллации, — но переносить политику канона в хранилище значит потерять её из виду: нормализация разъедется между базами и версиями, а переезд на другое хранилище потребует изобретать её заново. Приложение остаётся единственным местом, где про канон знает весь стек.

Три легальных места, по возрастанию централизации. Метод Normalize на DTO — по умолчанию: чистка видна рядом с полями, тесты простые, а хендлер зовёт одну строку; минус — у каждой структуры свой метод, и общий приём повторяется. Функция-хелпер normalizeAndValidate(dto) — для проектов с десятками структур: одна точка порядка, но вход должен быть интерфейсом с методом Normalize, и это контракт, который придётся держать. Внутри Validation-хука фреймворка — самый централизованный вариант: Echo-валидатор из тринадцатого урока чистит перед Struct, gin-реализация то же самое делает до ValidateStruct; удобно, но чистка перестаёт быть видимой в хендлере — компенсируйте комментарием и тестом. Чего не заводить никогда: нормализацию внутри теговых функций. Функция-тег — чистый предикат из десятого урока: она отвечает bool, не мутирует данные, иначе Value() в ошибках устаревает, порядок правил в цепочке делает результат неочевидным, а повторный вызов того же правила на том же поле даёт другой ответ. Тот же запрет — на структурный уровень из одиннадцатого: он оценивает, а не исправляет. И последнее: конфигурационные данные из Viper чистят той же дисциплиной перед валидацией конфига — тема восемнадцатого урока, приёмы те же. Отдельный вопрос — мутация входа: Normalize меняет DTO на месте, и если сырой payload нужен для аудита или повторной обработки, чистите копию: одна строка копирования перед методом, зато журнал хранит то, что прислал клиент, а не то, что вы из него сделали.