CSV空白、空字符串和NULL是一回事吗：导入前先约定缺失值

开始前先确认

RFC 4180描述 CSV 的记录、字段和引号语法，并没有规定一个通用的数据库 NULL 类型。因此，“这是合法 CSV”与“它保留了缺失值含义”是两项不同检查。

先把四种输入分开看

假设要导入一个可为空的备注字段，下面是一份专门用于核对的样例。它有一行表头、四行数据；第四行的引号内是一个普通半角空格。

case_id,remark
case_a,
case_b,""
case_c,NULL
case_d," "

这四行不是对所有导入器的预期结果。它们的作用是让接收方明确回答每一行如何解释，再通过小样本核对答案。尤其不要把 NULL 直接认定为数据库空值，也不要认为加上引号就一定能阻止接收系统进一步转换。

检查前先按 CSV 表头与字段结构核对确认 remark 映射到了目标备注字段。列映射错误时，即使缺失值规则正确，导入结果也可能落到错误的位置。

引号能区分到哪一步，取决于读写方式

以 Python 标准库为例，默认 csv.reader 会把上述未加引号的空字段和引号空串都读为空字符串；这说明原文件中写法不同，不保证解析后的值仍有区别。

Python 3.14 的文档还列出显式模式：QUOTE_NOTNULL 可将未加引号的空字段读成 None，把引号空串保留为空字符串；QUOTE_STRINGS 也有空字段处理规则，但其他未加引号的字段按其数字转换规则处理，不能视为通用文本读取模式。使用时必须核对实际 Python 版本和读写参数。Python csv 官方文档说明了这些模式的边界。

这只是特定工具的行为，不是 CSV 文件自带的保证。即使发送方能写出区别，接收方也必须按约定读取；只改发送端的引号策略，不能证明整条交付链路保留了原意。

把接收规则写成一张可执行的约定表

下面是假设的“备注字段”交付约定，用于展示应写清哪些事项，不是推荐所有业务采用同一规则。

若接收系统做不到上述区分，就应调整交付设计。例如，在双方支持的前提下增加一个明确的状态列，分别记录“未知”和“已确认无内容”；不要自行创造一个特殊字符串，然后假定所有导入工具都认识它。

同样要检查表头是否重复。若两列都叫 remark，先按 CSV 重复列名处理明确字段身份，再讨论空值含义，避免把列覆盖或映射问题误判成空值转换。

用小样本检查完整导入过程

1. 保留原文件，在副本中准备上述四行，并记录编码、分隔符、引号和空值识别设置。
2. 对照接收系统说明确认映射，先做预览或在允许的小样本环境导入。
3. 按 case_id 逐行核对实际保存值；如果界面都显示空白，使用系统支持的详情、查询或导出方式进一步区分。
4. 若业务需要再次导出，将结果读回并与约定比较。只有预览正确，不足以说明往返后仍保留区别。
5. 样本符合约定后，再用相同设置处理正式文件，并抽查同类记录。

需要核对中文备注时，额外加入一条正常中文记录。乱码与缺失值转换是不同问题，可结合 CSV 中文编码排查定位，避免用清空字段的方式掩盖字符问题。

不要在原件中把所有空白替换成 NULL，也不要批量删除引号或清理空格。这些修改可能把原本不同的状态合并。交付记录至少保留原文件、字段约定、导入设置和四行样本的核对结果；今后更换接收系统时，重新检查这四行即可快速发现规则变化。