Pemformat JSON

Apa yang dilakukan pemformat JSON ini

JSON (JavaScript Object Notation) adalah format paling umum untuk memindahkan data terstruktur antarprogram — respons API, berkas konfigurasi, baris log, dan lainnya. Ia dirancang agar ringkas, yang juga membuatnya sulit dibaca begitu objek bersarang beberapa tingkat atau datang dalam satu baris. Alat ini mengambil JSON apa pun yang Anda tempel dan menulisnya ulang dengan dua cara: dipercantik, dengan indentasi konsisten sehingga strukturnya jelas sekilas, atau diperkecil, dengan setiap spasi opsional dibuang agar sekecil mungkin untuk dikirim melalui jaringan.

Ia juga memvalidasi saat memformat. Karena ia mengurai teksnya sebelum menyerialkannya ulang, JSON tak valid tak pernah menghasilkan keluaran yang menyesatkan — sebagai gantinya Anda mendapatkan baris dan kolom tempat penguraian gagal, di mana pun ia bisa menyimpulkannya, jadi Anda bisa langsung menuju masalahnya.

Percantik vs. perkecil — kapan memakai masing-masing

Kedua mode melayani tujuan yang berlawanan, dan kebanyakan alur kerja memakai keduanya pada tahap berbeda:

• Percantik ketika Anda membaca atau men-debug — memeriksa respons API, membandingkan dua payload, atau meninjau berkas konfigurasi dalam pull request. Indentasi mengubah dinding teks menjadi pohon yang bisa dijelajahi.
• Perkecil ketika Anda mengirim — menyematkan JSON dalam HTML, menyimpannya dalam kuki atau tembolok, atau mengirimnya dalam badan permintaan tempat setiap bita berarti. JSON yang diperkecil adalah data yang setara bita demi bita, hanya tanpa spasi.

Pemilih indentasi (2 spasi, 4 spasi, atau tab) hanya memengaruhi keluaran yang dipercantik. Dua spasi adalah konvensi paling umum dalam JavaScript dan perkakas web; empat spasi atau tab cocok bagi tim yang menyukainya. Yang mana pun Anda pilih, hasilnya tetap JSON yang valid — indentasi murni kosmetik.

Membaca galat validasi

Ketika JSON tak valid, alat ini melaporkan baris dan kolom masalah pertama alih-alih hanya "tak valid" — kecuali dalam satu kasus yang diuraikan bagian tentang ke mana baris dan kolom menunjuk. Pesan galat mesin berbeda antarperamban dan sering menghilangkan posisi, jadi lokasinya dihitung secara mandiri dan menunjuk tempat yang masuk akal untuk mulai mencari. Perbaiki galat pertama lalu periksa ulang — satu karakter tersasar sering beruntun menjadi beberapa masalah yang tampak.

Kesalahan JSON yang umum

JSON lebih ketat daripada literal objek JavaScript yang menyerupainya. Inilah galat yang paling sering menjebak orang:

• Koma di ujung: koma setelah item terakhir dalam objek atau larik valid di JavaScript tetapi tidak di JSON.
• Kutip tunggal: string dan kunci JSON harus memakai kutip ganda. 'value' tak valid; "value" benar.
• Kunci tanpa kutip: setiap kunci objek harus berupa string berkutip, jadi { name: "x" } harus menjadi { "name": "x" }.
• Komentar: JSON tak punya sintaksis komentar. // dan /* */ akan menyebabkan galat penguraian.
• Angka khusus: NaN, Infinity, dan -Infinity bukan angka JSON yang valid.
• Karakter kutip yang salah: “kutip pintar” yang ditempel dari pengolah kata tampak seperti kutip tetapi merupakan karakter berbeda dan tak akan terurai.

Ke mana baris dan kolom yang dilaporkan menunjuk

Posisinya bukan tempat Anda melewatkan sesuatu. Ia adalah tempat pengurai pertama kali menemui sesuatu yang secara sah tak boleh ada di situ, dan biasanya keduanya tempat yang berbeda. Pada objek di bawah, baris 3 kehilangan koma yang seharusnya menutupnya — dan alat ini melaporkan baris 4, kolom 3: kutip pembuka kunci berikutnya. Tak ada yang salah sampai kutip itu tiba, karena dokumen tadi sah saja berakhir setelah baris 3; jadi pengurai baru tahu ada yang terlewat ketika ia menemui sesuatu yang bukan koma dan bukan kurung kurawal penutup.

{
  "id": 42,
  "name": "widget"
  "price": 9.99
}

• Koma yang hilang dilaporkan di karakter pertama dari apa pun yang datang setelahnya, yang dalam JSON berindentasi seperti di atas adalah baris berikutnya: jadi bacalah baris yang disebut bersama baris di atasnya.
• Koma yang berlebih dilaporkan pada kurung penutup: baris 3, kolom 1 untuk objek yang pasangan terakhirnya ada di baris 2. Koma menjanjikan satu pasangan lagi, dan kurung itulah yang mematahkan janjinya.
• String yang tak ditutup biasanya dilaporkan di akhir baris tempat ia dibuka, bukan pada kutip pembuka, karena kutip berikutnya pada baris yang lebih jauh bisa menutupnya di tempat lain. Pergantian baris tak boleh muncul di dalam string JSON, jadi pergantian itulah karakter pertama yang tak boleh ada di situ.
• Baris 1, kolom 1 pada dokumen yang tampak sempurna biasanya berarti tanda urutan bita. Sebagian penyunting menuliskannya saat menyimpan sebagai UTF-8; ia tak terlihat, ia duduk sebelum kurung pembuka, dan JSON tak punya tempat untuknya.

Dan di tempat alat ini tak bisa menyimpulkan posisi sama sekali, ia melaporkan kegagalannya tanpa posisi alih-alih menyebut koordinat hasil terkaan. Baris dan kolom yang disebut dengan yakin tetapi menunjuk sintaksis yang sudah benar akan membuat Anda mencari di tempat yang salah, dan itu lebih buruk daripada hanya tahu bahwa dokumennya tak terurai.

Apa yang diubah pemformatan dan apa yang dipertahankannya

Untuk hampir setiap dokumen, jawabannya adalah spasi dan tak ada yang lain. Tetapi alat ini tak menyunting teks Anda: ia menguraikannya menjadi nilai sungguhan lalu menuliskan nilai-nilai itu kembali, dan lima hal tak selamat dari perjalanan bolak-balik itu. Tak satu pun adalah cacat alat ini — masing-masing adalah apa yang dikatakan spesifikasi JSON tentang angka atau objek — dan masing-masing pantas diketahui sebelum Anda menempelkan keluarannya di atas berkas asli Anda.

• Kunci yang sama ditulis dua kali: hanya yang terakhir dari keduanya yang selamat, karena objek tak bisa membawa satu kunci dua kali. RFC 8259 mengatakan perangkat lunak yang menerima objek dengan nama ganda berperilaku tak dapat diramalkan, dan pengurai lain bisa saja menyimpan yang pertama, jadi yang mana dari keduanya yang tinggal pun bukan hal yang bisa diandalkan.
• Bilangan bulat yang lebih panjang dari lima belas angka: angka JSON dibaca sebagai bilangan titik-kambang presisi ganda, yang memuat persis setiap bilangan bulat sampai dua pangkat lima puluh tiga — bilangan enam belas angka — jadi bilangan bulat lima belas angka selalu selamat dan yang lebih panjang mungkin tidak. Tempel 12345678901234567890 dan yang keluar 12345678901234567000. Pengenal basis data yang panjang adalah korban yang biasa: simpan sebagai string kalau bisa.
• Bentuk bereksponen dan bernol di ujung dinormalisasi: 1e3 kembali sebagai 1000, dan 1.50 sebagai 1.5. Itu angka yang sama, ditulis dengan cara standar.
• Besaran di luar yang bisa dibawa format itu kembali sebagai hal lain: 1e400 tak punya nilai presisi ganda dan kembali sebagai null, dan 1e-400 kembali sebagai 0. Pecahan desimal yang panjang dibulatkan ke presisi yang dimiliki format itu, sama seperti bilangan bulat yang panjang.
• Runtun escape menjadi karakter yang ditunjuknya: \u00e9 kembali sebagai é, dan pasangan pengganti ber-escape kembali sebagai emoji yang dirangkainya. Bagi pengurai mana pun keduanya string yang sama; satu dari dua penulisan itu hanya lebih pendek.

Urutan kunci dipertahankan seperti yang Anda tulis, dengan satu pengecualian yang pantas diketahui: kunci yang hanya berupa angka, terbaca sebagai bilangan bulat tak negatif yang biasa dan di bawah kira-kira empat miliar, diperlakukan sebagai indeks larik dan kembali ke depan objeknya dalam urutan angka, di mana pun Anda menaruhnya. Tak ada lagi yang bergeser: tak ada kunci lain yang ditata ulang, dan tak ada yang ditambahkan atau diganti nama. Kalau ada di antara ini yang penting bagi Anda, perkecil alih-alih mempercantik lalu bandingkan hasilnya dengan berkas asli Anda karakter demi karakter. Itu jalan terpendek untuk melihat apa yang dilakukan perjalanan bolak-balik itu.

Ketika JSON yang Anda cari ada di dalam string

Log webhook, antrean pesan, dan kolom basis data sangat sering membawa satu dokumen JSON utuh sebagai satu nilai string, dengan setiap kutip di dalamnya ber-escape. Dokumen luarnya valid sempurna, jadi alat ini mempercantiknya dan melaporkannya valid — dan bagian yang Anda datangi untuk dibaca tetap satu baris panjang garis miring balik. Tak ada yang keliru: itu dua dokumen, yang satu terbungkus di dalam string milik yang lain.

{
  "event": "order.created",
  "payload": "{\"id\":42,\"total\":19.99}"
}

Karena itu membacanya butuh dua lintasan. Format dokumen luarnya di sini, salin apa yang ada di antara kutip string yang Anda inginkan, urungkan escape-nya, lalu tempel hasilnya kembali. Alat Escape / unescape string JSON mengerjakan langkah tengah itu: arah unescape-nya mengubah \" kembali menjadi " dan barisnya kembali menjadi dokumen yang bisa diformat halaman ini. Kalau Anda mengendalikan apa pun yang menghasilkan berkas itu, perbaikan yang lebih baik ada di hulu: kirim payload sebagai objek bersarang, bukan sebagai string, dan tak satu lintasan pun diperlukan.

Satu objek per baris bukan satu dokumen

Berkas log, ekspor API, dan titik akhir aliran umumnya menyimpan satu objek JSON utuh per baris; formatnya disebut JSON Lines, atau NDJSON. Setiap baris adalah JSON yang valid sendiri, tetapi berkasnya bukan dokumen JSON, karena dokumen JSON menyimpan tepat satu nilai tingkat teratas dan berkas ini menyimpan beberapa, satu demi satu tanpa apa pun yang menyambungkannya.

{"level":"info","msg":"started"}
{"level":"warn","msg":"retrying"}
{"level":"error","msg":"gave up"}

Tempel itu di sini dan alat ini melaporkan baris 2, kolom 1: objek pertama berakhir dengan bersih, lalu yang kedua mulai di tempat dokumennya seharusnya sudah selesai. Dari situ ada dua jalan. Format satu baris sekali waktu, yang Anda inginkan ketika sedang membaca satu entri log. Atau jadikan berkasnya satu dokumen — bungkus barisnya dalam kurung siku dan taruh koma di akhir setiap baris kecuali yang terakhir — yang Anda inginkan ketika hendak memuat semuanya ke sesuatu yang mengharapkan larik.