資料與電子表格 · CSV 更清理

RFC 4180 解釋：最接近的 CSV 必須有一個正式標準

2026年9月19日 · 背景

csv rfc-4180 資料格式

CSV 在有人把它寫下來之前已经存在了几十年。這篇文章介紹了 RFC 4180，它實際上說明了有關分隔符號、引用、行結尾和標題的內容，以及為什麼現實世界的檔案仍然忽略它。

兩個「有效」的 CSV 檔案，沒有一個解析器可以正確讀取 - 為什麼該格式在沒有標準的情況下增長了數十年

兩個檔案都可以帶有 .csv 副檔名，其中一個檔案使用分號，另一個檔案使用製表符，每個檔案套用不同的引號。在標點符號成為結構之前，解析器必須了解一種方言。 ToolAcre 從四個候選人開始，並對解析的樣本形狀進行評分，而不是信任擴展。

這種彈性解釋了為什麼「有效的 CSV」通常是不完整的描述。清理器可以接受常見的偏差，然後序列化一致的結果。它的行為是由配置和測試定義的，這比假設每個生產者都完美地遵循一份備忘錄提供了更有用的合約。

儲存庫重複將 RFC 4180 命名為輸出約定，但它不是有關備忘錄日期或法律狀態的歷史宣告的來源。因此，本文將聚焦於實作所體現的規則：記錄結尾、引用、標頭寬度和分隔符號處理。

當外部標準歷史很重要時，請單獨引用主要出版物。對於使用 ToolAcre，相關證據是本地的：程式碼預設為 CRLF、引用結構字元、雙引號並報告寬度與標題不同的行。

配置的目標描述逗號分隔的輸出、CRLF 行結尾、可選的標頭概念和矩形行。在發貨路線上，第一行在實踐中不是可選的：它始終被用作標題。無標頭檔案將失去該角色的第一個記錄。

參差不齊的輸入不會導致拒絕。短行用空白儲存格填滿；長行保留額外內容，並都收到行編號的警告。序列化器寫入每個保留的行，因此「乾淨的輸出」並不意味著程式猜測如何修復結構分歧。

當欄位包含所選分隔符號、引號或記錄結束字元時，必須用引號引起來。 ToolAcre 還額外引用前導空格或尾隨空格，因此另一個解析器不會默默地修剪它們。在引號的欄位內，每個文字雙引號變成兩個雙引號。

Quote 每個欄位開關要求統一的樣式；否則輸出最少被引用。冗餘的來源引號可能會消失，而解析的值保持相等。這種標準化是預期的，這也是測試比較恢復的表以及所選範例的精確輸出的原因。

磁碟上的檔案很少會附加媒體類型參數。 ToolAcre 不會從所選檔案讀取 `header` 或 `charset` 參數。它依賴其路由契約：UTF-8 文字、第一行標題和支援的分隔符號偵測或手動選擇。

可選的 BOM 匯出開關在第一個標頭之前寫入 U+FEFF。這可能有助於電子表格識別 UTF-8，但配置警告它可能會破壞嚴格的腳本或資料庫導入，因為標記在未剝離時會連接名字。除非消費者需要，否則將其保留。

實際輸入可以使用分號、製表符或垂直線、LF 或單獨的 CR、不均勻的行和前導 UTF-8 BOM。解析器有意接受所有這些行結尾和分隔符號候選。它不會默默地「容忍」參差不齊的行；它保留資料並附加警告。

未關閉的報價是另一個已接受但報告的條件。起始引號之後的所有內容都成為一個欄位，因為不存在明確的結束邊界。在信任匯出之前更正該來源。許可解析是一種保存策略，而不是證明輸入符合要求。

這裡沒有規則給出單元格數字、布林或空白類型。解析器傳回字串，JSON 轉換器將它們保留為字串。語意約定必須由發送者和接收者達成一致，包括是否缺少空白文字以及數字序列是否為標識符。

公式註入安全性是位於 CSV 語法之上的匯出策略。啟用後，除了普通數字形式之外，有風險的前導字元都會收到撇號。為了電子表格的安全故意改變數值；它不是引號轉義或通用類型系統的一部分。

即使源方言發生變化，也要爭取可預測的輸出。解析並解決警告後，ToolAcre 會發出 CRLF 記錄和標準雙引號轉義。如果偵測到的分隔符號仍然是分號或製表符，則下載會保留該分隔符號而不是始終強制使用逗號。

當接收合約需要逗號分隔輸出時，手動選擇逗號，並檢查控件，因為它顯示實際使用的分隔符號。一致性來自明確選擇加上經過審查的行形狀，而不是僅來自 CSV 擴充。