CSV: как проверить, что импорт не изменил нули, даты и длинные коды

Чтобы открыть CSV без потери исходных значений, сохраните нетронутый файл, настройте импорт до преобразования столбцов и сравните результат с оригиналом. Особенно уязвимы коды с нулями, длинные идентификаторы, даты и обозначения пропусков. Аккуратный вид таблицы ещё не означает, что данные целы: потерянные цифры не возвращаются после выбора текстового формата.

Если файл уже открыли двойным щелчком

Не сохраняйте результат поверх полученной выгрузки. Закройте таблицу без записи изменений либо сохраните рабочую копию под другим именем. Затем найдите исходный CSV: повторите выгрузку из системы, возьмите исходное вложение или используйте сохранённую копию. Открытие и сохранение — разные события: пока оригинал не перезаписан, ошибочный импорт можно выполнить заново.

Если осталась только таблица с числовым кодом, сначала установите, какая информация действительно потеряна. Отображение 1,23E+19 может скрывать полное значение или сопровождать уже произошедшее округление. Увеличение ширины столбца исправит только отображение. Оно не восстановит последние цифры, которые программа отбросила. Добавление нулей слева тоже требует знания исходной длины: из значения 123 нельзя самостоятельно выбрать между 0123 и 000123.

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

Что именно должно сохраниться

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

Для идентификатора 000123 обычно нужна точная строка из шести символов. Для измерения 1,25 может требоваться числовое значение с десятичной запятой при чтении. Для записи 01/02/2026 необходим известный порядок частей даты: это может быть первое февраля или второе января. Одинаковое правило преобразования всех трёх столбцов не решает эти разные задачи.

До импорта составьте короткий словарь: название поля, его смысл, исходный формат, разрешённые пропуски и ожидаемый тип после чтения. Для кода укажите, значимы ли регистр, пробелы, плюс и начальные нули; для измерения — единицу; для даты — порядок частей и наличие времени. Если смысл строк и ключ ещё не определён, начните с разбора единицы наблюдения и полей таблицы. Импорт не должен незаметно принимать эти решения за вас.

Выберите несколько тревожных значений заранее

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

• 000123: после импорта должно остаться именно шесть символов, если это код.
• 12345678901234567890: сравнивайте все двадцать цифр, не только начало.
• +007 и 3E10: знак и буква могут быть частью обозначения, а не инструкцией получить число.
• NA, NULL, N/A, пустая строка и 0: заранее решите, какие из них означают отсутствие данных.
• Пробелы перед и после АБ-007, неразрывный пробел внутри кода, кавычки и перенос строки: сохраняйте их, пока словарь не разрешает преобразование.

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

Excel: задайте тип до потери цифр

Для управляемого чтения используйте импорт текстового или CSV-файла, а не полагайтесь на двойной щелчок. В версиях с Power Query путь начинается с получения данных из текстового/CSV-файла. В окне предварительного просмотра проверьте источник кодировки и разделитель, затем откройте преобразование данных. Названия пунктов различаются между версиями Excel и платформами; ниже описана логика по документации, а не универсальный снимок интерфейса.

Столбцам идентификаторов задайте тип «Текст» до преобразования их в числа. В Power Query посмотрите список применённых шагов: автоматически добавленный шаг изменения типов мог сработать раньше вашего действия. Если сначала длинный код стал неточным числом, а потом строкой, выбор «Текст» на последнем шаге не вернёт исходное содержимое. Вернитесь к данным до неверного преобразования и настройте затронутый столбец заново.

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

В документации Excel указана точность чисел в пятнадцать значащих цифр. Поэтому длинные номера документов, товаров или счетов следует рассматривать как текстовые идентификаторы, если над ними не нужна арифметика. Это не ограничение длины текста в ячейке и не то же самое, что предел точного целого у двоичного числа в другой программе. Не переносите числовой порог одного движка на другой.

В Microsoft 365 и Excel 2024 доступны настройки части автоматических преобразований, включая ведущие нули и некоторые длинные числа. Они не являются общим выключателем всех интерпретаций и не заменяют проверку шагов Power Query. В старом мастере импорта отдельно задаются разделители, ограничитель текста и формат столбцов. Если вашей версии не хватает нужного контроля, используйте поддерживаемый путь импорта, а не обещание, что одни кавычки сохранят тип.

Разделитель, кавычки и кодировка решают разные проблемы

Если вся строка оказалась в одной ячейке, сначала проверьте разделитель. Если вместо русских букв появились неверные символы, проверьте кодировку. Если число столбцов скачет между записями, изучите кавычки, переносы внутри полей и возможные служебные строки перед заголовком. Одна настройка не исправляет все эти симптомы. Не меняйте запятые на точки по всему файлу: запятая может быть разделителем, десятичным знаком или частью обычного текста.

UTF-8 BOM — сигнатура в начале файла, а не описание типов столбцов. Она может помочь конкретному приложению распознать кодировку, но не защищает длинный код от преобразования в число. В нашем примере Python обычное декодирование UTF-8 оставило сигнатуру перед первым полем; чтение с utf-8-sig обработало этот образец правильно. Из этого не следует, что любой неизвестный файл нужно объявить UTF-8 или снабдить BOM.

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

Даже строгий разбор кавычек не гарантирует одинаковой ширины записей. Python csv.reader с strict=True отверг незакрытую кавычку, но разобрал строки с одним и тремя полями при двух полях заголовка. Для такой выгрузки нужна отдельная проверка количества и назначения столбцов. Пропуск «плохих» строк, обрезание лишних полей или заполнение недостающих значений следует считать изменением данных, а не технически нейтральным ремонтом.

Локаль и пустота — часть договора об импорте

Строку 1,25 нельзя интерпретировать без знания десятичного разделителя. Для даты 01/02/2026 нужен порядок дня и месяца. В нашем опыте явное чтение D/M/Y дало 2026-02-01, а M/D/Y — 2026-01-02. Оба результата технически допустимы, но верным для конкретной выгрузки будет только согласованный с её автором. По одному значению в начале месяца угадать этот договор нельзя.

У Power Query локаль может задаваться при преобразовании типа; она не сводится к языку подписей интерфейса. Проверьте также смысл временного поля: календарная дата, местное время и момент со смещением часового пояса не равнозначны. Не добавляйте часовой пояс к дате только потому, что приложение умеет его хранить. Если в одном столбце смешаны форматы, сохраните исходные строки и разберите неоднородность до общего преобразования.

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

Что показала проверка Python и pandas

Мы проверили небольшой искусственный набор на Python 3.12.14 и pandas 3.0.1. В нём пять записей, шесть столбцов, длинные коды, текстовые метки пропусков, кириллица, значимые пробелы и перенос внутри поля. Это воспроизводимый опыт конкретных парсеров. Отдельная проверка Calc описана ниже. Excel, Power Query и Google Sheets не запускались; их поведение здесь разобрано по документации, а не установлено этим опытом.

Параметр dtype=str у pandas сам по себе не отменил распознавание пропусков. В столбце меток NA, пустота, NULL и N/A стали отсутствующими значениями, а 0 остался строкой. Вариант с dtype=str и keep_default_na=False без дополнительных na_values сохранил исходные строки образца. Если в вашем коде заданы собственные na_values, политика уже другая. Проверяйте сочетание параметров, а не один знакомый флаг.

В отдельном опыте on_bad_lines='skip' вернул две записи из трёх, исключив строку с лишним полем. Обычный режим сообщил ParserError. Отсутствие исключения в режиме пропуска не означает полный импорт: нужно сравнить ожидаемые ключи и объяснить каждое исключение. Нельзя сначала отбросить проблемные записи, а затем использовать уменьшенный набор как единственный эталон количества строк.

Для файла с переносом внутри поля важен и режим чтения текста. В нашем опыте newline=None заменил внутренний CRLF на LF; newline='' сохранил исходную последовательность. Такая нормализация иногда допустима, но это отдельное решение. Аналогично, errors='replace' при декодировании подставил символ замены вместо неверного байта, тогда как строгий режим сообщил ошибку. Результат, который удалось прочитать любой ценой, не обязательно сохранил исходные данные.

Переход длинного кода через число тоже оказался необратимым: строка 9007199254740993 после преобразования в Python float и обратного вывода стала 9007199254740992. Преобразование той же строки в Python int сохранило цифры, но всё равно изменило её тип. Этот пример демонстрирует конкретную двоичную арифметику; он не является испытанием числового формата Excel и не даёт разрешения переводить любые идентификаторы в целые числа.

Сравнивайте записи, а не только общий итог

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

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

Число строк и сумма полезны как дополнительные сигналы. Но пусть у r1 было 10, у r2 — 20. После перестановки значений между ключами останутся две строки и сумма 30, хотя обе записи изменились. Проверка длины кода также пропустит замену одной цифры другой. Контроль должен соответствовать возможной ошибке: агрегат находит некоторые потери, точное сопоставление — изменения конкретных полей.

В Excel для точного текстового сравнения можно использовать СОВПАД, а ДЛСТР — как дополнительный контроль длины. Эти функции не создают правильный эталон и не чинят неверный импорт. Не применяйте СЖПРОБЕЛЫ или ПЕЧСИМВ автоматически перед сравнением: так можно удалить именно то различие, которое нужно обнаружить. Сначала зафиксируйте расхождение, затем решайте, является ли оно допустимой нормализацией.

Повторный экспорт — ещё одна граница преобразования

Сохранение в CSV не сохраняет всю книгу с её оформлением, объектами и несколькими листами. Уточните, какой лист или диапазон экспортируется и что означает текст каждой ячейки после преобразования. Экспорт под новым именем оставляет возможность сравнить результат с исходником. Не удаляйте первый файл, пока не подтверждён следующий шаг обмена: хорошо прочитанная таблица ещё может быть неверно записана обратно.

В pandas to_csv по умолчанию добавляет индекс. Для нашего шестиколоночного образца index=False исключил лишний столбец, и повторный разбор вернул ожидаемые поля. Если индекс несёт смысловой ключ, его нельзя просто выбросить: сначала решите, где он должен оказаться в схеме. Отдельно задайте подходящие получателю разделитель, кодировку и представление пропусков.

Стандартный Python csv.writer записал None и пустую строку как два одинаково пустых поля. После чтения отличить их было уже нельзя. У других систем могут быть специальные соглашения о кавычках и NULL; переносить их на любой CSV-парсер нельзя. Если для задачи эти состояния различаются, нужен явный согласованный маркер либо другой способ обмена, который сохраняет требуемую схему.

После повторной записи сравнивайте и файл, и разобранные данные в нужном смысле. В нашем опыте смена способа расстановки кавычек изменила SHA-256, но все ожидаемые ячейки остались прежними. Разные хеши означают разные байты, а не автоматически испорченные значения. Совпадающий с надёжно сохранённым оригиналом хеш полезен для контроля самого файла, но не подтверждает правильность выбранной интерпретации его содержимого.

Что показал отдельный опыт Calc

В отдельном опыте использовали LibreOffice Calc 26.8.0.3 на Windows: шесть вариантов импорта и обратного экспорта того же искусственного CSV с пятью записями и шестью полями. Файл был в UTF-8, все поля заключены в кавычки, язык числового разбора — русский. Запуски шли через консольный фильтр Calc с явными параметрами и отдельным профилем. Сравнивали содержимое записанных файлов. Действия в графическом интерфейсе не проверялись.

При текстовом типе всех столбцов сохранились ведущие нули, длинные коды, метки NA/NULL/N/A, значащие пробелы и кириллица. Но перенос CRLF внутри одного поля после этого цикла стал LF. Поэтому полного равенства всех исходных строк не было даже в текстовом режиме. Если различие переносов существенно для получателя, такой результат нельзя принять без отдельного решения о допустимой нормализации. Проверка варианта UTF-8 с BOM дала тот же результат по значениям.

В контрольном режиме Standard отключили распознавание специальных чисел и научной записи, но это не сделало столбцы текстовыми. После импорта и экспорта 000123 стало 123, а +007 — 7; длинные коды вышли в научной записи. Флаг распознавания научной записи управляет чтением значений вроде 3E10, а не форматом вывода длинного числа. При отдельном включении распознавания научной записи исходное 3E10 превратилось в 30000000000. Это наблюдения всей цепочки чтения и записи в указанных условиях, а не доказательство того, что любое расхождение возникает только при импорте.

Настройка «поля в кавычках — текст» также сохранила коды нашего полностью закавыченного файла, но не исходный CRLF внутри поля. Это действие конкретной настройки Calc: сами CSV-кавычки не задают тип данных для всех программ. В смешанном файле незаключённые в кавычки значения потребуют отдельной проверки. Если повторяете работу через интерфейс или с ранее сохранёнными настройками, сверяйте фактические типы столбцов, локаль и контрольные значения до основного импорта.

Содержимое чужого CSV может выглядеть как формула. Кавычки, необходимые для структуры CSV, не являются универсальной защитой от её вычисления табличным редактором. В Python-образце строка =1+1 сравнивалась как текст. В описанных запусках Calc вычисление формул при импорте явно отключили, и эта строка сохранилась в итоговом CSV. Это не проверка безопасности открытия произвольного чужого файла в Excel или Calc. Не разрешайте внешние подключения ради просмотра выгрузки и не считайте заранее неизвестное содержимое доверенным.

Когда импорт можно принять

Остановитесь и вернитесь к настройкам или источнику, если пропали записи, изменилась ширина строк, появились символы замены, длинный код округлился или смысл даты остался неоднозначным. Сохраните исходный файл и небольшой пример расхождения. Запишите приложение, версию, параметры чтения, затронутое поле и ожидаемую строку. Такой отчёт позволяет повторить проблему; сообщение «Excel что-то испортил» не показывает, на каком этапе это произошло.

Импорт принят, когда заданная схема соблюдена, ожидаемые записи присутствуют, критичные строки совпадают с независимым эталоном, а преобразования чисел, дат и пропусков объяснены. Если нужен обратный экспорт, проверьте и его. После этого можно переходить к аудиту пропусков, дублей и невозможных значений: сохранность при переносе и корректность самих данных — две разные проверки.