Alat pembangun · JSON pemformat & pengesah
Sejarah piawai JSON: RFC 4627 hingga RFC 8259 dan ECMA-404
· Latar belakang
json piawaian pengesahan
JSON telah ditetapkan sekurang-kurangnya empat kali oleh dua badan piawai. Siaran ini mengesan laluan dari json.org Douglas Crockford kepada RFC 8259 dan ECMA-404, dan menerangkan perkara yang sebenarnya berubah untuk pembangun sepanjang perjalanan.
Spesifikasi manakah yang diikuti oleh penghurai saya?
Spesifikasi yang manakah diikuti oleh penghurai? Jawapannya biasanya kelihatan di bahagian tepi dan bukannya dalam objek dan tatasusunan biasa. Uji rentetan peringkat atas seperti `"ready"`, tanda tertib bait terkemuka, nama ahli pendua dan nombor yang luar biasa besar. Dokumen yang berbeza membincangkan sintaks dan kesalingoperasian pada tahap yang berbeza, manakala pelaksanaan menambah jenis data dan gelagat ralat mereka sendiri. Menamakan standard sahaja berguna apabila kontrak penghurai yang diperhatikan dipisahkan daripada andaian tentang setiap pelaksanaan JSON.
Bukti repositori untuk ToolAcre adalah konkrit dan lebih sempit daripada sejarah piawaian umum. Pemformat menggunakan `JSON.parse` untuk menghasilkan nilai dan `JSON.stringify` untuk memancarkannya; selepas kegagalan penghuraian, pengimbas tempatan membekalkan kedudukan dan alasan diagnostik yang stabil.
json.org dan penerangan awal JSON
json.org mempersembahkan JSON sebagai tatatanda padat yang diperoleh daripada sintaks literal objek JavaScript dan mendokumenkan struktur terasnya dengan tatabahasa yang kecil. Penerangan awal itu membantu memberi pembangun nama dan rujukan yang dikongsi untuk objek, tatasusunan, rentetan, nombor, boolean dan nol. Adalah lebih selamat untuk menerangkan halaman itu sebagai penjelasan awam awal daripada mendakwa, tanpa bukti sejarah yang disebutkan di sini, bahawa satu halaman atau orang secara bersendirian menemui format atau menetapkan penerimaannya.
Sumber repositori semasa tidak termasuk sejarah arkib json.org, penggunaan pelayar atau perbincangan jawatankuasa. Mereka menunjukkan cara aplikasi ini menghuraikan dan mendiagnosis JSON hari ini. Sehubungan itu, kenyataan sejarah dalam artikel ini kekal dekat dengan dokumen piawaian bertarikh dan elakkan mengaitkan motif atau kesan pasaran yang tidak dapat dibuktikan oleh fail tempatan tersebut.
RFC 4627 dalam 2006 — perihalan IETF pertama, aplikasi/json jenis media dan peraturan bahawa teks mestilah objek atau tatasusunan
RFC 4627, diterbitkan dalam 2006, menerangkan JSON untuk pertukaran Internet dan mendaftarkan jenis media `application/json`. Takrifan teks JSON memerlukan objek atau tatasusunan di peringkat atas, walaupun rentetan, nombor dan literal wujud sebagai nilai di dalam bekas tersebut. Sekatan itu ialah perbezaan sejarah yang berguna kerana dokumen yang mengandungi sahaja `"ready"` boleh menjadi nilai yang sah dalam rumusan kemudian sementara berada di luar definisi teks JSON RFC 4627.
Dokumen itu juga membincangkan pengekodan dan kebimbangan keselamatan dalam konteks pelaksanaan yang tersedia pada masa itu. Ia tidak boleh dibaca sebagai log perubahan untuk repositori ini: ToolAcre tidak mengandungi mod keserasian RFC 4627 dan laluan penghurainya mewakilkan pembinaan nilai kepada enjin JavaScript hos.
ECMA-404 dalam 2013 — Piawaian sintaks minimum Ecma sahaja dan sebab dua organisasi akhirnya menerangkan satu format
ECMA-404, pertama kali diterbitkan dalam 2013, menentukan sintaks JSON dalam bentuk yang sengaja padat. Fokusnya ialah tatabahasa teks JSON yang sah dan bukannya profil pertukaran yang lengkap untuk setiap penggunaan rangkaian. Skop itu membantu menjelaskan sebab ECMA-404 dan dokumen IETF boleh menerangkan tatatanda asas yang sama sambil berbeza dalam panduan kesalingoperasian sekitar yang mereka tekankan. Kewujudan dua badan piawai tidak membayangkan dua format yang tidak serasi dalam penggunaan biasa.
Tuntutan tentang sebab organisasi memilih laluan penerbitan tertentu memerlukan sumber dokumentari di luar pangkalan kod ini, jadi artikel ini tidak membuat kesimpulan motif jawatankuasa daripada tarikh piawaian. Perkara praktikal yang berkaitan ialah RFC 8259 dan ECMA-404 bertujuan untuk menjajarkan pada sintaks, manakala RFC 8259 membekalkan cadangan yang penting kepada pertukaran saling kendalian.
RFC 7159 dan RFC 8259
RFC 7159 menggantikan RFC 4627 dalam 2014 dan meluaskan takrifan teks JSON kepada sebarang nilai bersiri, mengalih keluar peraturan peringkat atas objek atau tatasusunan sahaja. RFC 8259 menggantikan RFC 7159 dalam 2017 dan kekal sebagai rujukan IETF yang biasa disebut untuk JSON. Ia memerlukan UTF-8 untuk JSON ditukar antara sistem di luar ekosistem tertutup dan merekodkan amaran kesalingoperasian sekitar nombor, nama pendua, Unikod dan tanda tertib bait daripada berpura-pura tatabahasa sahaja menjamin hasil yang sama di mana-mana sahaja.
`true` peringkat atas ialah cara padat untuk mematuhi peraturan nilai akar moden dalam ToolAcre kerana `JSON.parse` menerimanya. Keputusan itu menunjukkan tingkah laku pelaksanaan ini; ia tidak membina semula apabila setiap pelayar, pelayan atau API menggunakan definisi yang lebih luas.
Perkara yang berubah untuk pembangun yang bekerja
Untuk pembangun yang bekerja, perubahan spesifikasi yang paling jelas ialah penerimaan moden mana-mana nilai JSON pada akar dan panduan yang lebih kukuh untuk pengekodan saling kendali. Pelajaran yang kurang dapat dilihat ialah sintaks yang sah masih meninggalkan pilihan pelaksanaan. Nama objek pendua mungkin diruntuhkan, pesanan ahli bukan kontrak semantik, jumlah yang sangat besar mungkin kehilangan ketepatan, dan urutan Unicode yang luar biasa boleh bergerak secara berbeza melalui perpustakaan. Oleh itu, dokumen yang mematuhi piawaian boleh mendapat kekangan tambahan daripada skema aplikasi.
Dalam pemformat ini, nama pendua dan token nombor mula-mula melalui `JSON.parse`, jadi pemformatan kemudian mencerminkan nilai JavaScript yang terhasil daripada dokumen leksikal asal. Pengimbas menyumbang diagnostik selepas kegagalan; ia tidak mengekalkan ahli pendua atau nombor ketepatan sewenang-wenangnya. Itu adalah pemerhatian yang disokong repositori.
Perkara ini tidak meliputi
Perkara ini tidak meliputi spesifikasi berlapis di atas JSON. JSON Skema menerangkan kekangan pada bentuk dan nilai dokumen; JSON Penunjuk alamat lokasi dalam dokumen; JSON Tampalan mewakili perubahan. Mereka menyelesaikan masalah yang berbeza daripada tatabahasa asas dan tidak boleh dianggap sebagai versi JSON itu sendiri. JSONC, JSON5 dan format pengarang yang serupa juga memanjangkan atau mengubah sintaks yang diterima dan memerlukan penghurai mereka sendiri dan bukannya dilipat menjadi pengesahan ketat secara senyap.
Artikel ini juga mengelakkan sejarah sosial yang komprehensif tentang penerimaan JSON, sokongan pelayar atau persaingan dengan XML kerana sumber repositori yang disenaraikan tidak dapat membuktikan naratif tersebut. Tiada petikan luaran telah dicipta untuk mengisi jurang.
Bawa pulang: RFC 8259 ialah rujukan kepada petikan
RFC 8259 ialah rujukan IETF praktikal untuk dipetik untuk sintaks JSON semasa dan panduan kebolehoperasian, dengan ECMA-404 menyediakan standard Ecma yang sejajar. RFC 4627 dan RFC 7159 kekal berguna untuk memahami cara definisi yang diterbitkan berubah, terutamanya di peringkat atas. Petik dokumen yang menyokong tuntutan yang tepat dan bukannya menggunakan "spek JSON" sebagai rayuan yang samar-samar kepada pihak berkuasa dan bezakan peraturan normatif daripada gelagat pelaksanaan yang diperhatikan dalam penghurai tertentu.
Untuk ToolAcre, pernyataan yang boleh dipertahankan ialah repositori menggunakan penghurai dan penyeri bersiri JavaScript JSON dan menambah pengimbas tempatan yang ketat untuk diagnostik selepas kegagalan. Ujian nilai peringkat atas, tanda baca yang salah dan pengendalian nombor menerangkan laluan itu; mereka bukan sumber sejarah.