文字與校稿
JSON 排版成功，報名資料為什麼還是匯不進去？
市集報名資料可以正常排版，卻因欄位型別被退回？用一筆自擬資料核對代碼、數量、是否用電與日期，說明長編號、空值和試匯入時要注意的地方。
排版成功後，還要對照收件規格
JSON 排版成功，報名資料卻被退回，我會先看收件規格，不會繼續換縮排。能排版只表示語法可讀，攤位代碼、數量和日期仍可能不符合對方要求。尤其錯誤寫著「欄位型別不符」時，要核對的是欄位名稱、型別和實際內容，改成四格縮排也不會解決。下面用一筆自擬的社區二手市集報名資料練習。
本例約定：攤位代碼是三位文字，椅子數量是整數，是否用電是布林值，活動日期用年－月－日文字，報名編號存為文字，備註接受文字或 null。這些是教學設定，不是任何平臺的正式匯入格式。換一套系統，欄位名稱與規則都可能不同。
向收件人索取一份可接受的範例，並確認最外層要一個物件還是一份陣列。也要問清楚必填欄位、空值寫法與重複匯入的處理方式。不要只照畫面上的中文標籤自行翻譯鍵名，因為 chairs 和 chair_count 對讀者意思相近，對接收程式未必是同一欄。
- JSON 格式化可檢查 JSON 語法與整理縮排；本文的市集收件規格仍須另外逐欄核對。
- 下載待核對的示例資料六個欄位語法有效，但其中五個不符合本文自擬的收件規格。
- 下載依約定整理的示例資料保留已確認的攤位、數量、用電與日期；不代表其他平台接受同一規格。
六個欄位，有五個要依規格修正
假設紙本報名表已確認為第007號攤位、借兩張椅子、不用電，活動日期是2026年10月18日；報名編號每一位也已與原始名單核對。以下右欄依這些已知資料整理，沒有根據「看起來應該是」補值。備註尚無內容，按本例約定保留 null。
左欄有五個欄位不符合本例規格，但仍是語法有效的 JSON。表格的引號不能省略："2" 是文字、2 是數字；"false" 是文字、false 才是要求的布林值。格式化工具會保留這些值，不會替你猜報名者要不要用電。
那把7補成"007"就好了嗎？本例可以，是因為已有紙本依據。若手上只剩數字7，連原代碼長度都不確定，我會先回查，不自行補兩個零。椅子數量也一樣，文字能轉成數字不代表內容已確認。原值若寫"兩張或三張"，還是得向報名者問清楚數量。
| 欄位 | 收到的值 | 核對後的值 |
|---|---|---|
| booth_code | 7 | "007" |
| chairs | "2" | 2 |
| needs_power | "false" | false |
| event_date | "2026/10/18" | "2026-10-18" |
| registration_id | 9007199254740993 | "9007199254740993" |
| note | null | null |
長編號存成文字前，先核對每一位
報名編號用來找到某一筆紀錄，不需要相加。本例因此約定存成文字，在右欄加上引號。椅子數量仍留數字，才能依規格核對總數。欄位要怎麼存，我會看它拿來做什麼、收件端要求什麼，不為了看起來一致就全部改成文字。
這裡有個容易漏掉的差別：本站格式化會保留9007199254740993的原始數字寫法，直接用 JavaScript 的 JSON.parse 讀取未加引號的同一數字，卻會得到9007199254740992。前一個工具保留得住，不代表下一個程式也有相同精度，所以交件前必須知道收件端怎麼讀。
若編號在前一個程式中已經被改成9007199254740992，再加引號只會把錯誤的值保存成文字。回到原始來源核對每一位，再依雙方約定輸出。收件端若堅持使用數字，應請維護者確認可接受範圍與精度，不能只由交件人改型別。
日期能排版，不表示日曆上有這一天
本例將日期改成"2026-10-18"，是為了符合事先約定的格式，並非 JSON 只允許這種日期寫法。即使寫成"2026-02-30"也可能通過語法檢查，但2026年二月沒有30日。還要對照活動通知與日曆，確認它確實是預定辦理的日期。
備註的 null、空字串""、一個空格" "及整個 note 欄位不存在，是不同的資料。這裡約定 null 表示沒有備註，不代表所有表單都這樣定義。若空欄有「尚未回覆」和「確定沒有」兩種意思，先請收件人說明如何區分，不要批次替換成同一個值。
是否用電也要這樣核對。false 在本例代表已確認不用電，不能拿它填還沒問到答案的人。遇到未回覆的資料，我會先放進待確認清單，或按對方明訂的未知值處理。能寫成有效 JSON，和有沒有忠實記下報名內容，仍是兩件事。
先試匯入一筆，核對收到什麼再交整批
全部改好後，我會用對方提供的測試方式先交一筆，再看接收畫面裡到底留下了什麼：攤位007、椅子2張、不用電、10月18日，報名編號每一位都相同。這一步值得做，因為有些程式會忽略不認識的欄位，少了資料也未必報錯。「匯入成功」還不足以替你確認每一欄。
若沒有測試入口，先向維護者確認安全的試匯入方式，避免直接把同一筆資料反覆送進正式名單。尤其要先知道再次匯入是新增、覆蓋還是略過。否則修正檔案後再傳一次，可能留下兩筆報名。
開始處理整批時，核對的不只是一筆範例。假設這次有12筆報名，就逐項對照接收成功幾筆、失敗幾筆，以及原名單是否有人漏列或重複。若回報10筆成功、2筆失敗，先找出是哪兩筆與原因，也不要因總數對得上，就假定成功的10筆內容也完全正確。
原始匯出檔、為收件規格整理的檔案和接收結果各留一份，檔名標明用途與版本。核對紀錄寫清楚改了哪個欄位、依據是什麼，例如「booth_code 依紙本第007號恢復為三位字串」。這比只寫「格式修正」更方便之後追查。
原檔若含姓名、聯絡方式或其他未公開資料，示範與回報問題時改用另外製作的假資料，不要把整份真實名單放進公開貼文。本站工具不會替你決定檔案應交給誰；收件人、傳送管道與可分享欄位仍要先確認。
送出前，重新開啟這次要交的檔案，確認版本，附上收件規格和仍待確認的問題。前面保留的原檔、修改稿與接收結果，就是之後回查的依據：原資料已經錯了、轉換時改錯，或收件端讀法不同，才有辦法逐段查清楚。
參考來源
- RFC 8259：JSON 數值範圍與精度接收程式可能有不同的數值範圍與精度限制，JSON 語法有效不等於所有程式都能精確保存。
- MDN：JSON.parse 的數值精度說明數字在解析成 JavaScript Number 時可能失去精度。本文另外核對本站格式化保留原始字串的實作。