JSON Tree Penampil

JSON, format data yang menang

Douglas Crockford menerbitkan JSON di json.org pada 2001 sebagai alternatif ringan untuk XML, menarik sintaksnya langsung dari literal objek JavaScript. Format pertama kali distandardisasi sebagai IETF Internet-Draft di RFC 4627 (Juli 2006), kemudian direvisi sebagai RFC 7159 (Maret 2014), dan akhirnya ditetapkan di RFC 8259 (Desember 2017), yang merupakan standar saat ini dan dijaga selaras dengan ECMA-404 (edisi 1 Oktober 2013, edisi 2 Desember 2017). RFC 8259 menambahkan satu persyaratan signifikan: pengkodean lapisan jaringan harus UTF-8. Dua spesifikasi pelengkap menyempurnakan ekosistem: RFC 6901 «JSON Pointer» (April 2013) mendefinisikan sintaks /store/book/0/title untuk mengalamatkan node di dalam dokumen, dan RFC 6902 «JSON Patch» mendefinisikan dokumen JSON yang menggambarkan perubahan untuk diterapkan ke dokumen JSON lain. JSON Schema (draft IETF saat ini 2020-12) menambahkan validasi. Semua yang lain dibangun di atasnya, JSONC untuk komentar file konfigurasi, JSON5 untuk sintaks longgar, NDJSON untuk streaming, datang kemudian.

Enam tipe nilai JSON (dan apa yang hilang)

RFC 8259 §3 mendefinisikan tepat enam tipe nilai. Tidak ada yang lain.

• objek: kumpulan tidak terurut pasangan nama-nilai dibatasi oleh kurung kurawal. Kunci selalu string.
• array: daftar nilai yang diurutkan dibatasi oleh kurung siku. Dapat berisi tipe campuran.
• string: karakter Unicode dalam tanda kutip ganda. Tanda kutip tunggal bukan JSON yang sah.
• angka: floating point presisi ganda IEEE 754. Spec tidak menjamin presisi sembarang; angka di luar Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9 007 199 254 740 991 kehilangan presisi saat di-parse.
• true / false: literal boolean, huruf kecil, tanpa kutip.
• null: literal null, huruf kecil, tanpa kutip. Kunci dengan nilai null berbeda dari kunci yang tidak ada.

Apa yang tidak dimiliki JSON: tipe tanggal (konvensi adalah string ISO 8601 dengan zona waktu), komentar (gunakan field metadata terpisah), koma akhir, string berkutip tunggal, angka heksadesimal, undefined, NaN, atau Infinity. Salah satunya akan membuat JSON.parse melempar SyntaxError.

JSON ketat, JSONC, JSON5: mana yang mana

JSON ketat (RFC 8259) adalah yang diterima viewer ini: tanpa komentar, tanpa koma akhir, kunci berkutip ganda, string berkutip ganda. JSONC adalah konvensi Microsoft yang dikirim dalam VS Code yang mengizinkan komentar baris // dan komentar blok /* ... */ sambil menjaga semuanya tetap ketat; Anda melihatnya di tsconfig.json, .vscode/settings.json, dan paket npm jsonc-parser. JSON5 (2017, https://json5.org) adalah superset yang menambahkan string berkutip tunggal, kunci tanpa kutip, koma akhir, angka heksadesimal, nilai khusus IEEE 754 (NaN, Infinity), dan komentar baris dan blok; paket npm json5 memiliki sekitar 10 juta unduhan mingguan. NDJSON / JSON Lines (https://jsonlines.org) adalah varian streaming di mana setiap baris adalah dokumen JSON independen, digunakan oleh pengirim log dan pipeline ingestion big-data. Hapus komentar dan koma akhir sebelum menempel jika sumber Anda adalah JSONC atau JSON5.

Di mana viewer pohon benar-benar mendapatkan gajinya

• Inspeksi respons API. Stripe, GitHub, Slack, Twilio: setiap API modern mengembalikan JSON bersarang. Menempel ke viewer pohon membuat bentuknya jelas.
• File konfigurasi. package.json, tsconfig.json, composer.json, kubeconfig, dan long tail dari config JSON penyedia cloud semuanya menjadi lebih mudah diaudit sebagai pohon.
• Inspeksi ekspor database. Output MongoDB find(), baris PostgreSQL row_to_json, daftar hit ElasticSearch.
• Penemuan skema. Ketika API tidak memiliki dokumentasi, viewer pohon adalah dokumentasinya.
• Persiapan diff. Sebelum menjalankan json-diff atau jq di antara dua file, inspeksi masing-masing di viewer untuk mengidentifikasi perbedaan yang jelas secara manual.
• Inspeksi payload webhook. Stripe, GitHub, SendGrid, dan layanan serupa semua mengirim webhook JSON. Menempel payload ke viewer adalah cara tercepat untuk memverifikasi apa yang akan diterima endpoint Anda.
• Pembuatan data sampel. Bangun fixture pengujian dengan mengetik JSON dan saksikan pohon diperbarui secara bertahap; menangkap kurung yang hilang sebelum Anda menyimpan file.

Kesalahan umum saat bekerja dengan JSON

• Koma akhir. {"a": 1,} adalah JavaScript yang sah tetapi JSON yang tidak sah. JSON.parse melempar SyntaxError: Unexpected token '}'. Hapus atau beralih ke JSON5.
• Komentar. // seperti ini atau /* seperti ini */ valid di JavaScript dan JSONC tetapi tidak di JSON ketat.
• Kehilangan presisi bilangan bulat besar. ID Twitter dan Stripe dapat melebihi 2⁵³; JSON.parse("9007199254740993") mengembalikan 9007199254740992. Terima mereka sebagai string jika presisi penting.
• Membingungkan null dengan tidak ada. {"foo": null} memiliki foo didefinisikan sebagai null; {} memiliki foo tidak terdefinisi. Perbedaan ini penting untuk kontrak API dan penanganan NULL database.
• Kunci duplikat. RFC 8259 mengatakan perilaku tidak terdefinisi; dalam praktik setiap mesin JS menyimpan nilai terakhir. {"a": 1, "a": 2} mem-parse sebagai {a: 2}.
• Referensi sirkular. JSON.stringify melempar TypeError: Converting circular structure to JSON. Ratakan siklus, gunakan replacer, atau gunakan library seperti flatted.
• String tanggal tanpa zona waktu. "2026-05-12" ambigu; "2026-05-12T18:30:00Z" adalah ISO 8601 yang jelas dalam UTC. Selalu sertakan offset.

Pertanyaan yang lebih sering diajukan

Seberapa besar file JSON yang dapat ditangani viewer ini?

Parsing 1 MB dengan JSON.parse memakan waktu sekitar 10 ms di V8. Merender 100.000 node DOM yang terlipat dapat membekukan browser selama beberapa detik. Dalam praktik, viewer ini nyaman hingga sekitar 5 MB; di luar itu, harapkan lag yang terlihat selama render. Untuk dokumen yang lebih besar, gunakan parser streaming seperti stream-json di Web Worker, atau paginasi input dalam potongan.

Mengapa bilangan bulat besar saya kembali salah?

Angka JavaScript adalah float presisi ganda IEEE 754. Bilangan bulat hingga 2⁵³ − 1 = 9 007 199 254 740 991 bertahan dalam round-trip dengan tepat; di luar itu, presisi hilang. ID snowflake Twitter (64-bit), ID pelanggan Stripe, ID transaksi blockchain, dan banyak kunci surrogate database melebihi batas ini. JSON.parse akan secara diam-diam memotong. Solusinya adalah menerima ID sebagai string (kebanyakan API modern melakukan ini) atau parse dengan library yang mendukung BigInt.

Apa itu JSON Pointer, dan di mana saya akan menggunakannya?

RFC 6901 (April 2013) mendefinisikan sintaks jalur untuk mengalamatkan node di dalam dokumen JSON: /store/book/0/title memilih judul buku pertama di array store. JSON Pointer adalah fondasi JSON Patch (RFC 6902), yang mengekspresikan delta dokumen sebagai array pasangan pointer-dan-operasi. Server API Kubernetes menggunakan JSON Patch untuk pembaruan inkremental; demikian juga API REST GitHub dan banyak sistem lainnya.

Apakah NDJSON / JSON Lines berfungsi di viewer ini?

Tidak. NDJSON adalah satu nilai JSON independen per baris, tanpa array pembungkus. JSON.parse pada seluruh file melempar karena baris kedua dimulai di mana objek pertama berakhir. Bungkus seluruh konten dalam [ dan ] dan ganti setiap baris baru antara objek dengan koma, atau tempel satu baris sekaligus, atau gunakan viewer NDJSON khusus.

Apakah JSON saya dikirim ke mana pun?

Tidak. JSON.parse berjalan di mesin JavaScript browser Anda, pohon dirender sebagai node DOM secara lokal, dan tidak ada salinan data Anda dikirim melalui jaringan. Ini aman untuk respons API dengan rahasia, data pelanggan, atau PII. Buka tab Jaringan di DevTools dan tempel sampel: Anda akan melihat nol permintaan keluar selama parsing dan rendering.