Alat pengembang · JSON pemformat & validator
Riwayat standar JSON: RFC 4627 hingga RFC 8259 dan ECMA-404
· Latar belakang
json standar validasi
JSON telah ditentukan setidaknya empat kali oleh dua badan standar. Postingan ini menelusuri jalur dari json.org Douglas Crockford ke RFC 8259 dan ECMA-404, dan menjelaskan apa yang sebenarnya berubah bagi pengembang selama proses tersebut.
Spesifikasi manakah yang diikuti parser saya?
Spesifikasi mana yang diikuti parser? Jawabannya biasanya terlihat di bagian tepi daripada di objek dan array biasa. Uji string tingkat atas seperti `"ready"`, tanda urutan byte terdepan, nama anggota duplikat, dan angka yang sangat besar. Dokumen yang berbeda membahas sintaksis dan interoperabilitas pada tingkat yang berbeda, sementara implementasi menambahkan tipe data dan perilaku kesalahannya sendiri. Penamaan standar hanya berguna ketika kontrak parser yang diamati dipisahkan dari asumsi tentang setiap implementasi JSON.
Bukti repositori untuk ToolAcre bersifat konkrit dan lebih sempit dibandingkan riwayat standar umum. Pemformat menggunakan `JSON.parse` untuk menghasilkan nilai dan `JSON.stringify` untuk memancarkannya; setelah kegagalan penguraian, pemindai lokal memberikan posisi dan alasan diagnostik yang stabil.
json.org dan deskripsi awal JSON
json.org menyajikan JSON sebagai notasi ringkas yang berasal dari sintaksis objek-literal JavaScript dan mendokumentasikan struktur intinya dengan tata bahasa kecil. Deskripsi awal tersebut membantu memberi pengembang nama dan referensi bersama untuk objek, array, string, angka, boolean, dan null. Lebih aman mendeskripsikan halaman tersebut sebagai penjelasan publik awal daripada mengklaim, tanpa bukti sejarah yang dikutip di sini, bahwa satu halaman atau orang sendirian menemukan suatu format atau menetapkan penerapannya.
Sumber repositori saat ini tidak menyertakan riwayat arsip json.org, penggunaan browser, atau diskusi komite. Mereka menunjukkan bagaimana aplikasi ini mem-parsing dan mendiagnosis JSON hari ini. Oleh karena itu, pernyataan historis dalam artikel ini tetap sesuai dengan dokumen standar bertanggal dan menghindari mengaitkan motif atau dampak pasar yang tidak dapat dibuktikan oleh arsip lokal tersebut.
RFC 4627 di 2006 — deskripsi IETF pertama, jenis media aplikasi/json dan aturan bahwa teks harus berupa objek atau larik
RFC 4627, diterbitkan di 2006, menjelaskan JSON untuk pertukaran Internet dan mendaftarkan jenis media `application/json`. Definisi teks JSON memerlukan objek atau larik di tingkat atas, meskipun string, angka, dan literal ada sebagai nilai di dalam wadah tersebut. Pembatasan tersebut merupakan perbedaan historis yang berguna karena dokumen yang hanya berisi `"ready"` dapat menjadi nilai yang valid dalam formulasi selanjutnya, namun berada di luar definisi teks JSON RFC 4627.
Dokumen tersebut juga membahas masalah pengkodean dan keamanan dalam konteks implementasi yang tersedia pada saat itu. Ini tidak boleh dibaca sebagai log perubahan untuk repositori ini: ToolAcre tidak berisi mode kompatibilitas RFC 4627, dan jalur parsernya mendelegasikan konstruksi nilai ke mesin host JavaScript.
ECMA-404 di 2013 — Standar sintaksis minimal Ecma saja, dan mengapa dua organisasi akhirnya menjelaskan satu format
ECMA-404, pertama kali diterbitkan di 2013, menetapkan sintaksis JSON dalam bentuk yang sengaja dipadatkan. Fokusnya adalah tata bahasa teks JSON yang valid, bukan profil pertukaran lengkap untuk setiap penggunaan jaringan. Cakupan tersebut membantu menjelaskan mengapa dokumen ECMA-404 dan IETF dapat mendeskripsikan notasi dasar yang sama namun berbeda dalam panduan interoperabilitas seputar yang mereka tekankan. Keberadaan dua badan standar tidak berarti dua format yang tidak kompatibel dalam penggunaan sehari-hari.
Klaim tentang alasan organisasi memilih jalur publikasi tertentu memerlukan sumber dokumenter di luar basis kode ini, sehingga artikel ini tidak menyimpulkan motif komite dari tanggal standar tersebut. Poin praktis yang relevan adalah bahwa RFC 8259 dan ECMA-404 dimaksudkan untuk menyelaraskan sintaksis, sedangkan RFC 8259 memberikan rekomendasi yang penting untuk pertukaran interoperable.
RFC 7159 dan RFC 8259
RFC 7159 menggantikan RFC 4627 di 2014 dan memperluas definisi teks JSON ke nilai serial apa pun, menghilangkan aturan tingkat atas khusus objek atau array. RFC 8259 menggantikan RFC 7159 dalam 2017 dan tetap menjadi referensi IETF yang biasanya dikutip untuk JSON. Hal ini memerlukan UTF-8 untuk JSON yang dipertukarkan antar sistem di luar ekosistem tertutup dan mencatat peringatan interoperabilitas seputar angka, nama duplikat, Unicode, dan tanda urutan byte daripada berpura-pura tata bahasa saja menjamin hasil yang sama di mana pun.
`true` tingkat atas adalah cara ringkas untuk mengamati aturan nilai akar modern di ToolAcre karena `JSON.parse` menerimanya. Hasil tersebut menunjukkan perilaku implementasi ini; itu tidak direkonstruksi ketika setiap browser, server atau API mengadopsi definisi yang lebih luas.
Apa yang berubah untuk pengembang yang bekerja
Untuk pengembang yang bekerja, perubahan spesifikasi yang paling jelas adalah penerimaan modern atas nilai JSON apa pun pada akarnya dan panduan yang lebih kuat untuk pengkodean yang dapat dioperasikan. Pelajaran yang kurang terlihat adalah sintaksis yang valid masih menyisakan pilihan implementasi. Nama objek duplikat mungkin diciutkan, pengurutan anggota bukanlah kontrak semantik, jumlah yang sangat besar mungkin kehilangan presisi, dan jaringan Unicode yang tidak biasa dapat berjalan secara berbeda melalui perpustakaan. Oleh karena itu, dokumen yang memenuhi standar dapat memperoleh batasan tambahan dari skema aplikasi.
Dalam pemformat ini, duplikat nama dan token nomor terlebih dahulu melewati `JSON.parse`, sehingga pemformatan selanjutnya mencerminkan nilai JavaScript yang dihasilkan, bukan dokumen leksikal asli. Pemindai memberikan kontribusi diagnostik setelah kegagalan; itu tidak mempertahankan anggota duplikat atau nomor presisi sewenang-wenang. Itu adalah observasi yang didukung repositori.
Hal ini tidak tercakup dalam hal ini
Yang tidak tercakup di sini adalah spesifikasi yang dilapisi di atas JSON. JSON Skema menjelaskan batasan pada bentuk dan nilai dokumen; JSON Penunjuk alamat lokasi dalam dokumen; JSON Patch mewakili perubahan. Mereka memecahkan masalah yang berbeda dari tata bahasa dasar dan tidak boleh diperlakukan sebagai versi JSON itu sendiri. JSONC, JSON5 dan format penulisan serupa juga memperluas atau mengubah sintaksis yang diterima dan memerlukan parsernya sendiri daripada digabungkan menjadi validasi ketat secara diam-diam.
Artikel ini juga menghindari riwayat sosial komprehensif tentang adopsi JSON, dukungan browser, atau persaingan dengan XML karena sumber repositori yang tercantum tidak dapat mendukung narasi tersebut. Tidak ada kutipan eksternal yang diciptakan untuk mengisi kesenjangan tersebut.
Kesimpulan: RFC 8259 adalah referensi untuk dikutip
RFC 8259 adalah referensi IETF praktis yang dapat dikutip untuk panduan sintaksis dan interoperabilitas JSON saat ini, dengan ECMA-404 menyediakan standar sintaksis Ecma yang selaras. RFC 4627 dan RFC 7159 tetap berguna untuk memahami bagaimana definisi yang dipublikasikan berubah, terutama di tingkat atas. Kutip dokumen yang mendukung klaim yang sebenarnya daripada menggunakan “spesifikasi JSON” sebagai permohonan yang tidak jelas kepada pihak berwenang, dan bedakan aturan normatif dari perilaku implementasi yang diamati dalam parser tertentu.
Untuk ToolAcre, pernyataan yang dapat dipertahankan adalah bahwa repositori menggunakan parser dan serializer JavaScript JSON dan menambahkan pemindai lokal yang ketat untuk diagnostik setelah kegagalan. Pengujian nilai tingkat atas, tanda baca yang salah, dan penanganan angka menjelaskan rute tersebut; itu bukan sumber sejarah.