Validator JSON Gratis

Tentang validasi JSON

Validator JSON menjawab pertanyaan biner, apakah ini dokumen JSON yang well-formed?, dengan menyerahkan input ke parser yang sama yang digunakan browser secara internal dan melaporkan apakah itu menerima sintaks. Alat ini melakukan hal itu dan hanya itu. Itu tidak memeriksa apakah data di dalam dokumen berarti apa yang Anda maksudkan. Pertanyaan kedua itu, apakah dokumen memiliki bentuk, tipe, dan kendala yang diharapkan aplikasi Anda?, adalah validasi skema, wilayah alat seperti Ajv (dibahas di bawah). Dua aktivitas saling melengkapi dan menjawab pertanyaan yang berbeda; menggunakan satu ketika Anda menginginkan yang lain adalah kesalahan kategori. Analogi yang berguna adalah perbedaan spelling-check / grammar-check di word processor: spelling check (sintaks) memberi tahu Anda apakah setiap kata adalah kata yang nyata; grammar check (skema) memberi tahu Anda apakah kalimat masuk akal; keduanya berguna, tidak ada yang menggantikan yang lain, dan tidak ada yang memberi tahu Anda apakah esai itu bagus. {"phoneNumber": 12345} adalah JSON well-formed, tetapi jika aplikasi Anda mengharapkan string yang diformat sebagai "+1-555-555-1234", itu salah, dan validator sintaks tidak dapat memberi tahu.

Di luar pemeriksaan sintaks, alat ini juga menawarkan pass "Perbaiki masalah umum" best-effort yang menulis ulang empat cara paling sering developer secara tidak sengaja menulis JSON yang tidak valid: trailing comma, string dengan kutipan tunggal, kunci tanpa kutipan, dan literal undefined (ditulis ulang menjadi null). Ini adalah heuristik, bukan parser, jadi selalu tinjau output yang dikoreksi sebelum mengadopsinya.

Sejarah Singkat JSON

JSON memiliki biografi yang sangat singkat. Akronim diciptakan di State Software, Inc., sebuah konsultansi kecil yang Douglas Crockford dan Chip Morningstar dirikan bersama pada Maret 2001 untuk membangun apa yang nantinya disebut aplikasi web Ajax. Pesan JSON pertama dikirim pada April 2001 dari komputer di garasi Morningstar di Bay-Area. Crockford tidak mengklaim telah menemukan JSON, format itu sudah ada di dalam bahasa JavaScript sebagai subset literal objek; kontribusinya adalah mengupasnya, memberinya nama, mendirikan situs web (json.org online pada 2002 dengan deskripsi tata bahasa dalam tiga notasi dan parser referensi JavaScript), dan melobi untuk adopsi. Desember 2005 adalah momen yang dirujuk sebagian besar sejarawan sebagai JSON menyeberang ke arus utama: pada bulan itu, Yahoo! mulai menawarkan beberapa layanan webnya dalam JSON. IETF mengambilnya berikutnya: RFC 4627 ("The application/json Media Type for JSON"), ditulis oleh Crockford sendiri, diterbitkan pada Juli 2006 sebagai dokumen informatif, bukan Standards Track. Badan standar mengejar pada 2013-2014: ECMA-404 edisi pertama pada Oktober 2013 (sengaja minimal, enam halaman konten substantif), RFC 7159 pada Maret 2014 (melonggarkan pembatasan tingkat atas sehingga nilai JSON apa pun, bukan hanya objek dan array, dapat menjadi dokumen lengkap), dan pasangan saat ini pada Desember 2017: RFC 8259 (sekarang Internet Standard STD 90) dan ECMA-404 edisi kedua disejajarkan secara normatif. Keduanya berikatan: masing-masing merujuk satu sama lain secara normatif dan berisi komitmen untuk menjaga mereka konsisten. Juga diterbitkan sebagai ISO/IEC 21778:2017.

Tata Bahasa JSON dalam 200 Kata

Dokumen JSON adalah nilai tunggal, opsional dikelilingi oleh whitespace. Ada tepatnya enam tipe nilai: objek, kumpulan tidak berurutan dari nol atau lebih pasangan nama/nilai, ditulis {"k": v, "k2": v2}; array, urutan terurut, [v, v2, v3] (array mempertahankan urutan menurut spec); string, urutan karakter Unicode yang dibungkus dalam kutipan ganda (kutipan tunggal tidak diizinkan; backslash escape \", \\, \/, \b, \f, \n, \r, \t ditambah \uXXXX; karakter kontrol U+0000 hingga U+001F harus di-escape); angka, bentuk ASCII ketat (tanda minus opsional, bagian bilangan bulat tanpa angka nol di depan, bagian fraksional opsional, eksponen opsional dengan e atau E); true / false, boolean JSON, hanya huruf kecil; null, ketiadaan nilai, hanya huruf kecil. Whitespace di antara token diizinkan dan diabaikan. Tidak ada komentar. Tidak ada trailing comma. Kunci objek harus berupa string kutipan ganda. Tata bahasa muat dalam satu halaman. Bentuk angka ketat melarang hex (0xFF), oktal (0777), tanda +, Infinity, NaN, dan titik desimal trailing seperti 1.; ini menangkap siapa saja yang menulis JSON dengan tangan di lingkungan yang menerima bentuk numerik ECMAScript yang lebih longgar, paling umum, siapa saja yang pernah menempelkan kode warna hex ke dalam file JSON.

Mengapa Tata Bahasa Begitu Ketat, Pilihan Desain Crockford

Dua kelalaian yang disengaja menjelaskan sebagian besar gesekan yang dirasakan pengguna saat menulis JSON dengan tangan. Tidak ada komentar. JavaScript memiliki komentar // dan /* */; JSON, subset JavaScript, tidak memiliki keduanya. Alasan yang dinyatakan Crockford, diposting di Google+ pada 2012, telah dikutip ribuan kali sejak: "Saya menghapus komentar dari JSON karena saya melihat orang menggunakannya untuk menyimpan direktif parsing, sebuah praktik yang akan menghancurkan interoperabilitas. Saya tahu kekurangan komentar membuat beberapa orang sedih, tetapi seharusnya tidak." Argumennya adalah bahwa komentar mengundang perpanjangan, jika // @schema foo.json ada di config Anda dan alat Anda membacanya, maka file config Anda bukan lagi JSON. Tidak ada trailing comma. Koma adalah pemisah, bukan terminator. [1, 2, 3] legal tetapi [1, 2, 3,] tidak. Alasannya sama dengan komentar: kesederhanaan tata bahasa dan keseragaman di seluruh parser. Biayanya adalah siapa pun yang mengedit objek JSON multi-baris, menambahkan properti, menyusun ulang properti, menghapus properti terakhir, harus memikirkan koma. Tidak ada undefined. JavaScript memiliki undefined; JSON tidak. Gunakan null atau hilangkan properti sepenuhnya. BOM dalam input. Byte-order mark (U+FEFF) di awal dokumen JSON dilarang dalam JSON yang ditransmisikan, tetapi parser BOLEH mengabaikan satu jika muncul. Dalam praktik, file yang disimpan sebagai "UTF-8 dengan BOM" oleh editor Windows yang lebih lama secara diam-diam merusak beberapa parser dan secara diam-diam berfungsi di yang lain.

Kesalahan JSON yang umum:

• Koma trailing: elemen terakhir dalam objek atau array tidak boleh memiliki koma
• Tanda kutip tunggal alih-alih ganda: JSON hanya mengizinkan tanda kutip ganda untuk string
• Kunci tanpa tanda kutip: kunci objek harus selalu dalam tanda kutip ganda
• Komentar: JSON tidak mendukung komentar (meskipun beberapa alat menerimanya)
• Backslash tidak di-escape. Di dalam string JSON, \ adalah karakter escape. "C:\Users\Alice" gagal karena \U dan \A bukan escape yang dikenali. Obatnya adalah menggandakan setiap backslash: "C:\\Users\\Alice".
• Karakter kontrol tidak di-escape. Baris baru literal, tab, atau karakter lain di U+0000-U+001F di dalam string JSON dilarang. Sebagian besar pengguna mengalami ini ketika mereka menempelkan string multi-baris ke nilai JSON tanpa meng-escape baris baru sebagai \n.
• NaN dan Infinity. Bukan bagian dari tata bahasa JSON. JSON.parse browser akan menolaknya. JSON.stringify menghasilkan null ketika diminta untuk menserialisasi NaN atau Infinity, jadi round-trip secara diam-diam kehilangan informasi.
• Input kosong. Melempar "Unexpected end of JSON input." Jebakannya adalah respons HTTP yang kembali dengan Content-Type: application/json tetapi body kosong menghasilkan kesalahan ini dalam rantai fetch().then(r => r.json()).

JSON Schema, Standar untuk Validasi Bentuk

JSON Schema adalah kosakata berbasis JSON untuk menggambarkan struktur dan kendala dokumen JSON. Proposal pertama diajukan oleh Kris Zyp pada Oktober 2007; seri IETF Internet-Draft dimulai dengan draft-zyp-json-schema-00 pada 5 Desember 2009. Draf berturut-turut berkembang melalui setengah lusin penulis dan editor selama dekade dan setengah berikutnya. Versi stabil saat ini adalah draft 2020-12 (nama "2020-12" mengacu pada snapshot pengembangan dari mana ia diturunkan; rilis formal sebenarnya adalah 16 Juni 2022). Empat kata kunci assertion yang paling banyak digunakan menanggung sebagian besar pekerjaan harian: type (membatasi nilai ke salah satu dari enam tipe JSON atau daftar tipe yang dapat diterima), required (daftar nama properti yang harus dimiliki objek), properties (peta nama properti ke sub-skema untuk nilai), dan items (skema diterapkan ke setiap elemen array). Dikombinasikan dengan minimum, maximum, minLength, maxLength, pattern (regex), format (date-time, email, IPv4, dll.) dan kata kunci komposit (allOf, anyOf, oneOf, not), JSON Schema dapat mengekspresikan hampir semua kendala "bentuk" yang harus dipenuhi data Anda. Skema itu sendiri adalah dokumen JSON, yang rekursif dengan cara yang sebagian orang merasa elegan dan sebagian merasa memusingkan.

Ajv, Validator Skema JavaScript yang Dominan

Jika Anda ingin melakukan validasi skema di JavaScript, jawaban kanonik adalah Ajv (Another JSON Schema Validator) oleh Evgeny Poberezkin. Triknya adalah mengompilasi skema ke JavaScript yang dioptimalkan: alih-alih berjalan melalui skema dan pohon data pada runtime, ia menghasilkan fungsi yang mengkodekan setiap pemeriksaan dan berjalan dengan kecepatan native. Ini membuatnya jauh lebih cepat daripada validator naif pada dokumen besar dan pada jalur validasi panas. Ajv mendukung draf JSON Schema 04, 06, 07, 2019-09 dan 2020-12; ini adalah validator yang built-in di express-validator, validasi permintaan AWS API Gateway dan banyak framework Node.js utama. Untuk Python, pilihan kanonik adalah jsonschema oleh Julian Berman; untuk Java, json-schema-validator Networknt. Poinnya adalah bahwa validasi skema adalah masalah yang terpecahkan, matang, dan diperlengkapi dengan baik, tetapi ini adalah masalah yang harus Anda ikut serta dengan menulis skema. Alat ini tidak menulis skema untuk Anda; ia hanya melakukan validasi sintaktis.

JSON5 dan JSONC, Superset yang Longgar

JSON5 adalah superset formal JSON yang dispesifikasikan di json5.org, awalnya dirancang oleh Aseem Kishore pada 2012 dan sekarang dipelihara oleh Jordan Tucker. Ini mengizinkan segala sesuatu yang dilarang JSON ketat: komentar (baik // dan /* */), trailing comma, string kutipan tunggal, kunci objek tanpa kutipan (ketika mereka adalah pengidentifikasi ECMAScript yang valid), angka heksadesimal, titik desimal awal/akhir (.5 atau 5.), Infinity dan NaN, dan angka bertanda. Dokumen JSON5 biasanya menggunakan ekstensi .json5 dan diparsing oleh pustaka seperti paket npm json5. JSONC adalah mode informal "JSON dengan Komentar" Microsoft, digunakan dalam file pengaturan VS Code (settings.json, launch.json, tasks.json). Komentar diizinkan oleh spec; trailing comma ditoleransi oleh parser referensi tetapi ditandai dengan peringatan. Bentuk longgar untuk file konfigurasi yang diedit manusia di mana disiplin JSON ketat menghalangi; untuk pertukaran data mesin-ke-mesin, JSON ketat masih merupakan pilihan yang tepat. Alat ini menggunakan JSON.parse ketat browser dan akan menolak keduanya, lepaskan komentar dan trailing comma sebelum menempel, atau gunakan parser JSON5/JSONC untuk dikonversi ke JSON ketat terlebih dahulu.

Validator Streaming untuk Input Sangat Besar

JSON.parse browser memuat seluruh dokumen ke dalam memori sebagai pohon objek tunggal. Untuk sebagian besar input ini baik-baik saja; untuk file log, ekspor API multi-gigabyte atau dump data sensor, tidak. Pendekatan streaming adalah mengonsumsi dokumen sebagai aliran token dan memancarkan peristiwa ("mulai array", "nilai string", "kunci objek") tanpa pernah menahan seluruh struktur di memori sekaligus. clarinet oleh Marak Squires adalah parser JSON streaming Node.js kanonik, dimodelkan pada pola parser SAX XML. Oboe.js oleh Jim Higson (berasal dari disertasinya pada 2013) adalah ekuivalen yang ramah-browser, dirancang untuk mengonsumsi JSON melalui fetch saat streaming masuk dan memancarkan peristiwa untuk setiap JSONPath yang cocok; itu tidak lagi dipelihara secara aktif tetapi teknik yang dipeloporinya masih berguna. JSONStream di npm membungkus clarinet untuk penggunaan Node yang ramah pipe. Alat browser murni seperti ini dibatasi oleh memori yang tersedia; jika Anda memvalidasi JSON skala gigabyte, jalankan parser streaming di Node atau gunakan jq --stream di command line.

Di Mana Validasi JSON Penting dalam Alur Kerja Nyata

File konfigurasi adalah kasus dengan leverage tertinggi: tsconfig.json, package.json, config ESLint dan Prettier, Docker Compose, kebijakan AWS IAM. Satu karakter tidak valid dapat merusak build; validator sintaks menangkapnya sebelum build melakukannya. Respons API berikutnya: mengembangkan terhadap API eksternal sering kali berarti menatap payload dan bertanya "apakah benda ini sebenarnya JSON yang valid?" sebelum mengejar bug parsing lebih dalam dalam kode. Payload webhook, peristiwa Stripe, pemicu GitHub Actions, incoming webhooks Slack, adalah JSON; tempel-dan-validasi cepat menangkap kasus di mana tanda tangan yang salah atau byte yang nyasar telah merusak body. Entri log (Splunk, Datadog, log terstruktur Loki) adalah JSON yang dibatasi baris; satu baris buruk merusak seluruh pipeline ingest. File JSON yang dihasilkan (lockfile, manifest build, fixture pengujian) kadang-kadang melayang dalam cara berisik selama pengembangan normal; validator sintaks menangkap kasus di mana langkah generasi itu sendiri gagal.

Batasan Jujur dari Validator Hanya-Sintaks

Validator sintaks tidak dapat menangkap kesalahan logika. Itu tidak dapat memberi tahu Anda bahwa field "nomor telepon" berisi bilangan bulat alih-alih string; bahwa string "tanggal" salah bentuk tetapi kebetulan merupakan string yang valid; bahwa field yang diperlukan hilang; bahwa angka yang seharusnya positif adalah negatif; bahwa dua field yang seharusnya cocok tidak cocok. Semua itu adalah masalah validasi skema. Pipeline yang tepat untuk sistem produksi adalah: (1) validasi sintaks sebagai gerbang pertama, apakah ini parse sebagai JSON sama sekali? (2) validasi skema sebagai gerbang kedua, apakah memiliki bentuk yang Anda harapkan? (3) validasi logika bisnis sebagai gerbang ketiga, apakah data masuk akal mengingat keadaan lain? Alat ada untuk ketiga lapisan; ini menangani hanya yang pertama. Keuntungan menempelkan payload ke validator sintaks terlebih dahulu adalah bahwa itu mengisolasi mode kegagalan yang paling murah dan paling umum (koma yang nyasar, brace yang hilang) dari kesalahan skema yang lebih mahal yang sebaliknya akan menenggelamkan mereka.

Privasi: Mengapa Browser-Saja Penting di Sini

Validasi JSON pada server memerlukan unggahan dokumen. Untuk contoh data publik biasa ini tidak berbahaya. Untuk respons API yang berisi token autentikasi, PII pelanggan, catatan karyawan internal, rahasia konfigurasi, atau data produk yang belum dirilis, tidak. Bahkan dengan kebijakan penghapusan paling teliti, unggahan tetap berada di log server, mungkin di cache CDN, mungkin di pipeline analitik, mungkin di backup. Alat ini menjalankan JSON.parse di browser Anda melalui JavaScript. Dokumen yang ditempel tidak pernah melintasi jaringan, verifikasi di tab Network DevTools saat Anda mengklik tombol, atau bawa halaman offline (mode pesawat) setelah dimuat dan konfirmasi validator masih berfungsi. Aman untuk memvalidasi payload webhook dengan rahasia, respons API dengan header autentikasi, file konfigurasi dengan kredensial database, atau JSON lain yang tidak ingin Anda salin ke hard drive orang asing.

Pertanyaan yang Sering Diajukan

Apa itu JSON yang valid?

JSON yang valid harus berupa salah satu jenis ini: objek ({}), array ([]), string (""), angka, boolean (true/false), atau null. Semua string dan kunci objek harus menggunakan tanda kutip ganda. Angka tidak boleh memiliki nol di depan. Spasi diperbolehkan di antara elemen.

Apa fungsi «Perbaiki masalah umum»?

Perbaikan mencoba memperbaiki kesalahan umum secara otomatis: koma di akhir, apostrof yang dikonversi menjadi tanda kutip ganda, kunci tanpa tanda kutip, dan nilai undefined yang dikonversi menjadi null. Ini adalah alat heuristik yang mungkin tidak memperbaiki semuanya, tinjau hasilnya dengan cermat.

Bagaimana memvalidasi JSON di aplikasi saya?

Di JavaScript: gunakan JSON.parse() dan tangkap kesalahan. Di Node.js: fs.readFileSync() + JSON.parse(). Di Python: json.loads() atau json.load(). Sebagian besar bahasa memiliki pustaka JSON bawaan.

Bisakah saya memvalidasi JSON5 atau JSONC (JSON dengan komentar)?

Tidak secara langsung. Alat ini menggunakan JSON.parse ketat browser, yang mengikuti RFC 8259, komentar, trailing comma, kutipan tunggal dan kunci tanpa kutipan adalah kesalahan sintaks. Jika input Anda adalah JSON5 (json5.org, Aseem Kishore 2012, dipelihara oleh Jordan Tucker) atau JSONC VS Code, instal paket npm json5 atau paket jsonc-parser, konversi ke JSON ketat, lalu validasi. Pass "Perbaiki masalah umum" menangani subset dari perbedaan tetapi bukan parser JSON5 / JSONC lengkap.

Apakah ada batas ukuran?

Tidak ada batas keras, tetapi JSON.parse browser memuat seluruh dokumen ke dalam memori sebagai pohon objek tunggal. Puluhan ribu baris berfungsi dengan nyaman; dump log multi-gigabyte akan menghabiskan memori. Untuk JSON yang sangat besar, jalankan parser streaming seperti clarinet (Marak Squires) atau Oboe.js (Jim Higson, 2013), atau gunakan jq --stream di command line, yang dapat memproses dokumen ukuran sembarang tanpa pernah memuat seluruhnya.

Apakah dokumen JSON saya diunggah?

Tidak. JSON.parse berjalan di browser Anda melalui JavaScript. Dokumen yang ditempel tidak pernah melintasi jaringan, verifikasi di tab Network DevTools saat Anda mengklik Validate, atau bawa halaman offline setelah dimuat dan konfirmasi alat masih berfungsi. Aman untuk memvalidasi payload webhook dengan rahasia, respons API dengan header autentikasi, atau file konfigurasi dengan kredensial database.