JSON ke XML Konverter

JSON vs XML

XML (Extensible Markup Language) distandarisasi oleh W3C sebagai Recommendation pada 10 Februari 1998: spesifikasi W3C XML 1.0, diedit oleh Tim Bray, Jean Paoli, dan C.M. Sperberg-McQueen. XML tumbuh dari SGML ("Standard Generalised Markup Language" yang lebih lama, ISO 8879:1986) dengan menghilangkan fitur paling kompleks dan menghasilkan sesuatu yang dapat digunakan secara realistis oleh web. Untuk sekitar dekade pertama abad ke-21, XML adalah format yang diasumsikan untuk pertukaran data terstruktur apa pun: layanan web SOAP, feed RSS (RSS 2.0, Dave Winer, 2002), Atom (RFC 4287, 2005), format Open XML Microsoft Office (.docx/.xlsx/.pptx, ISO/IEC 29500:2008), tata letak XML Android, file properti Java, konfigurasi di hampir setiap framework server. Kekuatan XML adalah namespace, atribut, konten campuran (teks dan elemen anak yang diselingi), dan ekosistem skema yang kaya (DTD, XML Schema 1.1, Relax NG). Kelemahannya adalah verbositas: setiap nilai membawa tag buka dan tutup.

JSON (JavaScript Object Notation) dispesifikasikan oleh Douglas Crockford pada 2001: situs web json.org dan esai aslinya "JSON: The Fat-Free Alternative to XML." JSON sengaja dibuat sebagai subset dari sintaks literal objek JavaScript: object, array, string, angka, true/false/null. Distandarisasi sebagai RFC 4627 pada Juli 2006, disempurnakan sebagai RFC 7159 (Maret 2014) dan RFC 8259 (Desember 2017, standar STD 90 saat ini, juga diterbitkan oleh ECMA sebagai ECMA-404). Pengambilalihan API web JSON dari XML terjadi sekitar 2008-2014: waktunya cocok dengan kebangkitan aplikasi single-page dan era API mobile. Hari ini hampir setiap API publik mendokumentasikan dirinya sebagai JSON; XML sebagian besar bertahan dalam integrasi enterprise, format dokumen, file konfigurasi, dan format feed. Kedua format tetap dalam penggunaan aktif karena mereka mengkodekan hal-hal berbeda dengan baik: JSON tepat untuk data terstruktur dengan tipe sederhana dan bentuk yang dapat diprediksi; XML tepat untuk dokumen dengan konten campuran, atribut, namespace, dan skema yang ketat.

Kapan Anda Sebenarnya Perlu Mengonversi JSON ke XML

• Memanggil layanan web SOAP dari klien JSON-only. SOAP berbasis XML berdasarkan desain (envelope SOAP, deskripsi layanan WSDL, skema XSD). Jika Anda memiliki data dalam bentuk JSON dan perlu membuat body permintaan SOAP, JSON-to-XML adalah jembatannya. Umum dalam integrasi enterprise ketika microservice modern perlu berbicara dengan endpoint SOAP legacy (perbankan, pemerintah, asuransi, sistem pertukaran kesehatan).
• Membuat dokumen Office Open XML dari data JSON. Format .docx, .xlsx, dan .pptx adalah arsip ZIP file XML. Untuk membuat atau memodifikasi dokumen Office secara terprogram dari data berbasis-JSON, konversi JSON-ke-XML terjadi di batas antara lapisan data aplikasi Anda dan pustaka pembuatan dokumen.
• Memproduksi feed RSS atau Atom dari konten JSON. Blog, situs berita, dan platform podcast memancarkan feed RSS/Atom untuk sindikasi. Jika CMS Anda menyimpan artikel sebagai JSON, langkah pembuatan feed mengonversi entri JSON menjadi format XML yang diharapkan ekosistem feed-reader.
• Membuat file konfigurasi XML untuk aplikasi legacy. Banyak aplikasi enterprise lama (Java application server, file konfigurasi .NET, Spring XML application context) mengonsumsi konfigurasinya sebagai XML. Tooling infrastructure-as-code modern biasanya bekerja dalam YAML atau JSON, sehingga konversi JSON-ke-XML berada di pipeline deployment.
• Memberi makan data ke transformasi XSLT. XSLT (XSL Transformations, spesifikasi Michael Kay, W3C Recommendation) adalah bahasa transformasi XML standar dan mengonsumsi input XML. Jika data Anda dimulai dalam JSON dan mesin pelaporan Anda berbasis XSLT, konversi terjadi di batas input.
• Membuat file resource Android. File strings.xml, colors.xml, dimens.xml, dan layout Android adalah XML. Pipeline lokalisasi yang menyimpan string dalam JSON untuk kemudahan pengeditan mengonversi ke XML pada waktu build.

Pemetaan Konversi: Di Mana Informasi Bertahan dan Di Mana Hilang

JSON dan XML memiliki primitif struktural yang berbeda, sehingga konversi apa pun harus membuat pilihan. Pemetaan JSON-ke-XML standar yang diikuti sebagian besar konverter (yang ini termasuk):

• Objek JSON menjadi elemen XML. Setiap kunci menjadi elemen anak dengan kunci sebagai nama tag. {"name": "Alice"} menjadi <name>Alice</name>.
• Array JSON menjadi elemen anak yang diulang. {"items": [1, 2, 3]} menjadi tiga elemen anak <item>1</item><item>2</item><item>3</item> di dalam wrapper <items>. (Konverter berbeda menggunakan konvensi berbeda untuk nama elemen-array; beberapa menggunakan nama induk dalam bentuk tunggal, beberapa menggunakan <item> tetap.)
• String, angka, boolean menjadi konten teks dari elemen. Informasi tipe tidak dipertahankan: XML memperlakukan semua teks sebagai data karakter, sehingga round-trip XML → parse → serialisasi kembali ke JSON akan memancarkan angka sebagai string yang dikutip kecuali konsumen menerapkan inferensi tipe.
• null menjadi elemen kosong yang menutup-sendiri. {"middle_name": null} menjadi <middle_name/>. Beberapa konverter menggunakan xsi:nil="true" sebagai gantinya.
• Elemen root membungkus semuanya. JSON mengizinkan array atau skalar tingkat-atas; XML memerlukan tepat satu elemen root. Wrapper <root> (dapat dikonfigurasi di sini) adalah perbaikan konvensional.

Informasi yang hilang dalam konversi: perbedaan JSON antara angka dan string, perbedaan JSON antara true/false dan string "true"/"false", perbedaan array vs objek JSON (ketika array menjadi elemen yang diulang Anda tidak dapat memberi tahu dari XML saja apakah sumbernya memiliki array satu-elemen atau nilai tunggal). Informasi yang berpotensi diperoleh tetapi tidak digunakan oleh konverter sederhana: atribut XML (objek JSON dapat memetakan kunci ke atribut daripada elemen anak), namespace XML (JSON tidak memiliki yang setara), bagian CDATA (untuk menyematkan teks dengan karakter khusus XML). Untuk konversi JSON-ke-XML yang aman-roundtrip yang mempertahankan informasi tipe, konvensi BadgerFish atau konvensi Parker mengkodekan tipe JSON sebagai atribut XML yang dinamai-namespace: alat ini menghasilkan bentuk yang lebih sederhana dan lebih mudah dibaca daripada bentuk aman-roundtrip.

Kendala Nama-Tag XML yang Tidak Dimiliki Kunci JSON

Kunci objek JSON adalah string sembarang: setiap Unicode diizinkan. Nama elemen XML jauh lebih dibatasi: mereka harus dimulai dengan huruf atau underscore (bukan digit, tanda hubung, atau titik), dapat berisi huruf, digit, tanda hubung, underscore, dan titik (tidak ada spasi, tidak ada sebagian besar tanda baca), peka huruf besar/kecil, dan tidak dapat dimulai dengan prefiks cadangan xml dalam kombinasi kasus apa pun. Kunci JSON dengan spasi ("first name": "Alice"), kunci yang dimulai dengan digit ("3rd_choice"), atau kunci dengan karakter khusus ("@type", "$value") tidak dapat digunakan sebagai nama elemen XML secara langsung. Sebagian besar konverter (yang ini termasuk) secara diam-diam mengubah karakter yang tidak valid: mengganti spasi dengan underscore, menambahkan underscore di depan kunci yang dimulai dengan digit, menjatuhkan sebagian besar tanda baca. Sadarilah ini saat round-tripping: dokumen JSON dengan kunci yang tidak aman-XML tidak akan round-trip secara identik melalui XML.

Di Mana XML Masih Berkuasa pada 2026

XML tidak mundur pada 2026: itu hanya menetap di ceruk tertentu. Format dokumen: Office Open XML (Microsoft Office), OpenDocument (LibreOffice), ebook EPUB, SVG (W3C Recommendation 4 September 2001), MathML, XHTML. Konfigurasi: Java application server, Spring XML context, Maven POM, resource XML Android, file app.config dan web.config .NET. Feed: RSS 2.0, Atom 1.0 (RFC 4287), feed podcast (ekstensi RSS iTunes). Pertukaran kesehatan dan pemerintah: HL7 v3, FHIR (yang sekarang menawarkan JSON sebagai alternatif tetapi bentuk XML tetap dalam penggunaan berat), DocBook, NewsML, ISO 20022 perbankan. Badan standar: Hampir setiap contoh spesifikasi IETF dan W3C menggunakan XML. Verbositas XML adalah fitur dalam domain tersebut: itu mendeskripsikan diri sendiri, validasi terhadap skema sudah mapan, dan transformasi XSLT antara dialek XML adalah toolkit yang matang. Format ini tidak ke mana-mana; konversi JSON-ke-XML adalah jembatan antara tooling data modern dan sistem XML-native yang sudah mapan ini.

Privasi: Konversi Hanya-Browser

JSON yang ditempel ke konverter sering berisi data produksi nyata: respons API dengan pengidentifikasi pengguna, ID entitas internal yang mengungkapkan taksonomi bisnis, nilai konfigurasi yang menyertakan URL endpoint dan flag fitur, token, konten draf yang belum diterbitkan. Konverter sisi-server mengambil salinan setiap input ke log mereka. Konverter ini mem-parsing JSON Anda dengan JSON.parse() bawaan browser, berjalan melalui pohon objek yang dihasilkan dalam JavaScript, dan memancarkan XML sebagai string: semuanya di dalam tab browser Anda. Verifikasi di tab Network DevTools saat Anda mengklik Konversi (tidak ada permintaan yang dikirim), atau bawa halaman offline (mode pesawat) setelah dimuat dan konverter masih berfungsi. Aman untuk respons API produksi, konfigurasi internal, konten draf, atau JSON apa pun yang tidak ingin Anda salin ke hard drive orang asing.

Pertanyaan yang Sering Diajukan

Bagaimana array JSON dikonversi?

Array JSON dikonversi menjadi elemen XML berulang yang dibungkus dalam tag <item>. Misalnya, [1, 2, 3] menjadi tiga elemen <item> di dalam parent.

Apakah ini bekerja dengan file JSON besar?

Ya: karena semuanya berjalan di browser Anda, batas praktis adalah memori yang tersedia perangkat Anda. Puluhan ribu baris JSON dikonversi dalam waktu kurang dari satu detik di laptop modern. Input yang sangat besar (multi-MB) mungkin sebentar membekukan tab saat parser berjalan melalui pohon. Untuk konversi batch dataset besar, skrip yang menggunakan konverter sisi-server (xml2js di Node, dicttoxml di Python) lebih sesuai.

Apakah JSON saya diunggah ke server?

Tidak. Konversi berjalan sepenuhnya di browser Anda: JSON yang ditempel tidak pernah meninggalkan perangkat Anda. Verifikasi di tab Network DevTools saat Anda mengklik Konversi (tidak ada permintaan yang dikirim), atau bawa halaman offline (mode pesawat) setelah dimuat. Aman untuk respons API produksi, konfigurasi internal, atau data apa pun yang tidak ingin Anda bagikan secara eksternal.

Bisakah saya membuat beberapa kunci JSON menjadi atribut XML alih-alih elemen anak?

Konverter ini memancarkan semua kunci JSON sebagai elemen anak, bukan atribut. Konvensi yang digunakan beberapa konverter: kunci yang diawali dengan @ menjadi atribut ("@id": 5 → id="5" pada induk): adalah konvensi BadgerFish. Jika konsumen hilir Anda memerlukan nilai-nilai tertentu sebagai atribut, Anda akan memerlukan konverter kustom yang memahami konvensi, atau mengedit XML yang dihasilkan dengan tangan.

Apa yang terjadi pada kunci JSON yang berisi spasi atau karakter XML yang tidak valid?

Nama elemen XML memiliki aturan yang lebih ketat daripada kunci JSON: mereka harus dimulai dengan huruf atau underscore, tidak boleh berisi spasi, dan melarang sebagian besar tanda baca. Kunci dengan karakter yang tidak valid disanitasi: spasi menjadi underscore, digit di depan mendapat prefiks underscore, karakter khusus dijatuhkan. Ini berarti round-trip JSON → XML → JSON mungkin tidak menghasilkan nama kunci asli persis. Jika data Anda memiliki kunci yang tidak biasa, periksa output untuk memastikan mangling tidak merusak sesuatu yang penting.

Alat terkait