一個基於瀏覽器的 CSV 轉 JSON 替代方案，完全在用戶端執行，可以將符合 RFC 4180 風格的逗號分隔檔案轉換成格式化的 JSON 陣列，且無需上傳資料、無需推測儲存格內容的型別，也無需擔心遺漏引號包起來的逗號、換行符或雙引號。轉換過程在單一瀏覽器分頁內完成，因此來源檔案從不經過網路傳輸，而產生的 JSON 輸出是由 null 原型物件所構成，其屬性順序完全對應原始 CSV 的標頭順序。每個儲存格都會成為 JSON 字串，這代表 001 會保留為 "001"、true 會保留為 "true"、null 會保留為 "null"，而空儲存格則一律保留為空字串，無論下游解析器原本會如何推測型別。引號包起來的欄位可以包含逗號、嵌入的 CRLF、嵌入的 LF、嵌入的 CR，以及成對的雙引號，且解析器會就地解碼這些序列，而不是將它們視為結構。領先的 UTF-8 位元組順序標記會在標頭解析前被消耗掉，使得由試算表程式匯出的檔案仍可作為有效輸入，而串流中稍後出現的 U+FEFF 則會保留為欄位資料。這些特性結合起來，使本機瀏覽器工具成為 Node.js 函式庫、Python 腳本與遠端 API 服務之外一個可信的替代方案，特別是在隱私、可重現性與精確字串保留不可妥協的情況下。
為什麼開發者會尋找 CSV 轉 JSON 的替代方案
現有的數種 CSV 轉 JSON 轉換方式都帶有阻力，促使開發者尋求其他方案。Node.js 函式庫如 csv-parse、papaparse 與 fast-csv 在腳本內運作良好，但需要安裝套件、經過建置步驟，且在受限環境中不一定能取得執行環境。Python 內建的 csv 模組雖然可靠，但將 Python 直譯器與前端套件一起發布通常並不實際。雲端 API 如 tableconvert、convertcsv 或 csvjson 雖然免除了相依性負擔，卻會上傳檔案、在大量使用時按次計費，且有時會在回傳 JSON 之前悄悄強制轉型數字、日期與布林值。
遭遇到這些痛點的開發者通常會搜尋結合三種特性的 CSV 轉 JSON 替代方案：無需上傳、無需安裝、無需型別推測。當解析器嚴謹到足以處理現實世界的 CSV 怪癖時，本機瀏覽器分頁即可滿足這三點。CSV 轉 JSON 轉換器正是這樣的一個替代方案，本文剩下的部分將逐步說明它的保證內容與實際使用方式。
本機 CSV 轉 JSON 替代方案應有的保證
一個值得信賴的本機替代方案應該承諾一組小而可驗證的行為，使其產生的 JSON 在不同機器與瀏覽器版本間都可預測。第一項承諾是所有剖析、驗證、物件建構、UTF-8 量測、複製與 Blob 建立都在當前分頁內進行，不上傳任何 CSV 或 JSON。第二項承諾是僅限字串的值：每個儲存格都成為 JSON 字串，數字、布林值、null、日期、公式與空值都不會從拼寫推測而來。第三項承諾是由標頭驅動的鍵：第一筆記錄提供鍵，標頭順序決定屬性順序，重複或空白的標頭會直接使轉換失敗。第四項承諾是精確的引號處理：引號包起來的欄位可以包含逗號、CRLF、LF、CR 與成對的雙引號，未加引號的引號則會被拒絕而非修復。第五項承諾是 BOM 容錯：會在標頭解析前消耗一個領先的 U+FEFF，而稍後出現的任何 U+FEFF 則會保留為資料。最後一項承諾是絕無部分結果：過短或過長的列、空白的標頭、重複的鍵或超過上限時，會明確失敗且絕不會留下舊的 JSON。
這些保證對應到大多數讀者實際所指的「替代方案」工作定義：新工具必須執行相同的工作，但移除了阻力。下一節將展示讓該替代方案實際運作的具體步驟。
使用本機替代方案將 CSV 轉換為 JSON
轉換是個三步驟流程，在單一頁面中執行。每一步都對應一次明確的使用者操作，並在畫面上產生可觀察的結果。
- 貼上 CSV。開啟 CSV 轉 JSON 頁面，並貼上一個以逗號分隔的表格，其第一筆記錄包含非空白且不重複的標頭名稱。CRLF 是規範的記錄結尾，而獨立的 LF 或 CR 也會作為互通性延伸被接受。領先的 UTF-8 BOM 會在標頭解析前自動被消耗，因此常見試算表工具匯出的 UTF-8 檔案無需手動清理即可使用。
- 轉換並驗證摘要。觸發轉換並檢視畫面上的摘要。摘要應回報資料列數、欄數、儲存格總數，以及產生 JSON 的 UTF-8 位元組大小。若其中任何數字看起來不正確，請編輯 CSV 並重新轉換。編輯 CSV 會撤銷舊的 JSON ObjectURL，並清除輸出、錯誤、摘要與複製狀態，因此絕不會有機會基於過時的輸出進行操作。
- 確認字串保留並複製或下載。抽樣檢查 JSON 中的每個值都是字串，然後將結果複製到剪貼簿或下載 converted.json。下載檔案由 Blob URL 產生，當輸入被編輯、取代或轉換失敗時，以及分頁卸載時，該 URL 都會立即被撤銷，因此分頁中不會留有過時的檔案。
這個三步驟模式就是全部的轉換介面。沒有隱藏的開關、沒有結構描述推測步驟，也沒有型別強制轉換選項，因為這套工具刻意限定在字串保留的範疇內。
字串保留如何保護您的資料
任何 CSV 轉 JSON 替代方案最重要的單一行為，就是它如何處理看起來像其他型別的值。一個以零開頭的 3 位數 SKU、一個為了讓下游匯入端保留為字串的 ISO 日期、用作旗標的字面詞 "true"，以及用作類別名稱的詞 "null"，這些都會在解析器決定「幫個忙」的那一刻遺失。
| CSV 儲存格 | 保留字串的 JSON | 推測型別的 JSON |
|---|---|---|
| 001 | "001" | 1 |
| 2025-01-15 | "2025-01-15" | "2025-01-15" 或 Date 物件 |
| true | "true" | true |
| null | "null" | null |
| (空白儲存格) | "" | null、undefined 或省略 |
| 3.14 | "3.14" | 3.14 |
CSV 轉 JSON 工具絕不推測，因此上表的中間那一欄也就是正確的那一欄。記錄在序列化前以 null 原型物件建構，這代表 __proto__、constructor、prototype 與 toString 這類鍵會以一般字串屬性的形式儲存，而不會被解讀為繼承行為。接著 JSON.stringify 會以兩格縮排對屬性名稱、引號、反斜線、控制字元與嵌入的換行符套用標準跳脫，因此產生的文字是有效的 JSON 資料而非可執行的程式碼。接收端應用程式在信任結果前仍須自行剖析並驗證，但產生端是完全可預測的。
引號內的逗號、行尾與 BOM
現實世界的 CSV 很少符合課本上的最低標準。試算表匯出時會將包含逗號、引號或換行符的儲存格用雙引號包起來，並依平台不同而發出 CRLF、LF 或兩者的混合。一個嚴謹的替代方案必須處理這些變化而不訴諸修復啟發法，因為靜默修復正是下游產生幽靈列與欄位移位的元凶。
這套工具使用的解析器實作了有限制的 RFC 4180 風格方言。逗號是唯一分隔符，因此 Tab、分號與直立線都是欄位字元而非替代分隔符。引號包起來的欄位可包含逗號、CRLF、LF、CR 與成對的雙引號，且引號欄位內連續兩個引號會解碼為單一的字面引號。在閉合引號之後，只接受逗號、記錄結尾或輸入結束；空格或其他結尾字元會被拒絕而非靜默丟棄，這能及早抓出匯出端的錯誤。引號內嵌入的行尾會以原始的 CRLF、LF 或 CR 形式保留為欄位資料，絕不會被壓平或正規化掉。
關於 BOM，解析器會在標頭解析前精確消耗一個領先的 U+FEFF，使試算表工具產生的 UTF-8 CSV 檔案保持有效的輸入。其他位置的 U+FEFF 會保留為資料而不會被剝除。僅含 BOM 的檔案在正規化後會被視為空白，並回報需要輸入的錯誤。原始輸入的預算會在移除 BOM 之前檢查，因此一個幾乎全是 BOM 位元組的檔案仍會得到公平的量測。當貼上的檔案在非預期位置含有雜散 BOM 時，一份專門探討如何從 CSV 檔案中移除 BOM 而不遺失資料的指南是實用的搭配閱讀，但對於一般的 UTF-8 匯出，轉換器會自動處理領先位元組。
限制、錯誤與超過時會發生什麼事
一個會靜默限制輸入的替代方案比大聲失敗的方案更糟，因為部分輸出看起來很成功，直到下游匯入端拒絕它為止。CSV 轉 JSON 工具在完整轉換前或轉換中強制執行每一項限制，並在跨越邊界時回報明確的錯誤。
| 限制 | 邊界 | 量測方式 |
|---|---|---|
| 原始輸入大小 | 5,000,000 個 UTF-16 字碼單元 | 消耗 BOM 前的預剖析預算檢查 |
| 資料列數 | 標頭後 10,000 列 | 剖析過程中計數 |
| 欄數 | 200 欄 | 標頭寬度，每個資料列必須相符 |
| 資料儲存格數 | 200,000 個儲存格 | 整個表格中列 × 欄的乘積 |
| JSON 輸出大小 | 10,000,000 個 UTF-8 位元組 | 序列化字串的 TextEncoder 編碼 |
精確的邊界值會被接受，而超出邊界一個單位、一列、一欄、一個儲存格或一個位元組都會明確失敗。儲存格預算可能在列數限制之前先拒絕一個寬表格，這是刻意的設計，因為即使其他檢查都通過，一個 201 欄的表格在第 996 列時就必須失敗。多位元組 Unicode 輸出以編碼後的位元組而非 JavaScript 字串長度來量測，因此含有大量表情符號的輸出會以其實際消耗的位元組來評估。狀態機也會區分一個可選的最後記錄結尾與真正的空白記錄，因此結尾的換行不會產生幽靈空白列，但兩個連續的結尾則會。
常見的失敗包括過短或過長的列、外露的引號、閉合引號後的垃圾字元、未閉合的引號、空白的開頭/中間/結尾標頭、重複的鍵（以精確且區分大小寫的方式比較，並保留空白字元），以及列長不一致。這些情況都不會產生部分 JSON，也不會被靜默修復。轉換失敗時不會留下過時的下載，因此下一次嘗試會從乾淨的狀態開始。
Where This Alternative Fits in a Developer Workflow
For most day-to-day conversion tasks a browser tool is faster to reach than spinning up a Node.js script or a Python REPL. It is also a stronger fit than an API service when the file contains personally identifiable information, internal schemas, or anything covered by a data-residency rule. Because every parsing step happens locally, the JSON output is reproducible on any machine that runs the same browser, and the source CSV can be archived next to the output for a complete audit trail.
For debugging downstream issues, the produced JSON can be piped directly into the JSON formatter or the JSON validator without leaving the browser, and for the inverse direction the JSON to CSV tool handles the round trip with the same RFC 4180-style guarantees. None of those tools upload data either, so the entire workflow stays inside the local tab. As a final check before import, review the headers and counts reported in the summary, retain the source CSV when original quoting or line-ending style matters, and confirm that the receiving application parses every value as a string rather than coercing it on its own.
If you're weighing options, Excel Formulas Cheat Sheet Alternative for Common Formulas covers this in detail.