CSV 轉 JSON：保留開頭的零和長 ID
帳戶 ID 不用來做計算。換格式時，別丟了開頭的零或末尾的數字。
如果 001 是帳戶 ID，把它變成 1 就是轉換出錯。很長的貼文 ID 如果連最後一位數字都變了，也代表資料已經不正確。
CSV 不會告訴轉換器哪些欄位是識別碼。穩妥的做法是先把儲存格內容保留為字串，只有確實需要計算或判斷真假的值，才轉成數字或布林值。
先用範例檔案試試
我們的範例有前導零、兩個 19 位數 ID、引號欄位內的逗號，以及名字 Zoë。這些列都不包含真實帳戶資料。
account_id,post_id,name,note,active
001,1234567890123456789,Alex,"Design, then share",true
002,9876543210987654321,Zoë,"Keep leading zeros",false
{
"account_id": "001",
"post_id": "1234567890123456789",
"name": "Alex",
"note": "Design, then share",
"active": "true"
}使用 CozyToolkit 的預設設定，001 會保持為 "001"，長 ID 保持有引號，"Design, then share" 保持為單一值。即使是 true 也維持字串 "true"。這是預設行為：沒有開啟型別偵測，轉換器就不會自行猜測。
在不改變識別碼的情況下轉換
- 下載上面的範例 CSV，或使用 試試這個 CSV 在 資料轉換器 中開啟。
- 選擇 CSV 作為來源，JSON 作為輸出格式。自動偵測也能辨識這個範例。
- 在選項中，保持 第一列包含標題 開啟，偵測 CSV 中的數字和布林值 關閉。
- 檢查 JSON 輸出。
account_id和post_id的值應該有引號包住。 - 下載 JSON，並在會使用它的應用程式中檢查。正確的匯出仍可能被下一個匯入程式改變。
表格預覽適合檢查欄和列。檢查型別時請使用 JSON 檢視：帶引號的字串和數字在表格中可能看起來一樣。
型別偵測何時有幫助——何時沒有
如果 CSV 包含像 12 的數量，以及像 true 的旗標，偵測 CSV 中的數字和布林值 可以將它們轉換成 JSON 數字和布林值。在我們的轉換器中，像 001 這樣的值即使啟用偵測，仍會保持為字串。
長整數則不同。啟用偵測時，我們的轉換器使用無損數字解析器，在匯出的 JSON 中保留其數字。但它現在是沒有引號的數字。讀取該檔案的程式也必須精確處理它。
JavaScript 最大的安全整數是 9,007,199,254,740,991。一般的 JSON.parse 會將 JSON 數字轉換成 JavaScript 數字，超過這個安全範圍的值可能會被四捨五入。MDN 解釋了安全整數限制。
例如，在 JavaScript 中：
JSON.parse('{"id":1234567890123456789}').id
// 1234567890123456800
JSON.parse('{"id":"1234567890123456789"}').id
// "1234567890123456789"
如果你永遠不會對 ID 做加法、減法或平均，將它保持為字串可以避免這個問題。目前轉換器的型別偵測開關適用於整個檔案，而不是個別欄位。如果同一個檔案裡既有 ID 又有數量，先關閉型別偵測，再到接收資料的系統裡單獨轉換數量欄位。
如果 CSV 已經損壞
轉換器無法恢復先前試算表匯出時四捨五入掉的數字。也無法推斷 1 原本是 001 還是 0001。
在轉換前，以文字形式開啟原始 CSV。如果數字已經遺失，請回到原始資料來源重新匯出。事後加上零或編造最後幾位數字不是修復。
我們檢查了什麼
在 2026 年 9 月 28 日，我們用型別偵測關閉和開啟的狀態，將可下載的檔案透過 CozyToolkit 的轉換功能執行。我們檢查了兩個長 ID、前導零、引號內的逗號，以及輸出中的 Unicode。測量檔案 包含兩種輸出以供比較。檔案在你的瀏覽器中處理；這次測試沒有使用 AI 模型。