Alat pengembang · JSON pemformat & validator
Bagaimana validator JSON menemukan baris dan kolom kesalahan yang tepat
· Cara kerjanya
json validasi alur kerja pengembang
Mesin browser melaporkan kegagalan JSON.parse secara berbeda, dan beberapa hanya memberikan offset karakter. Postingan ini menjelaskan bagaimana validator mengubahnya menjadi garis dan kolom, dan mengapa posisi tersebut menandai tempat penguraian berhenti, bukan tempat Anda melakukan kesalahan.
Pesan kesalahan yang tidak memberi tahu Anda apa pun — mengapa 'Token tak terduga di JSON pada posisi 1432' tidak berguna dalam file baris 400
Kesalahan seperti “Token tak terduga” membuat frustasi dalam konfigurasi yang panjang karena tidak menawarkan lokasi yang dapat Anda buka di editor Anda. JSON.parse adalah parser resmi browser, namun teks diagnostiknya berbeda antar mesin dan versi JavaScript. ToolAcre tidak menebak lokasi dengan mencocokkan string kesalahan bahasa Inggris yang tidak stabil. Jika JSON.parse gagal, pemindai ketat terpisah akan menelusuri teks asli untuk mengidentifikasi karakter pertama yang tidak dapat diterima oleh tata bahasa JSON.
Apa yang sebenarnya dilakukan parser JSON saat membaca — penelusuran tokenisasi dan tata bahasa turunan rekursif yang menggunakan satu nilai pada satu waktu
JSON memiliki enam karakter struktural—kurung kurawal, tanda kurung, titik dua, dan koma—dan nilai yang dapat berupa string, angka, larik, objek, benar, salah, atau nol. Pemindai perlu mengetahui apakah ia ada di dalam string yang dikutip sebelum menyebut koma sebagai pemisah: {"note":"A,B"} memiliki satu nilai, bukan dua. Ini melangkah melalui nilai atau anggota objek dan memeriksa apa yang selanjutnya secara hukum dapat diikuti. RFC 8259 mendefinisikan tata bahasa ini, dan tidak seperti JavaScript objek literal, ia tidak mengizinkan komentar atau tanda koma.
Dari offset karakter hingga baris dan kolom — menghitung baris baru hingga offset kegagalan, dan mengapa akhiran CRLF dan karakter multi-byte mempersulit penghitungan
Pemindai biasanya dimulai dengan offset berbasis nol pada string JavaScript asli. Untuk membuatnya berguna, hitung jeda baris sebelum offset dan temukan seberapa jauh letak kegagalan dari jeda terakhir. CRLF harus diperlakukan sebagai satu garis visual yang berakhir, bukan dua garis; posisi dalam string JavaScript menghitung UTF-16 unit kode, bukan UTF-8 byte pada disk. Emoji non-BMP dapat menempati dua unit kode di editor yang secara visual menampilkan satu mesin terbang. UI melaporkan baris, kolom, dan kutipan sehingga Anda dapat memeriksa tanda sisipan terhadap file yang Anda tempel.
Jika penguraian berhenti bukan merupakan kesalahannya - koma yang hilang dilaporkan pada kunci berikutnya, dan tanda kutip yang menyimpang dapat mendorong kesalahan tersebut ke banyak baris ke bawah
Tanda mustahil pertama sering kali muncul setelah kesalahan awal. Dalam sebuah objek, melupakan koma setelah true membuat kutipan yang mengawali properti berikutnya menjadi ilegal: parser mengharapkan koma atau kurung kurawal penutup. String yang tidak diakhiri dapat menyebabkan kesalahan muncul pada jeda baris atau akhir input berikutnya. Baca mundur dari titik yang dilaporkan untuk menemukan pembatas yang hilang; jangan menganggap karakter di bawah tanda sisipan harus dihapus.
Contoh praktis: konfigurasi dengan satu koma yang hilang — posisi yang dilaporkan, token di sekitarnya, dan cara berjalan mundur ke penyebab sebenarnya
Coba dokumen tiga baris literal {"name":"demo", diikuti dengan "enabled":true pada baris kedua dan "port":8080} pada baris ketiga, tanpa koma setelah true. ToolAcre baris laporan 3, kolom 1, offset 31: diharapkan ada koma atau } setelah properti sebelumnya, dan menunjukkan tanda sisipan di bawah tanda kutip pertama "port". Sisipkan koma di akhir baris kedua, lalu validasi lagi. Ini adalah diagnosis kendala sintaksis pertama, bukan penilaian bahwa kata “port” salah.
Perbedaan mesin browser — V8, SpiderMonkey, dan JavaScriptCore menyatakan kegagalan yang sama secara berbeda, itulah sebabnya laporan baris dan kolom yang konsisten membantu
V8, SpiderMonkey, dan JavaScriptCore menggunakan kata-kata yang berbeda dan terkadang cuplikan kontekstual yang berbeda untuk kegagalan JSON.parse yang sama. Pemindai ToolAcre memberikan alasan struktural dan lokasinya sendiri ketika parser asli menolak nilainya. Jika pemindai tidak setuju dengan JSON.parse, alat akan mengembalikan kesalahan mesin daripada mengarang posisi. Penggantian itu lebih aman daripada dengan percaya diri menunjuk pada karakter yang dapat ditebak.
Apa yang tidak tercakup dalam hal ini — masalah semantik seperti tipe yang salah, bidang yang hilang, atau pelanggaran skema, yang tidak akan pernah ditandai oleh validator sintaksis
Objek yang valid secara sintaksis masih bisa salah untuk aplikasi Anda: bidang wajib yang hilang, usia yang ditulis sebagai teks, dua kunci duplikat, atau referensi ke file yang tidak ada tidak secara otomatis tidak valid JSON. RFC 8259 mengatakan nama anggota harus unik untuk interoperabilitas, tetapi penguraian belaka tidak menerapkan skema API Anda. Validasi sintaksis di sini dan validasi batasan semantik dalam program yang menggunakan dokumen.
Kesimpulan: membaca posisi sebagai 'token pertama yang tata bahasanya tidak dapat diterima' — dan bagaimana formatter & validator JSON melaporkan baris dan kolom tersebut tanpa mengunggah teks
Perlakukan posisi yang dilaporkan sebagai “tanda pertama yang tidak dapat diterima oleh tata bahasa ini.” Bekerja mundur ke penyebabnya, perbaiki satu masalah dan jalankan kembali. JSON pemformat & validator melakukan ini secara lokal tanpa mengunggah konfigurasi yang ditempelkan. Jangan tempelkan kredensial produksi nyata ke situs web publik mana pun jika editor offline dapat mendiagnosis file tersebut.