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，也不要批量刪除引號或清理空格。這些修改可能把原本不同的狀態合併。交付記錄至少保留原文件、字段約定、導入設置和四行樣本的核對結果；今後更換接收系統時，重新檢查這四行即可快速發現規則變化。