CSV 缺少的標準：RFC 4180 涵蓋的內容以及未解決的內容

誰的 CSV 是正確的？ — 同一個表格的兩個匯出，一個帶分號，一個有逗號，都稱為 CSV

ToolAcre 可以從 JSON 發出逗號、分號或製表符分隔的輸出。它不會讀取兩個相互競爭的 CSV 匯出或宣告其中之一正確。 CSV 在這裡是只寫的，因此分隔符號選擇是一個明確的輸出選項，而不是一個檢測演演算法。

這種區別可以防止常見的事實失誤。可以編寫分號的介面尚未證明它可以識別未知檔案中的分號、處理區域設定小數或解釋標頭。這些是故意排除的單獨輸入責任。

兩個分隔符號選擇是輸出選項，而不是該面板讀取任一檔案的證據

此儲存庫不包含早期電子表格或資料庫歷史的來源，因此本文沒有發明年表。它從目前編寫器及其測試開始：記錄、欄位、分隔符號、CRLF 終止和引號轉義。

稍後可以透過審查的來源添加歷史背景。轉換器的實作是產品今天所寫內容的證據，而不是約定何時首次出現或供應商為何出現分歧的證據。

RFC 4180 之前的 CSV 歷史記錄位於儲存庫之外的證據

包含分隔符號、雙引號、回車符或換行符的欄位用雙引號括起來，並每個嵌入的引號都是雙引號。前導或尾隨空格也被引用，以防止常見的電子表格修剪。記錄以 CRLF 結尾，檔案終止。

這些行為遵循在儲存庫中測試的 RFC 4180 樣式規則。本文避免聲稱普遍合規，因為作者也支援替代分隔符，並在狹義語法之外添加了安全處理。

作者使用 RFC 4180 樣式引用和 CRLF，但未宣告完全符合標準

CSV 單元不保留 JSON 類型。 Null 和空字串都變成空單元格，而布林值和數字則變成文字表示。 UTF-8 內容被傳遞，並可以為需要它的消費者添加可選的 BOM 前綴。

未嵌入區域設定解釋。分號分隔符號可以與小數逗號共存，但編寫器不會按區域設定重新格式化數字或對日期類型進行編碼。接收應用程式仍然決定如何解釋每個欄位。

編碼、類型和區域設定邊界在本文中保持明確

實現的變體是逗號、分號和製表符，以及可選的 BOM。以 `=`、`+`、`-`、`@`、製表符或回車符開頭的類似公式的文字預設以撇號為前綴，因此電子表格將其視為文字。使用者可以停用該保護並收到警告。

此編寫器中沒有 `sep=` 提示或反斜線轉義模式。將這些稱為已發貨選項是錯誤的。嵌入的引號使用加倍，正如測試斷言的那樣。

觀察到的電子表格變化僅限於此處實施的選項和保護

路線中的每個假設都從解析的 JSON 開始：哪個值提供行，嵌套如何展平為點列以及哪些鍵成為標題。不對傳入的 CSV 方言做出任何假設，因為傳入的 CSV 被拒絕。

此更正顛倒了工作簿所要求的方向。 CSV 到 JSON 工作流程必須在另一個工具中選擇分隔符號、引號、標題和儲存格類型。 ToolAcre 的錯誤解釋了這種拒絕，而不是靜靜地猜測。

轉換假設只適用於 JSON 到 CSV，因為 CSV 輸入被拒絕

修復格式錯誤的 CSV 超出了範圍。斷引號、混合編碼和意外分隔符號需要 CSV Cleaner 或其他具有明確診斷功能的解析器。語法轉換器接收嚴格的 JSON，而不是損壞的 CSV 文字。

當巢狀樹建立不明確的點列或超過 2,000 列時，輸出仍然可能不適合目標。警告和上限會在下載前暴露這些表格形狀的故障。

重點： CSV 是一種約定，而不是一種格式 - 以及語法轉換器面板如何將格式良好的檔案轉換為 JSON 您可以檢查

將 CSV 視為其選擇必須可見的約定。 ToolAcre 記錄其輸出選擇並拒絕未指定的反向操作。這比使用一個按鈕完成兩項完全不同的工作更可靠。

檢查接收系統中的分隔符號、引號、CRLF、BOM 和公式轉義。如果需要輸入解析，請使用詢問的工具，而不是將編寫者的約定轉移到未知檔案上。

實際驗收檢查會在目標使用者中開啟產生的檔案，並檢查原始位元組或文字。消費者視圖擷取顯示和匯入問題；原始視圖確認分隔符號、雙引號、CRLF 和可選的 BOM，無需重新解釋電子表格。將類似公式的字串測試為惰性文字，將負數測試為數字。這些配對檢查驗證了編寫者的實際合同，而不聲稱每個程式都相同地實現 CSV 約定。