Перейти к содержимому
PulsarKit

Как гонять CSV в Excel и обратно, не ломая данные

CSV, который прошел через Excel и вернулся обратно, может незаметно измениться по сравнению с исходным файлом, и отличия не всегда бросаются в глаза.

Автор: PulsarKit · ·

Проблема с разделителем начинается еще до открытия файла

Excel решает, как разбивать CSV на столбцы, по разделителю списков в региональных настройках вашей операционной системы, а не по содержимому файла. На компьютере с европейской локалью разделитель по умолчанию — точка с запятой. В итоге нормальный экспорт с запятыми как разделителями попадает в одну колонку неразбитого текста. На машине с настройками США та же история происходит наоборот, уже с файлом, где разделитель — точка с запятой. Ни в одном из случаев файл не сломан. Excel сделал предположение по настройкам, которые никак не связаны с тем, как файл был записан. Конвертер вроде «CSV в Excel», который сам разбирает файл с несколькими кандидатами на роль разделителя и проверяет, какой из них дает одинаковое количество полей в выборке строк, уходит от этой угадайки. Он не полагается ни на расширение файла, ни на системную настройку.

Начальные нули и длинные номера — незаметные жертвы

Самый разрушительный эффект при переходе из CSV в Excel — слишком рьяное превращение текста в числа. Код товара, записанный как 00123, в тот же момент превращается в число 123, как только таблица решает, что это «похоже на число». Начальный ноль потом уже не восстановить: он исчезает. Длинные идентификаторы ломаются по-другому: шестнадцатизначный номер карты или штрихкода без предупреждения теряет несколько последних цифр, потому что обычные числа в таблицах не умеют хранить больше примерно пятнадцати значащих цифр без округления. И то и другое должно оставаться текстом, а не конвертироваться в числа, и то же правило действует, когда получатель — программа, а не Excel: «CSV в JSON» сохраняет такие значения строками. При этом числовые по смыслу значения (количества, цены, суммы) должны преобразовываться в числа, чтобы их можно было складывать и использовать в расчетах.

Кодировка — где ломаются неанглийские данные

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

Сама метка порядка байтов тоже может незаметно навредить

Метка порядка байтов (BOM) в UTF-8 — это три невидимых байта в самом начале файла, которые сообщают Excel, что дальше идет Unicode-текст. Когда файл предназначен для Excel, это полезно. Проблемы начинаются, как только файл читает что-то другое: консольная утилита или старая система импорта, которая не отбрасывает эти байты, получает их приклеенными к первому символу первой ячейки заголовка. В результате колонка, которая должна называться «id», перестает совпадать с именем, которое ищет система. Оставлять BOM или удалять — зависит только от того, кто будет читать файл дальше. Универсального правильного варианта по умолчанию нет.

Обратное направление добавляет собственные развилки

Когда вы сохраняете таблицу обратно в CSV через «Excel в CSV», появляется вопрос, которого нет в другую сторону: ячейка с формулой содержит два значения: текст формулы и число, в которое она в последний раз вычислилась. CSV может унести с собой только одно из них. Экспортировать рассчитанное значение — то, чего ожидает большинство систем при импорте. Экспортировать текст формулы — то, что удобнее человеку, который проверяет файл глазами. С датами нужна такая же явная аккуратность. Записывайте их в одном выбранном формате, а не полагайтесь на то, как их отобразила таблица. Тогда один и тот же файл не начнет показывать по-разному выглядящие даты в зависимости от региональных настроек компьютера, на котором его формировали.

Типичные ошибки и настройка, которая закрывает каждую

Оставить точку десятичным разделителем. Выгрузке с точкой с запятой из страны, где полтора пишут как 1,50, в «CSV в Excel» нужен десятичный разделитель «Запятая», иначе каждая цена останется строкой и не будет складываться. Доверить идентификаторы автоматическому определению типов. Оно бережет ведущие нули и все, что длиннее пятнадцати цифр, но номер заказа или почтовый индекс без нуля в начале все равно станет числом; если ни одной колонке не нужны вычисления, типы ячеек «Все как текст» переносят каждое значение ровно так, как оно записано. Загнать выгрузку на несколько миллионов строк в одну книгу. XLSX останавливается на 1 048 576 строках, поэтому CSV длиннее отклоняется со ссылкой на «Разделить CSV», а не обрезается молча.

На обратном пути сверьте три значения по умолчанию в «Excel в CSV» с тем, что будет читать файл дальше. Кодировка результата — UTF-8 с BOM, она нужна Excel; скрипту или загрузчику в базу обычно нужен чистый UTF-8. Формат даты — ISO 8601, так что 14 марта 2026 года становится 2026-03-14 на любой машине, а 14.03.2026, 03/14/2026 и серийный номер Excel остаются вариантами. Окончания строк — CRLF для Windows и LF для Unix-инструментов. Четвертую настройку легко пропустить: по умолчанию экспортируется только первый лист, и для книги со второй вкладкой нужно выбрать «Все листы» — тогда придет ZIP, по одному CSV на каждый лист.

Инструменты из этой статьи

Читать дальше