Python csv.reader strict 模式怎样定位格式错误

CSV 文件一旦出现未闭合引号、错误转义或混用分隔符，最怕的不是程序立刻报错，而是导入脚本把异常输入当成普通字段继续处理。Python 标准库的 csv.reader 可以通过方言参数开启严格解析：当 strict=True 检测到坏 CSV 时抛出 csv.Error，再结合 reader.line_num 记录已经读取的物理行数，就能把问题留在导入边界内。

官方文档：https://docs.python.org/3/library/csv.html

生产导入建议把 strict 当作输入格式防线，而不是业务字段校验器：先稳定打开文件和方言，再捕获 csv.Error 写入文件名、物理行号与错误信息；同一个 reader 抛错后不要盲目跳过并继续复用，应该隔离原始文件或进入修复流程。

strict=True 解决的是哪一层问题

csv 模块面对的是带分隔符、引号和转义规则的文本格式。不同导出程序对这些规则的实现并不总是一致，所以默认方言可能对部分不规范内容保持兼容。strict=True 的作用，是让方言在检测到坏 CSV 输入时抛出 csv.Error，把解析问题显式暴露出来。

它不负责判断“订单号是否为空”“金额能否转换为整数”或“列数是否符合业务约定”。这些属于字段和业务层校验。把两层分开，日志里才能看出究竟是 CSV 语法坏了，还是一行内容本身不满足业务规则。

先固定文本打开方式和方言

定位格式错误前，先把编码、换行和解析方言固定下来。文本文件建议使用 newline='' 交给 csv 模块处理换行；分隔符、引用符和转义符要按照上游文件约定填写，不要在遇到异常时随意改成另一个方言。

import csv

# 统一定义本次导入使用的 CSV 规则，避免默认方言掩盖坏输入。
strict_dialect = csv.excel()
strict_dialect.strict = True

with open("orders.csv", "r", encoding="utf-8", newline="") as source:
    # reader 负责 CSV 语法解析，业务字段校验放在读取结果之后。
    reader = csv.reader(source, dialect=strict_dialect)
    for row in reader:
        # 这里只处理已经通过 CSV 语法解析的字段列表。
        print(row)

也可以把方言属性写成自定义 Dialect，关键是让 strict 和分隔符约定成为显式配置。不要把 csv.Sniffer 的猜测结果直接当成生产配置；自动识别可以用于辅助提示，但最终仍应由文件协议决定。

捕获 csv.Error 并记录 line_num

异常处理要围绕“哪个文件、读到哪一段、为什么失败”展开。reader.line_num 表示 reader 已读取的物理行数；CSV 记录可能跨越多行，所以它不是业务记录编号，但足以帮助你在原始文件中缩小排查范围。

import csv
import logging

logging.basicConfig(level=logging.INFO, format="%(levelname)s %(message)s")

def read_strict_csv(path: str) -> list[list[str]]:
    """严格读取 CSV；遇到语法错误时保留定位信息并终止当前 reader。"""
    rows: list[list[str]] = []
    try:
        with open(path, "r", encoding="utf-8", newline="") as source:
            # strict=True 让坏引号、坏转义等解析问题转成 csv.Error。
            dialect = csv.excel()
            dialect.strict = True
            reader = csv.reader(source, dialect=dialect)
            for row in reader:
                # 语法已经通过后，再把字段交给业务层检查。
                rows.append(row)
    except csv.Error as exc:
        # line_num 是物理行数；记录它比只记录异常文本更容易回到原文件。
        line_num = locals().get("reader").line_num if "reader" in locals() else 0
        logging.error("CSV格式错误 file=%s line_num=%s error=%s", path, line_num, exc)
        raise
    return rows

这里选择重新抛出异常，是为了让上层任务知道导入没有完成。若只记录日志后返回空列表，调用方很容易把“解析失败”误判成“文件没有数据”。另外，reader 抛出 csv.Error 后不要简单地在同一个迭代器上继续下一行；先保存日志并关闭当前文件，再决定如何修复或隔离。

坏文件应该隔离，还是回到兼容解析

处理策略取决于文件来源和数据价值。来自固定上游接口的文件，应该优先把原始文件隔离，交给上游修正格式；来自人工导出的临时文件，可以在保留原件的前提下修复引号或分隔符，再重新导入。只有明确知道上游存在合法但非标准的方言时，才考虑放宽 strict，并把这种兼容写进协议。

批量导入前做一个最小样本检查

正式任务开始前，可以用一份包含正常引号、跨行字段和故意损坏引号的小样本，检查方言是否与上游协议一致。这个检查的目标是确认“坏输入会失败并留下定位信息”，而不是把本地运行结果写成文章结论。

import csv
from io import StringIO

sample = "name,remark\nAlice,ok\nBob,\"missing quote\n"
try:
    # StringIO 只承载测试文本，便于检查异常边界，不读取线上文件。
    dialect = csv.excel()
    dialect.strict = True
    reader = csv.reader(StringIO(sample), dialect=dialect)
    list(reader)
except csv.Error as exc:
    # 预期的坏样本应进入这里，line_num 用于确认定位日志字段可用。
    print(f"CSV格式错误，物理行号={reader.line_num}，原因={exc}")

如果这类小样本没有按预期抛错，先检查方言属性和输入文本，再检查 Python 版本与上游生成器的约定。不要直接把 strict 当作“所有 CSV 问题的自动修复器”；它的价值是把解析边界变得可观察。

常见问题

strict=True 会检查每一列的业务类型吗？

不会。它针对 CSV 解析规则；金额、日期、必填字段和列数仍需由业务代码检查。

line_num 是第几条业务记录吗？

不是。它记录物理行数，而一条 CSV 记录可能跨越多行，因此日志字段最好明确写成 line_num，不要命名为 record_id。

捕获 csv.Error 后能跳过当前行继续读吗？

不建议把这个假设写进生产逻辑。异常发生后先保存文件和定位信息，关闭当前 reader，再根据协议修复或隔离原始输入。

小结

要定位 Python CSV 格式错误，核心不是增加更多打印，而是把解析职责固定下来：用明确的方言开启 strict=True，捕获 csv.Error，记录文件名与 reader.line_num，再由上层决定隔离、修复或兼容。这样既能避免坏文件悄悄进入业务层，也不会把字段校验和 CSV 语法混成一个难以维护的异常处理块。