Как проверить CSV-файл в Python: разделитель, кодировка и число столбцов

Если CSV приходит из другой системы, главная ошибка — считать его «обычным текстом с точками с запятой» и сразу отправлять дальше. На практике ломаются три вещи: файл открывают не в той кодировке, строки режут через split(';') и не замечают, что одна запись стала шире или уже остальных. В результате данные теряются тихо: часть полей съезжает, лишний фрагмент пропадает, а источник ошибки находят уже после загрузки.

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

Как зафиксировать формат входного файла

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

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

• Кодировка: например, utf-8, если это согласовано с источником.
• Разделитель: ;, а не автоматический поиск.
• Кавычки: стандартные двойные, которые понимает модуль csv.
• Ширина строки: одинаковое число полей у заголовка и у каждой записи.

УЧЕБНЫЙ ПРИМЕР: файл, который нужно проверить

Возьмем условный файл с четырьмя столбцами: id, name, city, comment. В нем есть и точка с запятой внутри текстового поля, и внутренние кавычки, и одна строка с лишним полем. Такой пример хорош тем, что показывает сразу две типичные ловушки: нельзя разбирать CSV через обычное разбиение строки и нельзя считать файл корректным только потому, что он «открылся».

id;name;city;comment
1;Анна;Казань;"Сказала ""перезвоню"""
2;Борис;Пермь;"Ждет у склада; просит набрать заранее"
3;Вера;Тула;"Без комментариев";EXTRA
4;Глеб;Омск;"Подтвердил ""да"""

Здесь ожидаемая ширина строки — 4 поля. Вторая запись корректна, хотя внутри комментария есть точка с запятой: она находится в кавычках и не должна считаться разделителем. Первая и четвертая записи тоже корректны: внутренние кавычки переданы через удвоение. А вот третья запись уже проблемная, потому что содержит пятое поле EXTRA.

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

Разбор строк через csv.reader

Для CSV в Python здесь достаточно стандартной библиотеки. Важны три решения: открыть файл с newline='', явно указать encoding и передать в csv.reader нужный разделитель. Это избавляет от ручной обработки переводов строк и от ошибок, когда парсер получает уже искаженный текст.

import csv


def validate_csv(path, encoding="utf-8"):
    reader = None
    valid_rows = []
    problems = []

    try:
        with open(path, "r", encoding=encoding, newline="") as f:
            reader = csv.reader(f, delimiter=';', quotechar='"')

            try:
                header = next(reader)
            except StopIteration:
                return {
                    "header": None,
                    "rows": [],
                    "problems": [{"line": 1, "error": "empty file"}]
                }

            expected_count = len(header)
            if expected_count == 0:
                problems.append({
                    "line": 1,
                    "error": "empty header",
                    "expected": None,
                    "actual": 0,
                    "row": header,
                })

            for row in reader:
                if len(row) != expected_count:
                    problems.append({
                        "line": reader.line_num,
                        "error": "wrong column count",
                        "expected": expected_count,
                        "actual": len(row),
                        "row": row,
                    })
                    continue

                valid_rows.append(row)

    except UnicodeDecodeError as e:
        raise ValueError(f"Encoding error: {e}")
    except csv.Error as e:
        line = reader.line_num if reader is not None else "?"
        raise ValueError(f"CSV parse error on line {line}: {e}")

    records = [dict(zip(header, row)) for row in valid_rows]
    return {"header": header, "rows": records, "problems": problems}

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

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

Проверка ширины и отчет об ошибках

Проверка числа полей — это отдельный шаг, а не побочный эффект чтения. csv.reader корректно разберет синтаксис CSV, но не знает, сколько столбцов вы считаете правильным для своей схемы. Поэтому после каждой строки нужно сравнивать len(row) с ожидаемым числом полей, взятым из заголовка или заранее заданной структуры.

В учебном файле выше результат проверки будет таким: заголовок имеет ширину 4, корректных записей — 3, проблемных — 1. Проблема обнаружится на строке 4 файла, потому что там фактически 5 полей вместо 4. Это уже проверяемый результат: если запустить функцию на таком файле, в problems должна появиться одна запись с expected = 4 и actual = 5.

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

Что проверять перед передачей данных дальше

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

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

Если вам нужно быстро оценить собственный файл, ориентируйтесь на практический итог этого разбора: для учебного примера корректный результат проверки — 3 валидные строки, 1 строка с ошибкой ширины, номер проблемной строки 4. Если ваш код дает другой итог на тех же входных данных, значит, где-то не зафиксирован формат, неверно выбрана кодировка или проверка ширины срабатывает не в том месте.

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