Почему Excel портит коды в CSV
CSV — текстовый формат: в нём нет типов. Тип придумывает та программа, которая файл открывает. Excel придумывает его агрессивно, и именно поэтому коды в нём ломаются.
Три способа потерять данные за один двойной щелчок
Ведущие нули
Значение 00123 выглядит как число — Excel делает из него число 123. Ноли не «спрятаны», их больше нет: при сохранении обратно в CSV в файл уйдёт именно 123.
Экспоненциальная запись
Номер полиса 7812345678901234 превращается в 7,81235E+15. Выглядит как проблема отображения, но это не так.
Потеря точности
Числа в Excel хранятся с двойной точностью — это 15–16 значащих цифр. Шестнадцатизначный номер полиса уже на грани, семнадцатизначный — за ней: последние цифры заменяются нулями безвозвратно. Расширение колонки не поможет, данные уже потеряны.
В российской практике под удар попадают СНИЛС, номер полиса ОМС, ИНН с ведущим нулём, коды ОКТМО и ОКАТО, штрихкоды, номера счетов и лицевых счетов.
Почему «поменять формат ячейки» не спасает
Формат ячейки влияет на то, как значение показывается, а не на то, что в нём лежит. К моменту, когда вы меняете формат, преобразование уже произошло при разборе файла. Единственный способ — не дать Excel решить за вас на этапе открытия.
Рабочие способы
- Мастер импорта текста. Не открывать файл двойным щелчком, а импортировать: «Данные» → «Из текста/CSV», и для каждой колонки с кодами выбрать тип «Текстовый». Нудно, но работает.
- Кавычки не помогают. Распространённое заблуждение:
"00123"Excel всё равно распознает как число. Кавычки в CSV говорят только о границах поля. - Префикс-апостроф. Если вы формируете CSV сами, значение
'00123Excel покажет текстом — но этот апостроф попадёт в данные для всех остальных программ. - Не открывать в Excel вовсе. Если задача — посмотреть, отфильтровать, сверить или выгрузить подмножество, промежуточный Excel просто не нужен.
Как это сделано у нас
Тип колонки определяется по выборке значений, и есть три правила, которые Excel игнорирует:
- значение с ведущим нулём делает всю колонку текстовой;
- колонка, где у всех значений одинаковая длина в 11 и более цифр, считается кодом, а не числом: так ведут себя СНИЛС, полис и номер счёта;
- значения длиннее 15 цифр текстовые всегда — за этой границей арифметика с двойной точностью врёт.
При выгрузке в XLSX такая колонка остаётся текстовой, поэтому Excel уже ничего не «исправит».
Частые вопросы
Можно ли вернуть потерянные нули?
Если известна длина кода — да, дополнением слева нулями. Если потеряна точность длинного номера — нет, эти цифры не восстановить.
А Google Sheets ведёт себя так же?
Похоже: ведущие нули теряются, длинные числа округляются. Разница в мелочах, суть та же.
Почему тогда все пользуются CSV?
Потому что он читается чем угодно. Проблема не в формате, а в том, что типы в нём не записаны и каждый читатель угадывает их сам.