Границы нормализации

Нормализация заменяет несколько представлений одним выбранным. Например, JSON с разными отступами можно записать одинаково, а строки с CRLF привести к LF. Польза появляется только после ответа на вопрос: какие различия для этого набора несущественны? Без такого решения нормализатор становится преобразователем данных с неявной потерей информации.

Сортировка ключей JSON обычно не меняет модель объекта, но сортировка массива может изменить последовательность событий. Удаление пробелов вокруг CSV-поля иногда исправляет случайный ввод, а иногда портит значимый код. Одинаковое правило нельзя применять ко всем строкам только потому, что они хранятся в одном файле. Нужна схема или явно записанное соглашение о полях.

Хеш относится к байтам. После форматирования JSON отпечаток изменится, даже если разобранные значения равны. Поэтому полезно различать хеш исходника, хеш опубликованного представления и результат семантического сравнения. Последний нельзя называть контрольной суммой файла без описания алгоритма. Для криптографической подписи требуется точно определённая канонизация, а не просто красивый вывод.

Обычный json.dumps с sort_keys не является реализацией любого стандарта канонизации. Имеют значение представление чисел, правила Unicode, экранирование и допустимость повторных ключей. Парсер может округлить десятичное число или оставить только последнее значение дубликата. После этого форматирование уже не способно вернуть потерянные сведения. Проверку неоднозначностей выполняют до преобразования.

Разделите операции на независимые шаги: декодирование, проверка синтаксиса, проверка схемы, преобразование значений и оформление результата. Для каждого шага храните версию правила. Тогда изменение отступа не выглядит как изменение часового пояса, а исправление некорректного значения не маскируется словом «очистка». Журнал должен позволять объяснить каждое намеренное изменение.

Unicode-нормализация тоже требует решения предметной области. Визуально похожие строки могут состоять из разных последовательностей кодовых точек. NFC помогает сопоставлять некоторые из них, но не превращает все похожие символы в один. Не следует автоматически применять совместимостную нормализацию к паролям, подписям или идентификаторам без отдельного контракта.

Полезно хранить краткий отчёт о преобразовании по полям. Например, сколько строк получили другой Unicode-состав, сколько чисел изменили текстовую запись и сколько значений были отклонены. Такой отчёт не должен содержать сами закрытые данные. Он помогает отличить ожидаемую массовую замену от случайной ошибки в одном столбце. Если правило затронуло неожиданно много записей, публикацию лучше остановить до разбора причины. Для проверки выберите не только обычные строки, но и крайние значения допустимого диапазона. Сравнение на случайной выборке может не заметить редкое, но важное состояние. Контракт нормализации должен включать поведение при ошибке, а не только форму успешного результата и параметры оформления выходного файла.

Сохраните оригинал и сделайте небольшую выборку с неудобными значениями: пробелом в конце, пустой строкой, null, большим целым, комбинируемым символом и массивом из двух элементов. Проверьте, какие изменения вы ожидаете для каждого случая. Сравнение должно показывать не только успешное выполнение, но и конкретный результат правила.

Повторный запуск нормализатора должен давать тот же результат, если операция заявлена идемпотентной. Это полезное свойство, но недостаточное доказательство правильности: удаление всех строк тоже идемпотентно. Дополнительно проверяйте число записей, сохранение идентификаторов и оговорённые инварианты. Для больших наборов считайте контрольные агрегаты и записывайте отклонённые записи отдельно.

Публикуйте описание преобразования вместе с результатом. Укажите, можно ли восстановить исходное представление, какие поля были затронуты и как обнаружить версию нормализатора. Если обратимость нужна, храните исходные байты или отдельное соответствие изменений. Обещание «данные не изменились» допустимо только относительно явно определённой модели сравнения, а не относительно субъективного сходства текста.