Semua artikel

JSON Repair: mengapa JSON rusak dan cara memperbaikinya

JSON yang "rusak" adalah masalah umum: berkas terlihat hampir benar, tetapi parser menolak membacanya. Penyebabnya sering kali angka yang ditempel apa adanya dari spreadsheet berformat Indonesia.

Penyebab umum JSON tidak valid

  • Koma berlebih sebelum tanda kurung penutup — {"a": 1,} — yang ditoleransi JavaScript tetapi tidak oleh parser JSON yang ketat.
  • Tanda kutip tunggal alih-alih ganda — umum saat menyalin dari literal objek JavaScript.
  • Kunci tanpa tanda kutip{name: "Budi"} alih-alih {"name": "Budi"}.
  • Komentar — spesifikasi JSON sama sekali tidak mengizinkan komentar, berbeda dengan JSON5 atau JSONC.
  • Output terpotong — jika respons API atau berkas log terpotong di tengah, dokumen tetap tidak tertutup.

Koma desimal: jebakan diam-diam dari Excel

Format angka Indonesia memakai koma untuk desimal dan titik untuk pengelompokan ribuan: "Rp 1.234,50" adalah harga yang wajar di spreadsheet. Jika ditempel apa adanya ke field JSON, {"harga": 1.234,50} bukan angka desimal yang valid bagi parser — ia membaca 1.234, menemukan koma di posisi yang tidak sah, lalu tersisa token terpisah 50. Alat perbaikan bisa saja menebak nilai yang dimaksud, tetapi tidak ada jaminan apakah maksudnya 1234,50 atau 1.234 yang terpotong.

Cara kerja perbaikan otomatis

Alat perbaikan JSON menerapkan heuristik: menambahkan tanda kutip yang hilang, menghapus koma berlebih, menutup tanda kurung yang tidak tertutup berdasarkan konteks. Ini bekerja baik untuk kesalahan tipikal dan umum, tetapi bukan sihir — alat tidak bisa menebak nilai apa yang dimaksud jika data rusak lebih parah.

Batas kemampuan

Perbaikan otomatis memperbaiki sintaks, bukan semantik. Jika seluruh field hilang, atau sebuah nilai salah secara logika, alat tidak akan mendeteksinya — hasilnya tetap perlu diperiksa secara manual, terutama jika angkanya berasal dari spreadsheet berformat Indonesia.

Saat perbaikan bersifat ambigu

Beberapa kerusakan memiliki beberapa perbaikan yang sama-sama masuk akal. String yang terpotong {"a": 1, "b": 2 bisa saja ditutup begitu saja dengan tanda kurung — dan kehilangan data jika sebenarnya masih ada field lain yang dimaksud. Heuristik perbaikan membuat asumsi "paling tidak merusak", tetapi ini tetaplah tebakan, bukan jaminan.

Coba alat