Artikel
Mengonversi antara CSV, XML, JSON, dan YAML: panduan praktis
CSV, JSON, XML, dan YAML adalah empat format yang paling sering ditemui developer dalam pipeline data, file konfigurasi, dan API. Mengonversi di antara keempatnya mudah ketika model data sesuai, dan cukup banyak kehilangan informasi ketika tidak sesuai. Panduan ini membahas apa yang dapat dan tidak dapat direpresentasikan oleh setiap format, di mana informasi hilang selama konversi, dan jebakan enkoding yang menyebabkan korupsi data yang tidak terdeteksi. Tool data-converter di situs ini menangani tiga dari empat format tersebut (CSV, JSON, dan YAML) sepenuhnya di dalam browser; bagian XML di sini adalah latar belakang untuk saat Anda memindahkan data secara manual atau dengan alat terpisah.
Empat format dan model datanya
CSV mengorganisir data sebagai grid datar berupa baris dan kolom. Baris pertama biasanya menamai kolom-kolom; setiap baris berikutnya adalah satu record. Tidak ada nesting, tidak ada informasi tipe, dan tidak ada standar selain teks biasa di sel. Setiap nilai adalah string kecuali aplikasi konsumer menetapkan tipe tertentu. JSON memodelkan data sebagai pohon objek (peta kunci-nilai) dan array. Nilai dapat berupa string, angka, boolean, null, objek bersarang, atau array dengan kedalaman berapa pun. Ini memungkinkan satu dokumen JSON merepresentasikan record pelanggan dengan objek alamat yang disematkan, array item baris, dan total numerik bertipe. XML memodelkan data sebagai pohon elemen. Setiap elemen dapat memiliki atribut bernama dan mengandung elemen anak atau konten teks. Tidak ada tipe numerik atau boolean bawaan; semuanya adalah teks. Skema seperti XSD dapat menegakkan tipe saat validasi, tetapi format kabel selalu berupa data karakter. YAML menggunakan indentasi untuk mengekspresikan model objek-dan-array yang sama seperti JSON, dengan sintaks yang lebih bersih dan mudah dibaca manusia. YAML adalah superset dari JSON: dokumen JSON yang valid juga valid sebagai YAML. YAML menambahkan string multi-baris, komentar, dan referensi anchor-alias untuk blok yang berulang. YAML umum digunakan dalam file konfigurasi; JSON umum digunakan dalam respons API.
Konversi yang kehilangan data: penyederhanaan dan ambiguitas XML
Konversi yang paling umum kehilangan data adalah meratakan JSON atau XML bersarang menjadi CSV. Objek JSON dengan field alamat bersarang tidak dapat dipetakan dengan bersih ke baris CSV. Solusi umum adalah nama kolom dengan notasi titik: customer.address.city menjadi kolomnya sendiri. Ini berfungsi untuk satu tingkat nesting, tetapi gagal total ketika muncul array. Pelanggan dengan tiga nomor telepon memerlukan salah satu dari tiga kolom terpisah (menghardcode jumlah maksimum), memisah ke file CSV kedua, atau mengenkoding array sebagai string yang dibatasi di dalam satu sel. Tidak ada opsi ini yang dapat dikembalikan ke JSON asli tanpa metadata tambahan. XML memperkenalkan ambiguitas tersendiri: pilihan antara atribut dan elemen anak. Nilai Paris bisa disimpan sebagai atribut (<city name="Paris">) atau sebagai elemen anak (<city><name>Paris</name></city>). Ketika konverter membaca XML dan menghasilkan JSON, ia harus memutuskan cara memetakan atribut. Konvensi umum termasuk menambahkan prefiks @ pada kunci atribut atau menempatkannya di bawah kunci "_attributes". Pilihan ini tidak terstandarisasi, yang berarti dua konverter yang membaca XML yang sama dapat menghasilkan JSON dengan struktur berbeda. Jika Anda berencana melakukan round-trip data melalui XML dan JSON, tetapkan satu konvensi sebelum memulai.
Jebakan CSV: delimiter, tanda kutip, dan enkoding
CSV tidak memiliki standar formal tunggal, hanya RFC 4180 sebagai referensi yang banyak dikutip. Delimiter yang paling umum adalah koma, tetapi titik koma (umum di lokal Eropa di mana koma digunakan sebagai pemisah desimal), tab (TSV), dan pipa semuanya muncul dalam praktik. File yang disebut .csv mungkin menggunakan salah satu dari ini tanpa menandakan mana yang digunakan. Ketika nilai field mengandung delimiter itu sendiri, RFC 4180 mengharuskan membungkus field dalam tanda kutip ganda: "San Francisco, CA". Tanda kutip ganda di dalam field yang dikutip harus di-escape dengan menggandakannya: "He said ""hello""". Field yang mengandung baris baru literal juga harus dikutip. Parser yang melewati langkah ini menghasilkan error jumlah baris yang sulit dilacak. Enkoding adalah jebakan tersendiri. File CSV dari tool Windows sering membawa UTF-8 BOM (byte order mark: tiga byte EF BB BF di awal file). BOM membantu Excel mengidentifikasi enkoding, tetapi banyak parser bahasa pemrograman memperlakukan BOM sebagai bagian dari nama kolom pertama, menghasilkan kolom bernama "id" alih-alih "id". Ini merusak kode hilir yang mencari kolom berdasarkan nama. Saat membaca file CSV secara programatik, hapus BOM sebelum parsing, atau gunakan library yang menanganinya secara eksplisit.
Memilih format: konfigurasi, pertukaran, dan spreadsheet
Pilihan format biasanya ditentukan oleh konteks, bukan preferensi. JSON adalah default untuk REST API dan pertukaran browser-ke-server. Format ini ringkas, diurai secara native di setiap bahasa pemrograman, dan membawa informasi tipe untuk angka dan boolean. Kelemahannya adalah tidak adanya komentar, yang membuatnya tidak cocok untuk file yang dibaca dan diedit developer secara langsung. YAML lebih disukai untuk file konfigurasi (manifes Kubernetes, definisi pipeline CI, playbook Ansible) karena memungkinkan komentar inline dan lebih mudah dibaca daripada JSON dengan banyak tingkat indentasi. Risiko utamanya adalah bahwa error indentasi bersifat senyap: kunci yang salah indentasi berpindah ke scope yang berbeda tanpa error parse apa pun. XML tetap menjadi standar dalam sistem enterprise lama, layanan web SOAP, format dokumen (DOCX, SVG, RSS), dan konteks yang memerlukan validasi skema atau disambiguasi namespace. Format ini verbose, tetapi tooling XPath dan XSLT sudah matang. CSV adalah pilihan tepat ketika data memang benar-benar datar dan konsumernya adalah aplikasi spreadsheet atau analis data. Format ini tidak cocok untuk konfigurasi atau pertukaran API karena tidak memiliki sistem tipe dan tidak mendukung nesting.
Melakukannya secara lokal dengan data-converter
Tool data-converter di situs ini mengurai dan mengonversi antara CSV, JSON, dan YAML sepenuhnya di dalam browser; alat ini tidak membaca atau menulis XML. Tidak ada data yang dikirim ke server kapan pun. Konversi berjalan di runtime JavaScript lokal Anda, dan output tersedia untuk diunduh atau disalin tanpa apa pun yang meninggalkan perangkat Anda. Ini penting untuk data yang bukan milik Anda untuk dibagikan: respons API yang mengandung informasi pribadi, file konfigurasi dengan nama host internal, atau ekspor CSV dari database internal. Menempelkan data tersebut ke konverter berbasis web yang berjalan di server berarti kontennya dikirim melalui jaringan dan diproses di perangkat keras yang tidak Anda kendalikan. Dengan data-converter, tab browser adalah lingkungan pemrosesan. Tool ini menerapkan tanda kutip RFC 4180 saat membaca atau menulis CSV, dan mengharapkan array objek yang datar untuk konversi JSON atau YAML ke CSV: nilai objek atau array bersarang di bawah sebuah kunci tidak mendapat perataan notasi titik otomatis, jadi ratakan sendiri field tersebut sebelum konversi jika Anda membutuhkannya sebagai kolom terpisah. Jika Anda perlu memindahkan data ke atau dari XML, konversikan dulu ke JSON atau YAML dengan alat XML khusus, lalu bawa hasilnya ke sini.
Alat dalam artikel ini
Pertanyaan yang sering diajukan
Bisakah saya melakukan round-trip JSON melalui CSV dan mendapatkan kembali yang asli?
Hanya jika JSON adalah array datar berisi objek tanpa field bersarang dan tanpa array sebagai nilai. Begitu Anda memiliki objek bersarang atau nilai array, representasi CSV memerlukan keputusan struktural (kolom notasi titik, beberapa baris, atau string yang dienkoding) yang tidak dapat dibalik secara otomatis. Jika data Anda memiliki nesting, JSON, XML, atau YAML akan round-trip dengan bersih; CSV tidak.
Mengapa CSV saya terlihat salah di Excel setelah diekspor dari aplikasi Eropa?
Lokal Eropa sering menggunakan titik koma sebagai delimiter CSV karena koma dicadangkan untuk notasi desimal. Excel di lokal Eropa mengharapkan titik koma. Jika file menggunakan koma, Excel memperlakukan seluruh baris sebagai satu kolom. Solusinya adalah mengubah delimiter di pengaturan ekspor, atau menggunakan wizard Data Import Excel, yang memungkinkan Anda menentukan delimiter secara manual. Masalah UTF-8 BOM terpisah: tanpa BOM, Excel mungkin juga salah membaca karakter beraksen sebagai teks yang rusak.
Apa perbedaan antara YAML dan JSON dalam praktik?
Keduanya merepresentasikan model data yang sama: objek, array, string, angka, boolean, dan null. YAML menambahkan komentar (baris yang dimulai dengan #), literal string multi-baris, dan referensi anchor untuk blok yang berulang. JSON secara ketat adalah subset dari YAML yang valid, tetapi parser JSON tidak membaca YAML. Aturan praktisnya: gunakan JSON untuk payload API dan penyimpanan data; gunakan YAML untuk file konfigurasi yang diedit manusia dan yang mendapat manfaat dari komentar inline.