Alat pembangun · JSON pemformat & pengesah
Cara pengesah JSON mencari baris dan lajur ralat yang tepat
· Bagaimana ia berfungsi
json pengesahan aliran kerja pembangun
Enjin pelayar melaporkan JSON.parse kegagalan secara berbeza, dan sesetengahnya sahaja memberikan offset aksara. Siaran ini menerangkan cara pengesah mengubahnya menjadi baris dan lajur, dan sebab kedudukan menandakan tempat penghuraian berhenti dan bukannya tempat anda membuat kesilapan.
Mesej ralat yang tidak memberitahu anda apa-apa — mengapa 'Token tidak dijangka dalam JSON pada kedudukan 1432' tidak berguna dalam fail baris 400
Ralat seperti "Token tidak dijangka" mengecewakan dalam konfigurasi yang panjang kerana ia tidak menawarkan lokasi yang boleh anda buka dalam editor anda. JSON.parse ialah penghurai berwibawa pelayar, tetapi teks diagnostiknya berbeza antara JavaScript enjin dan versi. ToolAcre tidak meneka lokasi dengan memadankan rentetan ralat bahasa Inggeris yang tidak stabil. Jika JSON.parse gagal, pengimbas ketat yang berasingan menjalankan teks asal untuk mengenal pasti aksara pertama yang tidak dapat diterima oleh tatabahasa JSON.
Apa yang sebenarnya dilakukan oleh penghurai JSON semasa ia membaca — berjalan melalui tokenising dan tatabahasa turunan rekursif yang menggunakan satu nilai pada satu masa
JSON mempunyai enam aksara struktur—tanda kurung, kurungan, titik bertindih dan koma—dan nilai yang boleh menjadi rentetan, nombor, tatasusunan, objek, benar, palsu atau nol. Pengimbas perlu mengetahui sama ada ia berada di dalam rentetan yang dipetik sebelum memanggil koma sebagai pemisah: {"note":"A,B"} mempunyai satu nilai, bukan dua. Ia melangkah melalui nilai atau ahli objek dan menyemak perkara yang boleh diikuti secara sah seterusnya. RFC 8259 mentakrifkan tatabahasa ini, dan tidak seperti JavaScript objek literal ia tidak membenarkan ulasan atau koma di belakang.
Daripada pengimbangan aksara kepada baris dan lajur — mengira baris baharu sehingga mengimbangi kegagalan, dan mengapa CRLF pengakhiran dan aksara berbilang bait merumitkan kiraan
Pengimbas biasanya bermula dengan offset berasaskan sifar dalam rentetan JavaScript asal. Untuk menjadikannya berguna, kira pemisah baris sebelum pengimbangan dan cari sejauh mana kegagalan terletak daripada pemisah terakhir. CRLF harus dianggap sebagai satu penghujung garis visual, bukan dua baris; kedudukan dalam JavaScript rentetan dikira UTF-16 unit kod, bukan UTF-8 bait pada cakera. Emoji bukan BMP boleh menduduki dua unit kod dalam editor yang menunjukkan satu glyph secara visual. UI melaporkan baris, lajur dan petikan supaya anda boleh menyemak karet pada fail yang anda tampal.
Di mana penghuraian berhenti bukanlah di mana kesilapannya — koma yang hilang dilaporkan pada kekunci seterusnya dan petikan sesat boleh menolak ralat itu banyak baris ke bawah
Token mustahil pertama selalunya selepas kesilapan asal. Dalam objek, melupakan koma selepas benar menjadikan petikan yang memulakan sifat seterusnya menyalahi undang-undang: penghurai menjangkakan koma atau pendakap penutup. Rentetan yang tidak ditamatkan boleh menyebabkan ralat muncul pada pemisah baris kemudian atau akhir input. Baca ke belakang dari titik yang dilaporkan untuk mencari pembatas yang hilang; jangan anggap watak di bawah karet mesti dipadamkan.
Contoh yang berfungsi: konfigurasi dengan satu koma hilang — kedudukan yang dilaporkan, token di sekeliling dan cara berjalan ke belakang ke punca sebenar
Cuba dokumen tiga baris literal {"name":"demo", diikuti dengan "enabled":true pada baris dua dan "port":8080} pada baris tiga, tanpa koma selepas benar. ToolAcre melaporkan baris 3, lajur 1, mengimbangi 31: ia menjangkakan koma atau } selepas sifat sebelumnya dan ia menunjukkan karet di bawah petikan pertama "port". Sisipkan koma di hujung baris dua, kemudian sahkan semula. Ini adalah diagnostik bagi halangan sintaks pertama, bukan penghakiman bahawa perkataan "port" adalah salah.
Cara enjin pelayar berbeza — frasa V8, SpiderMonkey dan JavaScriptCore kegagalan yang sama secara berbeza, itulah sebabnya laporan baris dan lajur yang konsisten membantu
V8, SpiderMonkey dan JavaScriptCore telah menggunakan perkataan yang berbeza dan kadangkala coretan konteks yang berbeza untuk kegagalan JSON.parse yang sama. Pengimbas ToolAcre membekalkan sebab dan lokasi strukturnya sendiri apabila penghurai asli menolak nilai. Jika pengimbas pernah tidak bersetuju dengan JSON.parse, alat mengembalikan ralat enjin dan bukannya mengada-adakan kedudukan. Pengunduran itu lebih selamat daripada menunjuk watak yang diduga dengan yakin.
Perkara ini tidak meliputi — masalah semantik seperti jenis yang salah, medan hilang atau pelanggaran skema, yang tidak akan dibenderakan oleh pengesah sintaks
Objek yang sah dari segi sintaksis masih boleh salah untuk aplikasi anda: medan yang diperlukan yang tiada, umur yang ditulis sebagai teks, dua kekunci pendua atau rujukan kepada fail yang tidak wujud tidak secara automatik tidak sah JSON. RFC 8259 mengatakan nama ahli harus unik untuk saling kendali, tetapi penghuraian semata-mata tidak menguatkuasakan skema API anda. Sahkan sintaks di sini dan sahkan kekangan semantik dalam program yang menggunakan dokumen.
Bawa pulang: baca kedudukan sebagai 'token pertama yang tidak dapat diterima oleh tatabahasa' — dan cara pemformat & pengesah JSON melaporkan baris dan lajur itu tanpa memuat naik teks
Anggap kedudukan yang dilaporkan sebagai "token pertama yang tidak dapat diterima oleh tatabahasa ini." Berundur kepada punca, selesaikan satu isu dan jalankan semula. JSON pemformat & pengesah melakukan ini secara setempat tanpa memuat naik konfigurasi yang ditampal. Jangan tampal bukti kelayakan pengeluaran sebenar ke mana-mana tapak web awam jika editor luar talian boleh mendiagnosis fail itu.