Как очистить CSV от Windows-1251 и BOM перед импортом

Файл может выглядеть нормальным и все равно быть в неверной кодировке

CSV, выгруженный из старого бухгалтерского или учетного ПО, часто сохранен не в UTF-8. Для кириллического текста до сих пор распространен Windows-1251, для западноевропейских языков с диакритикой — Windows-1252. Табличный редактор обычно покажет такой файл без проблем: он сам подбирает, какой набор символов применить, и делает это достаточно удачно. Поэтому файл выглядит нормальным ровно до тех пор, пока его не прочитает что-то более строгое: скрипт, конвейер импорта или загрузчик в базу. Они по умолчанию ждут UTF-8 и вместо исходного текста получают стену кракозябр, из которой уже ничего не восстановить без правильной кодировки.

Трехбайтовая метка в начале файла может сломать строгий парсер

Маркер порядка байтов в UTF-8 — это невидимая последовательность из трех байтов в самом начале файла, которая подсказывает программе вроде Excel, что дальше идет текст в Юникоде. Для таких приложений это полезно. Но если файл идет в строгий JSON-импорт или скрипт, который маркера не ожидает, он превращается в проблему: лишние байты приклеиваются к первому символу имени первого столбца. В итоге колонка, которая должна называться «id», перестает точно совпадать с этим именем везде, где код его ожидает. Если найти и удалить маркер до конвертации, а не тащить его в итоговый файл, такого расхождения не будет. Отлаживать такое расхождение потом трудно, потому что на экране оба имени выглядят одинаково.

Автоматический выбор правильной кодировки без ручного списка опций

Надежное определение кодировки, которое «CSV в JSON» выполняет до чтения первой строки, сначала проверяет наличие маркера порядка байтов, затем строго валидирует оставшиеся байты как UTF-8 и только если проверка проваливается, пробует Windows-1251 или Windows-1252 в зависимости от распределения байтов с большими значениями. Этот порядок проверок важен. Файл, который уже в UTF-8, никогда не будет по ошибке принят за что-то другое. А файл не в UTF-8 будет опознан правильно, а не прочитан как UTF-8 с набором испорченных символов на выходе. То же определение стоит и перед «CSV в Excel» — на случай, когда результат нужен в таблице, а не в скрипте.

Типы данных важны не меньше, чем кодировка символов

Правильная кодировка решает только половину проблем при конвертации CSV в JSON. Вторая половина — это выбор, какие значения должны стать настоящими JSON-числами или логическими значениями, а какие нужно оставить как простой текст. Если строка 00123 превращается в число 123, ведущий ноль теряется навсегда уже в момент конвертации, и потом его неоткуда взять. А идентификатор длиной больше примерно пятнадцати цифр будет округлен, как только станет обычным числом с плавающей запятой вместо текстового значения. Такие поля нужно сохранять строками, потому что преобразование незаметно меняет сами данные, а не только их формат.

Лишний дублирующий заголовок ломает импорт иначе, чем плохая кодировка

JSON-объект не может содержать два свойства с одинаковым ключом. Поэтому если в исходном файле есть две колонки с одинаковым заголовком — обычная ситуация для выгрузок, собранных из нескольких систем, — при конвертации дубликаты нужно переименовать так, чтобы они различались. Иначе данные из второй колонки незаметно перепишут данные из первой в каждом объекте результата. Это другая причина сбоев, не связанная с кодировкой или типами, но она так же легко портит импорт. Проверьте, что инструмент конвертации сообщает о такой коллизии, а не решает ее без предупреждения, а «Форматер JSON» сразу покажет переименованные ключи в результате.

Пошагово: проверить файл до того, как он уйдет в импорт

Сконвертируйте выгрузку один раз в «CSV в JSON» с разделителем и кодировкой в режиме автоопределения и проверьте обе догадки: передайте результат в «Форматер JSON», один из следующих шагов, которые предлагает страница, и прочитайте первые записи. Кириллица или диакритика, превратившиеся в кракозябры, значат, что ошиблось определение кодировки; один длинный ключ, внутри которого остались разделители, — что ошиблось определение разделителя. Задайте вручную то, что определилось неверно, и конвертируйте заново: в меню кодировок есть Windows-1251, Windows-1252, UTF-8 с BOM и без него и UTF-16 LE, в меню разделителей — запятая, точка с запятой, табуляция, вертикальная черта или свой символ. Файл, разделитель или кодировку которого понять не удается, отклоняется с сообщением, а не превращается в бессмыслицу.

Дальше решите, как типизировать значения: по умолчанию инструмент и так оставляет текстом значения с ведущим нулем и длинные идентификаторы, а для файла из кодов, телефонов или номеров счетов типы значений «Оставлять все как текст» не конвертируют ничего. Пока результат открыт в инструменте «Форматер JSON», поищите два следа неаккуратного исходника: две колонки с заголовком id выходят как id и id_2, а у строки, где полей больше, чем в заголовке, лишние значения собираются под ключом __extra. И то и другое дешевле исправить в исходном файле, чем в системе, которая потом на этом споткнется. За один раз проходят до двадцати файлов общим объемом 300 МБ, и все это внутри вкладки браузера.