Cara memperbaiki error JSON parse: memeriksa Unexpected token langkah demi langkah

Intinya: saat error parse, baca baris dan kolom yang dilaporkan untuk menemukan karakter ilegal pertama, lalu tentukan apakah itu kutip yang hilang, koma yang hilang, koma di akhir, BOM, atau pemotongan — jangan membaca ulang seluruh dokumen dari awal.

Pesan error tidak pernah memberi tahu Anda "apa yang salah"; ia hanya memberi tahu "di mana parser tidak bisa melanjutkan". Kedua posisi itu seringkali bukan tempat yang sama.

1. Pertama, terjemahkan error menjadi koordinat

JSON rusak yang sama menghasilkan error yang sangat berbeda di berbagai bahasa, tetapi semuanya dapat dikonversi menjadi "baris mana, karakter mana":

Setelah Anda memiliki posisinya, tempelkan JSON ke parser JSON online; alat ini menempatkan kursor pada lokasi error dan menyorot nomor baris serta kolom — langkah ini menghemat 90% pemeriksaan karakter dengan mata.

2. Enam error frekuensi tinggi

1. Koma di akhir

复制{
  "name": "json",
  "version": 1,
}

Ada koma berlebih sebelum }. Spesifikasi JSON tidak mengizinkan koma di akhir, sementara object literal JavaScript mengizinkannya, sehingga konfigurasi yang disalin dari kode paling mungkin membawanya. Perbaikan: hapus koma terakhir; jika data ini sejak awal berada di file JS, beralih ke konversi JSON5 alih-alih memaksanya menjadi JSON.

2. Kutip tunggal dan kunci tanpa kutip

复制{ 'name': 'json' }
{ name: "json" }

String JSON hanya boleh menggunakan kutip ganda, dan kunci juga harus berupa string berkutip ganda. Kedua contoh ini adalah sintaks longgar JSON5 / JavaScript, bukan JSON. Kutip ganda di dalam string harus ditulis sebagai \", dan backslash sebagai \\.

3. Komentar

复制{
  // Timeout in milliseconds
  "timeout": 3000
}

Tata bahasa RFC 8259 tidak menyediakan tempat untuk komentar. Entah hapus komentarnya, atau simpan sebagai .jsonc / .json5 dan gunakan parser yang mendukung komentar. Untuk pertimbangan di antara berbagai "skema komentar", lihat Cara menulis komentar dalam JSON.

4. Baris baru mentah dan karakter kontrol di dalam string

复制{"sql": "SELECT *
FROM t"}

String JSON tidak boleh berisi line feed mentah, tab, atau karakter kontrol U+0000–U+001F; semuanya harus ditulis sebagai \n, \t, \u0009. Saat memasukkan teks multi-baris ke JSON, escape dulu sekali di editor, atau tangani secara seragam dengan minify dan escape JSON.

5. BOM di header

UTF-8 yang disimpan Notepad Windows membawa tiga byte EF BB BF. JSON.parse melaporkan Unexpected token saat menemui BOM, dan mata sama sekali tidak bisa melihatnya. Cara mengetahuinya: periksa header file dalam heksadesimal, atau salin kontennya ke alat online dan lihat apakah karakter pertama tampil sebagai . Perbaikan: simpan sebagai "UTF-8 tanpa BOM".

6. Konten terpotong

Log yang hanya mencetak 4096 karakter pertama, respons API yang terpotong gateway, unduhan yang terputus — ciri khas kelas ini adalah "error berada di akhir" dan jumlah kurung tidak cocok. Hitung kurung dulu: jika penutup { dan [ tidak cocok, itu pemotongan, bukan error sintaks. Dalam hal ini jangan perbaiki apa pun — dapatkan data lengkapnya.

3. Dua alarm palsu yang melibatkan teks Tionghoa dan escaping

Tionghoa berubah menjadi \u4e2d\u6587: ini escaping JSON yang valid, bukan teks rusak. Setelah parsing, nilainya kembali menjadi Tionghoa; bentuk \u hanya muncul saat Anda melihat string mentah secara langsung. Saat perlu menunjukkannya kepada orang lain, cukup outputkan dengan alat format; Anda hanya perlu memedulikan strategi escaping saat Tionghoa harus bertahan di URL atau log.

Tionghoa berubah menjadi teks rusak seperti 涓枃: ini masalah encoding, bukan masalah JSON. Ini terjadi saat byte UTF-8 didekode sebagai GBK, menghasilkan pola teratur "tiga karakter mewakili satu karakter Tionghoa". Periksa Content-Type: application/json; charset=utf-8 pada header respons, dan periksa apakah encoding='utf-8' ditentukan secara eksplisit saat membaca file.

4. Alur perbaikan lima menit

1. Tempelkan ke alat: gunakan parser online untuk menemukan error pertama, dan perbaiki satu per satu;
2. Validasi setelah setiap perbaikan: parse ulang setelah setiap perubahan, agar memperbaiki beberapa tempat sekaligus tidak membuat error baru menutupi yang lama;
3. Minify sekali: hapus whitespace dengan Minify dan parse lagi; ini membedakan "error struktural" dari "masalah whitespace atau baris baru";
4. Bandingkan struktur: jika error tiba-tiba muncul setelah perubahan, gunakan JSON diff terhadap versi sebelumnya; perbedaannya biasanya satu koma;
5. Validasi tingkat field: jika sintaks lolos tetapi lapisan bisnis menolaknya (field hilang, tipe salah), itu termasuk validasi JSON Schema, bukan masalah sintaks.

5. Mengapa satu dari dua cuplikan JSON "yang tampak identik" berhasil di-parse dan yang lain tidak

Penyebab paling umum adalah karakter tak terlihat: koma lebar penuh ，, kutip lebar penuh “”, spasi tak terputus U+00A0, spasi zero-width U+200B. Di layar keduanya hampir tak bisa dibedakan dari padanannya yang setengah lebar, tetapi tidak satu pun merupakan bagian dari tata bahasa JSON.

Hanya ada satu cara untuk memastikan: salin konten di sekitar karakter yang bermasalah dan periksa code point byte demi byte. Menjalankan kode berikut di konsol browser akan menampilkan setiap karakter yang non-ASCII dan di luar rentang Tionghoa:

复制[...text].filter((ch) => {
  const code = ch.codePointAt(0);
  return code > 127 && !(code >= 0x4e00 && code <= 0x9fff);
});

Jika 0x201c (kutip ganda kiri), 0xff0c (koma lebar penuh), atau 0x00a0 muncul di output, merekalah pelakunya.

6. Pencegahan lebih murah daripada perbaikan

• Jalankan pemeriksaan parse pada file konfigurasi sebelum commit; satu baris di CI sudah cukup: node -e "JSON.parse(require('fs').readFileSync('config.json','utf8'))";
• Hasilkan respons API dengan pustaka serialisasi; jangan pernah menyambung string dengan tangan — string yang dirakit manual adalah satu-satunya sumber koma di akhir dan kutip yang hilang;
• Saat mencatat JSON ke log, panggil JSON.stringify dulu alih-alih menginterpolasikannya ke templat, agar payload yang setengah tertulis tidak disalahartikan sebagai pesan lengkap.

FAQ

Bagaimana cara menemukan posisi error sintaks JSON dengan cepat?

Ambil posisi atau baris/kolom yang dilaporkan parser; position adalah offset karakter berbasis 0, bukan nomor baris, sementara Java Jackson dan Python melaporkan baris dan kolom secara langsung. Tempelkan JSON ke parser JSON online dan alat ini menempatkan kursor pada lokasi error serta menyorot baris dan kolom. Jika error berada di awal, periksa header file untuk BOM dan cari karakter tak terlihat.

Mengapa konfigurasi yang disalin dari kode sangat mungkin membawa koma di akhir?

Spesifikasi JSON melarang koma di akhir sementara object literal JavaScript mengizinkannya, sehingga konfigurasi yang disalin dari kode JS mudah membawanya. Perbaikannya cukup menghapus koma terakhir; jika data itu memang milik file JS, beralih ke konversi JSON5 lebih cocok daripada memaksanya menjadi JSON.

Bisakah saya mem-parsing file konfigurasi yang berisi komentar sebagai JSON biasa?

Tidak — tata bahasa RFC 8259 tidak menyediakan tempat untuk komentar, sehingga mem-parsing langsung akan memunculkan error. Entah hapus komentarnya, atau simpan sebagai .jsonc / .json5 dan gunakan parser yang mendukung komentar. Untuk pertimbangan di antara skema komentar, lihat Cara menulis komentar dalam JSON.