Pencarian Pesan Error JSON: Dari Teks Error Langsung ke Perbaikan

Intinya: saat error JSON.parse muncul, rebut dulu posisi dan token-nya; posisi 0 berarti periksa respons HTML, BOM, atau tipe yang salah, dan pesan "Expected" berarti lihat karakter sebelumnya — jangan membaca ulang baris demi baris dari posisi yang dilaporkan.

Teks error bukan gangguan — itulah jawabannya. Parser memberi tahu karakter mana yang ditemui, apa yang diharapkan, dan apa yang sebenarnya diterima. Mencari berdasarkan pesan error lebih baik daripada menulis ulang seluruh dokumen dengan tangan.

Setiap error JSON.parse() memiliki tiga bagian: posisi (offset karakter, atau baris/kolom), harapan (Expected...), dan kenyataan (Unexpected token X, atau xxx is not valid JSON). Setiap mesin menyebutkannya dengan cara berbeda — Chrome dan Node (V8) mengatakan Expected ',' or '}' after property value in JSON at position 25, Firefox mengatakan JSON.parse: expected ',' or '}' after property value in object at line 3 column 1, Safari mengatakan JSON Parse error: Expected ',' or '}' — tetapi ketiganya menunjuk pada kerusakan sintaks yang sama. Saat mencari error, abaikan kata-katanya dan ambil tiga fakta: karakter mana, apa yang diharapkan, apa yang datang.

1. Tabel pencarian 12 error

Kolom kiri adalah fragmen yang paling mudah dikenali dari konsol Anda (formulasi V8). Varian Firefox/Safari ada di dalam tanda kurung.

Dua yang pertama pantas diperiksa lebih dekat, karena keduanya tidak berarti "JSON Anda salah" — keduanya berarti "apa yang Anda terima bukan yang Anda kira".

2. Tiga sumber umum error posisi 0

Posisi 0 berarti karakter paling pertama tidak legal. Jika tidak ada yang tampak mencurigakan, karakternya mungkin tidak terlihat. Tiga tersangka yang biasa:

Pertama: <, artinya HTML. Ini error parse paling umum di produksi. URL yang salah, sesi kedaluwarsa yang dialihkan gateway, atau templat error server — body dimulai dengan <!DOCTYPE html> dan parser berhenti pada karakter pertama. Langkah yang benar adalah membuka panel Network dan membaca respons mentah, lalu memperbaiki panggilan API, bukan JSON-nya.

Kedua: BOM atau karakter zero-width. File yang disimpan oleh Notepad Windows sering dimulai dengan BOM UTF-8 (\uFEFF), dan teks yang disalin dari halaman web atau aplikasi chat bisa membawa spasi zero-width (\u200B–\u200D). Tak terlihat bagi Anda, jelas bagi parser:

复制// Strip BOM and zero-width characters before parsing
const cleaned = raw.replace(/^\uFEFF/, '').replace(/[\u200B-\u200D]/g, '');
const data = JSON.parse(cleaned);

Ketiga: tipe yang salah. JSON.parse(undefined) melaporkan "undefined" is not valid JSON; JSON.parse(someObject) melaporkan Unexpected token o (object dikonversi paksa menjadi "[object Object]", dan o tidak legal pada posisi 1). Keduanya berarti "data sudah di-parse" atau "tidak pernah ada data". Periksa tipenya, bukan sintaksnya:

复制let data = text;
if (typeof data === 'string') {
  data = JSON.parse(data); // Parse only when it really is a string
}

3. Posisi menunjuk ke hilir; penyebabnya ada di hulu

Dua error menyesatkan Anda soal lokasi, dan keduanya adalah entri yang paling sering salah dibaca dalam tabel:

• Koma yang hilang: {"a": 1 "b": 2} melaporkan Expected ',' or '}' after property value pada baris "b". Laporannya benar, tetapi perbaikan berada di akhir baris sebelumnya.
• Kurung penutup yang hilang: penyarangan dalam yang kehilangan satu } atau ] membuat parser menelan semua hingga akhir input dan melaporkan Unexpected end of JSON input. Posisinya adalah akhir file; celah sebenarnya bisa jauh lebih awal. Cari ke belakang untuk { atau [ terakhir yang belum ditutup — menghitung pasangan lebih baik daripada mengandalkan mata.

Teknik umumnya adalah bisection: potong teks sebelum posisi yang dilaporkan dan parse potongan itu sendiri. Jika berhasil di-parse, masalahnya dekat posisi yang dilaporkan; jika tidak, bagi lagi ke belakang. Batas potongan pertama yang gagal adalah lokasi error sebenarnya. Untuk file besar, format dulu dokumennya — dengan indentasi yang sejajar, level yang hilang terlihat sekilas (alat formatter JSON online cukup untuk ini).

4. Empat kondisi "tampak sehat" yang berhasil di-parse tetapi berperilaku salah

Lebih buruk daripada error adalah tidak ada error tetapi datanya salah. Dalam keempat kasus JSON-nya valid dan parser senang — masalahnya ada pada bentuk data:

1. Encoding ganda: seluruh dokumen telah di-JSON.stringify dua kali, sehingga hasil parsingnya string, bukan object. Jika typeof result === 'string', parse lagi — tetapi temukan dan perbaiki serialisasi ganda di sumbernya.
2. Kunci duplikat ditimpa diam-diam: {"name": "Tom", "name": "Jerry"} adalah JSON valid, sebagian besar parser tidak mengeluh, dan nilai kedua yang menang. Ini menggigit saat menggabungkan data dari beberapa sumber; munculkan dengan validator JSON yang ketat sebelum menggigit Anda.
3. NDJSON diperlakukan sebagai satu dokumen: API streaming mengeluarkan satu object per baris; mem-parsing seluruh teks gagal dengan Unexpected non-whitespace character after JSON. Pisahkan pada \n dan parse per baris.
4. Kehilangan presisi angka secara diam-diam: integer di atas 2^53 - 1 (snowflake ID) kembali dengan digit terakhir menjadi nol, tanpa error sama sekali. Kirim ID sebagai string.

Benang merahnya: parser percaya semuanya baik-baik saja. Jadi saat data API tampak salah, cetak dulu 80 karakter pertama dari teks mentah dan typeof-nya — konfirmasi bentuknya sebelum membahas isinya.

5. Buat error mustahil terjadi saat menulis

Tabel pencarian adalah alat setelah kejadian; pencegahan adalah alat sebelum kejadian. Empat kebiasaan mencegat sebagian besar error sebelum terjadi:

复制// 1. Two checks before parsing any response
const response = await fetch('/api/users');
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: the API returned no data`);
}
const contentType = response.headers.get('content-type') ?? '';
if (!contentType.includes('application/json')) {
  throw new Error(`Expected JSON, got ${contentType}`);
}
const data = await response.json(); // 2. json() already parses — do not parse again

• Serialisasi untuk menghasilkan, jangan menyambung string: JSON.stringify() menangani kutip, baris baru, dan karakter kontrol dengan benar; string yang dirakit manual adalah sumber utama Bad control character dan Unterminated string.
• Selalu tangkap: error JSON.parse yang dilempar adalah crash sinkron kecuali ada yang menangkapnya. Untuk input tak tepercaya — localStorage, file eksternal — blok catch membutuhkan nilai default atau pelaporan error eksplisit.
• Serahkan struktur ke Schema: sintaks valid tidak berarti struktur valid. Field yang hilang dan tipe yang salah adalah urusan validasi JSON Schema di batas; lihat apa yang diselesaikan JSON Schema.

6. Jalur keputusan cepat

Padatkan seluruh artikel menjadi satu urutan keputusan. Saat melihat error, rebut dulu posisi dan token-nya:

1. Posisi 0 → periksa tiga sumber: < (HTML), BOM, tipe yang salah;
2. end of input → periksa body kosong atau terpotong, lalu cari ke belakang untuk kurung yang belum ditutup;
3. Expected ... → lihat karakter sebelumnya; biasanya koma atau kutip yang hilang;
4. after JSON data → beberapa dokumen digabungkan; pisahkan per baris;
5. Berhasil di-parse tetapi data tampak salah → jalankan empat pemeriksaan "tampak sehat".

Dipadukan dengan triase langkah demi langkah di cara memperbaiki error JSON parse, 90% masalah parse selesai dalam lima menit. Simpan teks error itu sendiri sebagai bookmark — itu adalah log debugging yang ditulis parser untuk Anda, kata-katanya berubah sekali setiap tiga tahun, dan satu pencarian terbayar untuk setahun.

Apa arti "Unexpected token in JSON"?

Parser menemui karakter yang tidak legal pada posisi tersebut dalam tata bahasa JSON. Token adalah karakter yang ditolak: < biasanya berarti API mengembalikan HTML, ' berarti kutip tunggal, / berarti komentar, dan huruf biasa biasanya berarti kunci tanpa kutip atau literal khusus JavaScript seperti undefined atau NaN. Baca token dulu, lalu posisinya, dan penyebabnya menyempit menjadi satu.

Bagaimana cara memperbaiki "Unexpected end of JSON input"?

Dua sumber: input kosong (body respons kosong, atau string kosong di localStorage) atau input terpotong (unduhan terputus, salinan kehilangan baris terakhir, batas ukuran). Tangani kasus kosong dengan if (!text) return; lalu verifikasi kelengkapan dan tutup {, [, atau " terakhir yang belum ditutup. Perhatikan bahwa error juga bisa berasal dari kurung dalam yang hilang — posisinya kebetulan berada di akhir file.

Mengapa Chrome, Firefox, dan Safari melaporkan error secara berbeda?

Ketiga browser membawa mesin JS yang berbeda (V8, SpiderMonkey, JavaScriptCore), dan masing-masing merumuskan errornya dengan caranya sendiri; MDN mendokumentasikan semua varian resminya. Tetapi ketiga error membawa tiga elemen yang sama — posisi, harapan, kenyataan — dengan semantik satu-ke-satu. Terjemahkan ke formulasi V8 dan gunakan tabel ini apa adanya.

Posisi error menunjuk ke tempat yang tampak baik-baik saja — bagaimana?

Error sebenarnya lebih awal. Kasus khas: koma yang hilang (dilaporkan di baris berikutnya) dan kurung penutup yang hilang (dilaporkan di akhir file). Telusuri ke belakang dari posisi yang dilaporkan token demi token, atau lakukan bisection: parse paruh pertama sendiri, dan batas potongan pertama yang gagal adalah lokasi error sebenarnya.