JSON 轉 CSV 轉換器可在瀏覽器分頁中接受最多包含 10,000 個物件的 JSON 陣列，並將其轉換成可下載的逗號分隔檔案 converted.csv。每一個步驟——JSON 解析、綱要探索、CSV 跳脫、預覽渲染，以及 Blob URL 建立——都在本機完成，因此原始資料絕不會被上傳。輸出遵循常見的 RFC 4180 規則:欄位以逗號分隔，記錄以 CRLF 分隔，任何包含逗號、雙引號、CR 或 LF 的儲存格都會以雙引號包裹，內部的雙引號則加倍。轉換器將輸入上限設為 1,000,000 個 JavaScript 字元，綱要上限為 200 個欄位，產生的 CSV 上限為 5,000,000 個字元;超過任何一項限制都會回傳錯誤，且不會產生縮短的檔案。巢狀物件與陣列不會被攤平為帶點的欄位名稱——它們會以精簡 JSON 形式序列化至單一 CSV 儲存格中，然後加上引號。在這個語境中，「大量」一詞指的是一組特定的限制條件，而不是會逐檔迴圈的指令碼。
「大量」在 JSON to CSV 工具中的意義
這個工具是單一分頁轉換器，帶有四項明確的數值限制，用來決定您的輸入會成功轉換或回傳錯誤。只要超過其中任何一項，就會顯示訊息，並且不會寫入任何不完整的 CSV。
| 界限 | 上限 | 超過時的行為 |
|---|---|---|
| 輸入大小 | 1,000,000 個 JavaScript 字元 | 錯誤，不會產生 CSV |
| 陣列中的列數 | 10,000 個物件 | 錯誤，不會產生 CSV |
| 探索到的綱要 | 200 個欄位 | 錯誤，不會產生 CSV |
| 產生的 CSV | 5,000,000 個字元 | 錯誤，不會產生 CSV |
每一項限制的失敗方式都相同:不會產生縮短的檔案、不會悄悄截斷、也不會上傳。文字區域仍會顯示超過上限的輸入，並在計數器中標示出來，而不是在您輸入時就修剪字元。編輯 JSON 會在下次嘗試之前清除先前的輸出、錯誤與下載網址。這種確定性的行為，正是讓大量轉換能夠安心地推向上限的原因。
將大型 JSON 陣列轉換為 CSV
- 將一個非空、每個元素都是物件的 JSON 陣列貼到轉換器中——例如 [{"name":"Alice","age":30},{"name":"Bob","age":31}]。確認可見的計數器保持在 1,000,000 字元上限以下。
- 觸發轉換。瀏覽器會在本機解析 JSON，從第一筆到最後一筆掃描記錄，並在每個欄位首次出現時新增一個欄位。遺漏的欄位與明確的 null 值會成為空白儲存格。
- 檢視與 Blob 內容完全一致的預覽。確認欄位順序、巢狀物件與陣列以精簡 JSON 形式呈現在單一儲存格中的方式，以及回報有多少字串儲存格為了公式保護而加上前置單引號的摘要。
- 直接下載 converted.csv。MIME 類型為 text/csv;charset=utf-8。在接收的應用程式中選擇 UTF-8 逗號分隔匯入設定，不要依賴語系自動偵測。
當記錄變大時會有什麼改變
在小規模下，引號處理與欄位探索幾乎感覺不到。一旦超過數百列，以下四種行為就開始變得重要。
欄位探索與順序有關。第一筆記錄會定義最左側的欄位。之後每筆記錄在首次引入新欄位時，可以將其新增到右側，但先前欄位的相對順序是固定的。若第 1 列帶有 ["name","age"]，而第 2 列新增 "role"，綱要就會變成 name,age,role，即使 role 只出現在第 2 列。若第 1 列存在的欄位在第 50 列中遺漏，該列中就只會出現一個空白儲存格——不會產生錯誤，後續欄位也不會位移。
巢狀值保持巢狀。值為物件或陣列的欄位——例如 {"address":{"city":"Berlin","zip":"10115"}}——不會被拆成 address.city 與 address.zip。它會以精簡 JSON 形式序列化至單一 CSV 儲存格中。接著 CSV 跳脫會將內部的雙引號加倍，並因含有逗號而以雙引號包裹整個儲存格。需要原始結構的消費者必須將該儲存格解析為 JSON;攤平處理會發明出一套可能與真實欄位名稱衝突，或會遺失陣列結構的帶點命名慣例。
基本類型保持原樣。false、true，以及像 -42 這類數值屬於 JSON 型別的資料，並非攻擊者可控的公式字串，因此不會加上前置字元。-42 在 CSV 中仍然是 -42。只有以 =、+、-、@、tab、carriage return 或在開頭 BOM 或不斷行空格之後出現相同觸發字元的字串值——以及標頭——會在跳脫前加上前置單引號。
引號處理嚴格遵循 RFC 4180。只有當欄位包含逗號、雙引號、CR 或 LF 時，才會以雙引號包裹。在被引號包裹的欄位內，每個雙引號都會加倍。記錄之間以 CRLF 連接。空值保持空白。輸出刻意保持確定性——不修剪、不加 BOM、也不依語系更換分隔符號。
在儲存 CSV 之前先行檢視
預覽窗格會顯示 Blob 即將寫入的完整相同字串，因此在下載之前，可以同時檢查引號、公式前置字元、欄位順序與巢狀 JSON。以下三項檢查幾乎能抓出所有實際的大量轉換錯誤。
首先，檢視標頭列。若標頭順序錯誤，代表記錄順序也錯了——請在重新執行前先排序後再貼上。若某個標頭顯示有前置單引號，表示它是以公式觸發字元開頭;這個單引號是刻意的，可避免試算表程式將標頭當作公式處理。
其次，將預覽中的列數與來源陣列的列數進行比對。若不一致，代表某筆記錄被截斷、包含了不支援的形狀(基本類型列、陣列列或 null)，或在解析過程中被悄悄略過。轉換器會以明確訊息拒絕這些形狀，而不是自行猜測。
第三，掃描以雙引號開頭的儲存格。每個這類儲存格都包含嵌入的引號、逗號或換行——這是轉換器刻意加上引號的結果。若某個巢狀物件看起來被截斷，請開啟來源 JSON 確認結構完整，再假設是轉換器的問題。
安全地將 converted.csv 匯入試算表
取得 converted.csv 之後，下一個程式會決定如何解讀這個檔案。對大量匯入而言，有兩項設定特別重要。
編碼。轉換器輸出的格式為 text/csv;charset=utf-8，且不含 BOM。在 Excel 的「從文字/CSV」精靈中，請明確選擇 UTF-8。在 Google Sheets 中，匯入對話框通常會自動偵測為 UTF-8。若匯入後非 ASCII 字元顯示異常，表示編碼被當作 Windows-1252 處理;此時應以 UTF-8 重新匯入，而不是重新執行轉換器。若開發人員確實需要在其餘流程中偵測或移除 CSV 中殘留的 BOM，請參閱在不失資料的前提下移除 UTF-8 BOM 的指南。
分隔符號。請堅持使用逗號。轉換器不會根據瀏覽器語系更換分隔符號，因此檔案一律為以逗號分隔，並以 CRLF 作為記錄結尾。若試算表嘗試以分號分隔的格式匯入，這是語系端的預設，並非轉換器的行為。如需 CSV 的正式定義及其記載的欄位與記錄規則，請參閱國會圖書館的 CSV 說明。
轉換器內建的公式保護為預設行為，且沒有關閉的開關。此緩解措施能降低OWASP CSV Injection 指南中所提到的一項常見風險，但並非全面的安全保證。後續的應用程式可能會去除單引號，或重新解讀文字。在可執行公式、命令、連結或外部資料連線的軟體中開啟不受信任的匯出檔之前，請先加以檢視。對於單引號會造成問題的資料集——例如恰好以 = 開頭的數值 ID——請修正來源值，而不是停用保護;且只要型別與結構仍然重要，就請保留原始 JSON，因為 CSV 無法承載資料型別或巢狀綱要。