CSV 轉 JSON
最後更新：2026年10月1日
把一張 CSV 表讀回 JSON 物件陣列。表頭列給出鍵，讀取時能理解 RFC 4180 的引號規則，型別辨識由你決定是否開啟——全部在瀏覽器中完成，表格不會離開本機。
這個轉換做了什麼
CSV 把欄名放在第一列，所以轉換是直接的對應：表頭儲存格成為屬性名，其後的每一列成為陣列裡的一個物件。表格
id,name
1,Ada
2,Grace會變成 [{"id":"1","name":"Ada"},{"id":"2","name":"Grace"}]。注意這些值都是字串——這是預設行為，下一節會說明原因。
表頭列就是結構定義
第一列被當作表頭，而不是資料。有兩種邊界情況會被處理，而不是留給你踩坑：
- 名稱重複——重複的表頭會被改成唯一，因此
a,a會變成a與a_2。沒有這一步，第二欄會悄悄覆蓋第一欄。 - 名稱為空——空的表頭儲存格依位置命名，
column 1、column 2，依此類推，這樣就不會有鍵是空字串。
型別辨識預設關閉——這是刻意為之
CSV 沒有型別。每個儲存格都是文字，檔案本身也無法區分一個數字和一個恰好是數字的編碼。所以辨識預設關閉：關閉時，所有值都保持字串，這是對檔案的忠實解讀。
開啟後，只轉換沒有歧義的值。當一個值能寫成 JSON 數字時——可選的負號、數字、可選的小數部分與可選的指數——才當作數字；true、false、null 會被辨識為它們本身。關鍵在於，帶前導零的值不會被轉換，因為 007 與 02139 幾乎總是識別碼：郵遞區號、電話號碼、帳號、商品 SKU。籠統地「變成一個數字」會把 007 悄悄變成 7 並損壞資料，而這條規則不會。
帶引號的欄位、內嵌逗號與換行
讀取遵循 RFC 4180，也就是 JSON 轉 CSV 頁面寫出時所遵循的同一套規則。用雙引號包起來的欄位可以包含分隔符、換行，或成對的雙引號（讀回時變成一個）。所以 "Ada, Countess" 是一個含逗號的單值，跨兩列的值仍是一個儲存格。CRLF 與 LF 兩種行尾都接受；開頭的 UTF-8 位元組順序標記——Excel 與某些匯出工具加入的不可見 U+FEFF——會被去除，因此第一個欄名不會變成 id。
不規則的列
手工編輯的檔案很少是整齊的矩形。欄位比表頭少的列會以空值補齊，欄位比表頭多的列會被截斷，因此每個物件的鍵都相同。另一種做法——拒絕整個檔案——不如回傳那些格式良好的列有用，但這確實意味著缺失的值真的不在其中。
常見問題
CSV 是如何對應到 JSON 物件的？
第一列被讀作表頭，它的儲存格成為屬性名；其後的每一列成為陣列裡的一個物件，以這些名字為鍵。表頭為 id,name、只有一列 1,Ada 的 CSV，會產生 [{ "id": "1", "name": "Ada" }]。
為什麼我的數字與布林值都變成了字串？
型別辨識預設關閉，這是刻意為之。CSV 沒有型別，所以轉換器無法知道 007 是數字七還是編碼零零七；猜錯會悄悄損壞郵遞區號、電話號碼、帳號這類識別碼。當你確定某欄是數值時再開啟辨識，而且即使開啟，帶前導零的值仍會保持為字串。
開啟辨識後，什麼才算數字？
只有能寫成 JSON 數字的文字：可選的負號、不帶前導零的數字（除非值正好是 0）、可選的小數部分，以及可選的指數。true、false、null 也會被辨識。除此之外，包括 007 和 1,234 在內，都保持為字串。
帶引號的欄位、內嵌逗號與換行如何讀取？
解析遵循 RFC 4180：用雙引號包起來的欄位可以包含分隔符、換行，或成對的雙引號（讀回時變成一個）。所以內容為 Ada, Countess 的儲存格寫作 "Ada, Countess"，跨兩列的值仍是一個欄位。CRLF 與 LF 兩種行尾都接受。
我的檔案帶 UTF-8 BOM，第一個欄名會出問題嗎？
不會。開頭的位元組順序標記——某些工具（包括 Excel）會放在 CSV 開頭的不可見 U+FEFF——會在解析前去除，否則第一個表頭會讀成 id。這裡會正確地讀成 id。
與表頭不符的列會怎樣？
欄位比表頭少的列會以空值補齊，欄位比表頭多的列會被截斷，因此每個物件的鍵都相同。手工編輯的檔案裡不規則的列很常見，這裡選擇容忍而不是回報錯誤，但缺失的資料確實不在輸出中。
想要相反方向？JSON 轉 CSV 可以把物件陣列寫成一張表。發現錯誤？聯絡我們。