JSON, CSV, atau XML: Memilih Format Data yang Tak Akan Anda Sesali
Tiga format, tiga pekerjaan berbeda. Apa yang bisa dan tak bisa diungkapkan masing-masing, konversi yang kehilangan informasi, dan cara memilih tanpa menyesal kemudian.
Diperbarui 11 Agustus 2026Baca 4 menit
Ketiga format ini bukan pesaing melainkan jawaban atas pertanyaan yang berbeda. CSV adalah tabel. JSON adalah graf objek. XML adalah dokumen bermarkah. Sebagian besar penderitaan dalam pekerjaan data berasal dari meminta sebuah format menjadi sesuatu yang bukan dirinya — penyarangan di dalam CSV, tabel di dalam XML, komentar di dalam JSON — dan obatnya biasanya mengganti format alih-alih melawannya.
Apa yang bisa diungkapkan masing-masing
| CSV | JSON | XML | |
|---|---|---|---|
| Bentuk | Baris dan kolom datar | Objek dan larik bersarang | Elemen bersarang |
| Tipe | Tidak ada — semuanya teks | String, angka, boolean, null | Tidak ada bawaan; skema bisa menambahkannya |
| Komentar | Tidak | Tidak | Ya |
| Atribut vs isi | Tidak berlaku | Tidak ada pembedaan | Ya — perbedaan yang nyata |
| Ukuran | Terkecil | Menengah — kunci berulang | Terbesar — tag berulang dua kali |
| Mengalirkan berkas raksasa | Sepele | Merepotkan | Bisa dikerjakan |
Baris yang paling mengejutkan adalah komentar di JSON. Spesifikasinya tak punya komentar, dan satu baris // membuat berkasnya tidak sah — itulah sebabnya begitu banyak alat menciptakan dialek sendiri (JSON5, JSONC) untuk menyiasatinya. Jika sebuah berkas konfigurasi perlu dijelaskan, itu alasan sungguhan untuk memilih format lain.
Memilih berdasarkan tujuan
- 1Menuju lembar kerja, basis data, atau alat analisis? CSV. Didukung universal, ringkas, dan bentuk tabularnya persis yang diharapkan alat-alat itu.
- 2Menuju API atau aplikasi web? JSON. Ia membawa tipe, mengungkapkan penyarangan, dan setiap bahasa menguraikannya tanpa perlu memilih pustaka.
- 3Berbicara dengan sistem korporat atau pemerintah? Kemungkinan XML, karena begitulah bunyi spesifikasinya. Jangan melawannya.
- 4Berkas konfigurasi yang akan disunting orang secara manual? Jangan JSON — tanpa komentar dan sintaksisnya tak kenal ampun. YAML atau TOML lebih ramah.
- 5Jutaan baris? CSV, diproses baris demi baris. Mengurai berkas JSON berukuran gigabita secara utuh adalah masalah memori.
Apa yang hilang pada tiap konversi
| Konversi | Yang hilang |
|---|---|
| CSV → JSON | Tidak ada secara struktur, tetapi semuanya tiba sebagai string kecuali tipenya disimpulkan |
| JSON → CSV | Penyarangan. Objek dan larik harus diratakan atau dibuang |
| XML → JSON | Pembedaan atribut versus elemen, komentar, jaminan urutan |
| JSON → XML | Tidak ada, tetapi hasilnya bertele-tele dan butuh konvensi penamaan |
| Excel → CSV | Rumus, pemformatan, banyak lembar — lihat Excel ke CSV dan JSON |
Baris JSON-ke-CSV itulah yang menggigit. Meratakan {customer: {name, address: {city}}} menjadi kolom butuh konvensi — customer.address.city lazim dipakai — dan apa pun yang berupa daftar sama sekali tak punya jawaban yang baik. Jika JSON Anda memang bersarang, mengekspornya ke CSV adalah keputusan bersusut, bukan sekadar pergantian format.
Masalah tipe pada arah sebaliknya lebih senyap dan sama merusaknya. CSV tak punya tipe, jadi 007 bisa tiba sebagai angka 7, 2026-04-03 bisa menjadi tanggal di wilayah yang keliru, dan TRUE bisa jadi boolean atau tidak. Itu kegagalan yang sama seperti yang dijelaskan di mengubah Excel ke CSV dan JSON, dan sifatnya melekat pada format alih-alih pada alat tertentu.
Rapikan, validasi, dan telusuri — di perangkat Anda. Data pelanggan dan muatan API tidak pernah diunggah.
Rapikan dan periksa JSONKebiasaan praktis
- Validasi sebelum dikirim. Koma menggantung atau tanda kutip tanpa escape akan ditolak sistem penerima dengan galat yang jarang menunjuk baris sebenarnya. Validator menemukannya dalam hitungan detik.
- Pakai tanggal ISO di mana-mana.
2026-04-03tidak ambigu di setiap wilayah dan terurut benar sebagai teks biasa. Tak ada format lain yang begitu. - Kodekan sebagai UTF-8, selalu. Selain itu, nama beraksen dan simbol mata uang berubah jadi karakter kacau di sistem lain.
- Simpan pengenal sebagai string. Kode pos, nomor telepon, dan nomor rekening adalah label, bukan kuantitas — memperlakukannya sebagai angka mengikis nol di depan dan membulatkan nilai panjang.
- Urutkan kunci untuk pembandingan. Dua ekspor dari data yang sama dengan urutan kunci berbeda menghasilkan diff penuh derau. Pengurut kunci membuat perubahannya terbaca.
Minifikasi atau perapian?
Keduanya, pada saat yang berbeda. JSON yang dirapikan — berindentasi, satu nilai per baris — untuk dibaca manusia dan untuk kendali versi, di mana diff baris demi baris adalah seluruh intinya. JSON terminifikasi membuang setiap spasi yang tak perlu dan dipakai untuk pengiriman, di mana ia biasanya menghemat 20–30% sebelum kompresi.
Kesalahannya adalah menaruh JSON terminifikasi ke dalam repositori. Setiap perubahan lalu tampil sebagai satu baris raksasa yang termodifikasi, dan meninjaunya menjadi mustahil. Simpan dalam bentuk terbaca, minifikasi saat build atau saat dikirim.
Semua alat ini berjalan secara lokal di perangkat Anda, dan itu khususnya penting untuk pekerjaan data: muatan JSON atau ekspor CSV sering merupakan berkas paling sensitif yang ditangani sebuah organisasi, dan mengunggahnya ke perapi daring adalah sebuah pengungkapan terlepas dari apa yang dijanjikan layanan itu.
Pertanyaan umum
Sebaiknya pakai JSON atau CSV?
CSV untuk data tabular yang menuju lembar kerja, basis data, atau alat analisis — ia ringkas dan didukung universal. JSON ketika datanya bersarang atau ketika tipe penting, seperti muatan API, karena CSV tak bisa mengungkapkan daftar di dalam sebuah rekaman dan memperlakukan setiap nilai sebagai teks.
Apakah JSON menggantikan XML?
Untuk API web, sebagian besar ya — JSON lebih ringan dan memetakan langsung ke struktur data yang sudah dipakai bahasa pemrograman. XML tetap standar di lingkungan korporat, pemerintah, penerbitan, dan format dokumen, di mana skema, ruang nama, dan model atributnya benar-benar bekerja.
Bisakah JSON punya komentar?
Tidak. Spesifikasinya tak punya sintaksis komentar, dan menambahkannya membuat berkasnya tidak sah. Itulah sebabnya varian seperti JSON5 dan JSONC ada. Jika orang perlu menyunting dan memahami berkasnya secara manual, YAML atau TOML pilihan yang lebih baik untuk konfigurasi.
Apa yang terjadi pada data bersarang saat saya mengubah JSON ke CSV?
Ia harus diratakan, biasanya menjadi nama kolom bertitik seperti `customer.address.city`, dan daftar di dalam sebuah rekaman sama sekali tak punya perwakilan yang bersih. Jika JSON Anda memang bersarang, mengekspornya ke CSV adalah keputusan bersusut alih-alih sekadar pergantian format.