Konverter XML ke JSON Gratis

Apa itu XML?

XML (Extensible Markup Language) adalah format untuk menyimpan dan mengangkut data. Ini menggunakan tag kustom untuk menggambarkan struktur data, membuatnya mudah dibaca manusia dan didukung secara luas. Tidak seperti JSON, XML dapat menyertakan atribut pada elemen.

Mengapa Mengonversi XML ke JSON?

• Ukuran file lebih kecil · JSON lebih ringkas daripada XML.
• API Web · Sebagian besar layanan web modern menggunakan JSON daripada XML.
• Penguraian lebih mudah · JSON memetakan langsung ke objek JavaScript.
• Integrasi sistem lawas · Konversi data XML lama ke format JSON modern.

Pertanyaan yang Sering Diajukan

Bagaimana atribut XML ditangani?

Atribut XML dikonversi menjadi properti JSON dengan awalan @ (mis. @id, @href). Ini melestarikan informasi atribut dalam struktur JSON.

Bagaimana dengan namespace?

Namespace dipertahankan dalam output. Awalan disertakan dalam nama elemen (mis. "ns:element").

Bisakah saya mengonversi JSON kembali ke XML?

Alat ini mengonversi XML ke JSON. Untuk kebalikannya, Anda dapat menggunakan konverter JSON ke XML kami.

Dua format, tiga dekade terpisah

XML 1.0 menjadi Rekomendasi W3C pada 10 Februari 1998. Editor aslinya adalah Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft), dan C. M. Sperberg-McQueen (Universitas Illinois di Chicago); Kelompok Kerja diketuai oleh Jon Bosak dari Sun Microsystems. Garis keturunan XML bermula dari SGML (ISO 8879:1986), standar penandaan dokumen yang sendirinya berkembang dari GML IBM pada tahun 1970-an. SGML kuat tetapi menakutkan; brief desain XML adalah «desain versi 'lite' dari SGML», memangkas fitur opsional ke profil yang dapat diimplementasikan dalam beberapa ribu baris kode sambil mempertahankan Unicode, namespace, dan dokumen kaya-atribut.

JSON (JavaScript Object Notation) ditemukan, bukan dirancang. Douglas Crockford dan Chip Morningstar mengirim pesan JSON pertama pada April 2001 di State Software, memperoleh format dari sintaks object-literal JavaScript. Crockford mendaftarkan json.org pada tahun 2002 dan membuat spec satu halaman. Format ini pertama kali diformalkan sebagai RFC 4627 pada Juli 2006, diterbitkan ulang sebagai RFC 7159 pada tahun 2014, dan distabilkan sebagai RFC 8259 / STD 90 pada Desember 2017, tahun yang sama ECMA-International menerbitkan ECMA-404. Maksud desain JSON (dari retrospektif Crockford): minimal, independen dari bahasa, mudah dibuat dan di-parse, tidak ada nomor versi («tidak ada nomor versi»), dan sengaja tanpa komentar («Saya menghapus komentar karena saya melihat orang menggunakannya untuk menyimpan direktif parsing»).

JSON mengambil alih API web pada akhir tahun 2000-an saat REST menggantikan SOAP dan saat XMLHttpRequest memberi jalan ke JSON-over-fetch. Pada tahun 2015 JSON adalah format respons default dari hampir setiap API publik; XML bertahan di SOA enterprise long-tail, format dokumen (Office Open XML, OpenDocument), dan ceruk-ceruk yang terikat standar.

Di mana XML dan JSON berbeda

	XML	JSON
Atribut	Kelas pertama (<item id="5"/>)	Tidak ada atribut, semuanya adalah pasangan kunci/nilai
Namespace	Native (xmlns:prefix="uri")	Nama datar; tabrakan prefiks adalah masalah aplikasi
Komentar	<!-- … -->	Tidak ada per spec
Konten campuran	Native (<p>text <b>and</b> markup</p>)	Canggung, membutuhkan array atau serialisasi string
Skema	DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron	JSON Schema (spec komunitas, draft 2020-12)
Urutan	Urutan elemen signifikan per spec	Urutan kunci objek tidak dijamin (sebagian besar parser mempertahankan urutan penyisipan dalam praktik); array berurutan
Angka	String sampai diketik oleh skema	IEEE 754 double; tidak ada perbedaan integer/float di tingkat spec
Verbositas	Tinggi (setiap nilai dibungkus dalam tag	Rendah) hanya tanda baca

Mengapa XML→JSON secara fundamental bersifat lossy

Tidak ada pemetaan kanonik yang diberkati W3C dari XML ke JSON. Setiap konverter harus menemukan jawaban atas pertanyaan yang dapat Anda ekspresikan dalam XML tetapi JSON tidak memiliki kosakata native untuk itu. Keputusan yang berulang:

• Atribut vs elemen anak: XML memungkinkan Anda mengekspresikan data yang sama dengan kedua cara. JSON hanya memiliki satu gagasan (kunci pada objek), sehingga konverter harus menemukan penanda. Konvensi umum: BadgerFish menggunakan @ untuk atribut dan $ untuk teks; Parker membuang atribut sepenuhnya (lossy tetapi sederhana); JsonML merepresentasikan elemen sebagai array dengan tag tipe (mempertahankan urutan dan struktur); GData / Newtonsoft / xml2js menggunakan sub-objek @attributes ditambah kunci #text saat diperlukan. Konverter ini mengikuti konvensi gaya GData: atribut di bawah @attributes, teks konten-campuran di bawah #text, anak berulang menjadi array.
• Elemen anak berulang: jika konverter secara buta membuat satu kunci per anak, anak kedua menimpa yang pertama. Perbaikan standar: deteksi pengulangan dan pancarkan array. Tetapi ini berarti bentuk JSON bergantung pada data, satu <book> menghasilkan string, dua menghasilkan array string. Beberapa konsumen menginginkan bentuk array bahkan untuk satu item; beberapa konverter mengekspos toggle «always-array» untuk nama elemen tertentu.
• Konten campuran: <p>Hello <b>world</b>!</p> mencampurkan teks dan elemen dengan urutan yang signifikan. JSON tidak dapat secara native mengekspresikan interleaving tersebut tanpa array bertipe campuran atau kunci sentinel #text. Banyak konverter membuang prosa di antara elemen; yang lebih konservatif membaginya menjadi beberapa entri text-node.
• Namespace: <soap:Envelope xmlns:soap="…"> memiliki prefiks dan URI binding. Sebagian besar konverter mempertahankan prefiks sebagai bagian dari kunci JSON (soap:Envelope) dan membuang binding, yang baik-baik saja selama konsumen tidak perlu me-resolve namespace.
• Komentar dan instruksi pemrosesan: biasanya dibuang secara diam-diam, karena JSON tidak memiliki sintaks komentar.
• Bagian CDATA: diratakan menjadi string biasa; wrapper <![CDATA[…]]> hilang.
• Spasi kosong: XML memiliki xml:space="preserve" untuk spasi kosong yang signifikan; JSON tidak memiliki padanannya. Sebagian besar konverter memangkas text node yang hanya-spasi di antara elemen.

Kapan Anda akan menggunakan ini

• Mengonsumsi layanan SOAP legacy dari frontend JS modern. Respons SOAP adalah XML; mengonversi sekali di batas memungkinkan sisa aplikasi bekerja dalam JSON.
• Pemrosesan feed RSS / Atom: keduanya adalah format XML; pembaca berita dan agregator modern biasanya menginginkan JSON.
• Sitemap XML (sitemap.xml), mengonversi ke JSON membuatnya lebih mudah diperiksa dan diproses secara terprogram.
• Data OSM OpenStreetMap: diterbitkan sebagai XML, sering diperlukan sebagai JSON untuk pemetaan sisi klien.
• File KML / GPX Google Earth: format data geografis yang hadir dalam XML.
• Internal Office Open XML: .docx, .xlsx, dan .pptx adalah file XML yang dizip; jika Anda telah mengekstraknya dan ingin memeriksa strukturnya sebagai JSON, ini adalah langkah konversi.
• Manipulasi SVG: SVG adalah XML. Mengonversi ke JSON membuatnya lebih mudah untuk menavigasi dan memutasi pohon dalam JavaScript sebelum serialisasi ulang.
• Maven POM, file build Ant, konfigurasi Spring, resource Android, plist Apple, data keuangan XBRL, rekam medis HL7, MusicXML, dokumen hukum NMX: format XML long-tail yang sering membutuhkan JSON untuk tooling downstream.

Alternatif modern

• API JSON native. Jika layanan upstream menawarkan varian JSON, ambillah. Layanan SOAP biasanya tidak tetapi sebagian besar padanan modernnya menawarkan.
• GraphQL. Bahasa query yang memungkinkan klien meminta bentuk JSON yang tepat yang dibutuhkan dari skema bertipe.
• Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Format serialisasi biner dengan skema dan ukuran wire jauh lebih kecil dari XML atau JSON. Umum di dalam mesh microservice; jarang digunakan di batas browser karena membutuhkan library decoding eksplisit.
• Tetap dalam XML. Jika datanya benar-benar berorientasi dokumen (konten campuran, struktur bertipe yang dalam, validasi skema yang penting), XML adalah pilihan yang lebih baik. Kekuatan JSON adalah data berbentuk API; kesetiaan dokumen bukan keahliannya.

Pertanyaan lainnya

Mengapa XML yang sama menghasilkan bentuk JSON yang berbeda di alat yang berbeda?

Karena tidak ada pemetaan XML→JSON kanonik. Setiap konverter memilih konvensi (BadgerFish, Parker, JsonML, gaya GData) dan bentuk JSON yang dihasilkan berbeda dalam cara atribut ditandai, cara konten campuran dipertahankan, dan cara anak berulang di-array. Round-trip XML melalui konverter yang berbeda menghasilkan JSON yang berbeda; round-trip JSON kembali ke XML melalui konverter yang berbeda dapat mengubah penempatan atribut dan bahkan urutan elemen. Untuk interoperabilitas, dokumentasikan konvensi yang Anda gunakan dan pertahankan.

Bagaimana dengan CDATA, komentar, dan instruksi pemrosesan?

Bagian CDATA (<![CDATA[…]]>) diratakan menjadi konten string biasa, wrapper hilang, tetapi teks di dalamnya dipertahankan verbatim. Komentar XML (<!-- … -->) dan instruksi pemrosesan (<?xml-stylesheet …?>) dibuang, karena JSON tidak memiliki sintaks untuk keduanya. Jika Anda membutuhkan kesetiaan round-trip yang mempertahankan komentar, pendekatan round-trip hanya-XML adalah cara yang tepat.

Apakah skema XML (XSD) saya akan bertahan dari konversi?

Tidak. XSD mendeskripsikan struktur dan tipe XML; JSON Schema adalah standar yang analogous (terpisah) untuk JSON. Beberapa tooling lanjutan dapat menerjemahkan XSD ke JSON Schema, tetapi ini adalah operasi lossy, XSD memiliki fitur (konten campuran, substitution group, derived type) yang tidak memiliki padanan JSON Schema yang bersih. Untuk validasi dokumen yang penting, jalankan XSD terhadap XML asli, bukan terhadap konversi JSON.

Mengapa JSON menang untuk API web?

Beberapa alasan. JSON memetakan langsung ke objek JavaScript, sehingga parsing sisi browser hanya satu panggilan JSON.parse() jauhnya. Format ini jauh lebih kecil, tanpa closing tag, tanpa deklarasi namespace, tanpa bobot skema. REST menggantikan SOAP untuk sebagian besar API publik pada akhir tahun 2000-an, dan JSON adalah payload alami untuk REST. Kekuatan XML (skema ketat, namespace, konten campuran) penting untuk dokumen dan sistem enterprise legacy tetapi jarang untuk «berikan objek pengguna kepada saya». Web dioptimalkan untuk kasus yang lebih sederhana.

Apakah ada yang dikirim ke server?

Tidak. XML di-parse oleh DOMParser native browser, kemudian dijelajahi secara rekursif dalam JavaScript untuk membangun keluaran JSON. XML yang ditempel tidak pernah meninggalkan halaman. Alat ini berfungsi secara offline setelah dimuat, yang penting ketika XML sumber mengandung endpoint API internal, data pelanggan, atau skema kepemilikan yang sebaiknya tidak Anda unggah ke mana pun.

Alat Terkait