Artikel
Menukar antara CSV, XML, JSON, dan YAML: panduan praktikal
CSV, JSON, XML, dan YAML ialah empat format yang paling kerap ditemui pembangun dalam saluran paip data, fail konfigurasi, dan API. Penukaran antara format ini mudah apabila model data secocok, dan mengakibatkan kehilangan maklumat yang mengejutkan apabila tidak secocok. Panduan ini merangkumi apa yang setiap format boleh dan tidak boleh wakili, di mana maklumat hilang semasa penukaran, dan perangkap pengekodan yang menyebabkan kerosakan senyap. Alat data-converter di tapak ini mengendalikan tiga daripada empat format (CSV, JSON, dan YAML) sepenuhnya dalam pelayar; bahagian XML di sini adalah latar belakang untuk apabila anda memindahkan data secara manual atau dengan alat berasingan.
Empat format dan model data mereka
CSV mengatur data sebagai grid rata baris dan lajur. Baris pertama biasanya menamakan lajur; setiap baris berikutnya ialah satu rekod. Tiada penyarangan, tiada maklumat jenis, dan tiada piawaian untuk apa-apa selain teks biasa dalam sel. Setiap nilai ialah rentetan melainkan aplikasi pengguna mengenakan jenis. JSON memodelkan data sebagai pokok objek (peta kunci-nilai) dan tatasusunan. Nilai boleh berupa rentetan, nombor, boolean, null, objek bersarang, atau tatasusunan dengan kedalaman apa-apa. Ini membolehkan satu dokumen JSON mewakili rekod pelanggan dengan objek alamat yang terbenam, tatasusunan item baris, dan jumlah nombor bertaip. XML memodelkan data sebagai pokok elemen. Setiap elemen boleh membawa atribut bernama dan mengandungi elemen anak atau kandungan teks. Tiada jenis nombor atau boolean terbina; semuanya ialah teks. Skema seperti XSD boleh menguatkuasakan jenis pada masa pengesahan, tetapi format wayar sentiasa merupakan data aksara. YAML menggunakan lekukan untuk menyatakan model objek-dan-tatasusunan yang sama seperti JSON, dengan sintaks yang lebih mudah dibaca manusia. YAML ialah superset JSON: sebarang dokumen JSON yang sah juga merupakan YAML yang sah. Ia menambah rentetan berbilang baris, ulasan, dan rujukan sauh-alias untuk blok berulang. YAML biasa dalam fail konfigurasi; JSON biasa dalam respons API.
Penukaran rosak: meratakan dan kekaburan XML
Penukaran rosak yang paling biasa ialah meratakan JSON atau XML bersarang ke dalam CSV. Objek JSON dengan medan alamat bersarang tidak boleh dipetakan dengan bersih ke baris CSV. Penyelesaian biasa ialah nama lajur dengan notasi titik: customer.address.city menjadi lajur tersendiri. Ini berfungsi untuk satu tahap penyarangan, tetapi gagal sepenuhnya apabila tatasusunan muncul. Pelanggan dengan tiga nombor telefon memerlukan sama ada tiga lajur berasingan (mengehadkan jumlah maksimum), membahagi kepada fail CSV kedua, atau mengekod tatasusunan sebagai rentetan berpisah dalam satu sel. Tiada pilihan ini boleh dibalik semula ke JSON asal tanpa metadata tambahan. XML memperkenalkan kekaburan berasingan: pilihan antara atribut dan elemen anak. Nilai Paris boleh disimpan sebagai atribut (<city name="Paris">) atau sebagai elemen anak (<city><name>Paris</name></city>). Apabila penukar membaca XML dan menghasilkan JSON, ia mesti memutuskan cara memetakan atribut. Konvensyen biasa termasuk menambah awalan kunci atribut dengan @ atau meletakkannya di bawah kunci "_attributes". Pilihan ini tidak distandardkan, bermakna dua penukar yang membaca XML yang sama boleh menghasilkan JSON yang berbeza secara struktur. Jika anda bercadang untuk membalik-ulang data melalui XML dan JSON, tetapkan konvensyen sebelum memulakan.
Perangkap CSV: pembatas, petikan, dan pengekodan
CSV tidak mempunyai piawaian formal tunggal, hanya RFC 4180 sebagai rujukan yang banyak disebut. Pembatas paling biasa ialah koma, tetapi koma bertitik (biasa dalam lokasi Eropah di mana koma berfungsi sebagai pemisah perpuluhan), tab (TSV), dan paip semuanya muncul dalam amalan. Fail yang dinamakan .csv boleh menggunakan mana-mana ini tanpa menunjukkan yang mana. Apabila nilai medan mengandungi pembatas itu sendiri, RFC 4180 memerlukan pembungkusan medan dalam tanda petikan berganda: "San Francisco, CA". Tanda petikan berganda dalam medan yang dipetik mesti dilepas dengan menggandakannya: "He said ""hello""". Medan yang mengandungi baris baharu literal juga mesti dipetik. Penghurai yang melangkau langkah ini menghasilkan ralat kiraan baris yang sukar dikesan. Pengekodan ialah perangkap berasingan. Fail CSV daripada alat Windows sering membawa UTF-8 BOM (tanda susunan bait: tiga bait EF BB BF pada permulaan fail). BOM membantu Excel mengenal pasti pengekodan, tetapi banyak penghurai bahasa pengaturcaraan merawat BOM sebagai sebahagian daripada nama lajur pertama, menghasilkan lajur bernama "id" dan bukannya "id". Ini merosakkan sebarang kod hiliran yang mencari lajur mengikut nama. Apabila membaca fail CSV secara aturcara, tanggalkan BOM sebelum menghurai, atau gunakan pustaka yang mengendalikannya secara eksplisit.
Memilih format: konfigurasi, pertukaran, dan hamparan
Pilihan format biasanya ditentukan oleh konteks, bukan pilihan peribadi. JSON ialah lalai untuk REST API dan pertukaran pelayar-ke-pelayan. Ia padat, dihurai secara asli dalam setiap bahasa pengaturcaraan, dan membawa maklumat jenis untuk nombor dan boolean. Kelemahannya ialah ketiadaan ulasan, yang menjadikannya tidak sesuai untuk fail yang pembangun baca dan edit secara langsung. YAML diutamakan untuk fail konfigurasi (manifes Kubernetes, definisi saluran paip CI, buku main Ansible) kerana ia membenarkan ulasan sebaris dan lebih mudah dibaca berbanding JSON dengan banyak tahap lekukan. Risiko utamanya ialah ralat lekukan adalah senyap: kunci yang dilekukkan salah berpindah ke skop berbeza tanpa sebarang ralat penghuraian. XML kekal sebagai piawaian dalam sistem perusahaan lama, perkhidmatan web SOAP, format dokumen (DOCX, SVG, RSS), dan konteks yang memerlukan pengesahan skema atau penyelesaian nama ruang. Ia bertele-tele, tetapi alatan XPath dan XSLT sudah matang. CSV ialah pilihan tepat apabila data benar-benar rata dan pengguna ialah aplikasi hamparan atau penganalisis data. Ia tidak sesuai untuk konfigurasi atau pertukaran API kerana tiada sistem jenis dan tiada penyarangan.
Lakukan secara tempatan dengan data-converter
Alat data-converter di laman ini menghurai dan menukar antara CSV, JSON, dan YAML sepenuhnya dalam pelayar; ia tidak membaca atau menulis XML. Tiada data dihantar ke pelayan pada bila-bila masa. Penukaran berjalan dalam masa jalan JavaScript tempatan anda, dan output tersedia untuk muat turun atau salin tanpa apa-apa yang meninggalkan peranti anda. Ini penting untuk data yang bukan milik anda untuk dikongsi: respons API yang mengandungi maklumat peribadi, fail konfigurasi dengan nama hos dalaman, atau eksport CSV dari pangkalan data dalaman. Menampal data tersebut ke dalam penukar berasaskan web yang berjalan di pelayan bermakna kandungan dihantar melalui rangkaian dan diproses pada perkakasan yang tidak anda kawal. Dengan data-converter, tab pelayar ialah persekitaran pemprosesan. Alat ini menggunakan petikan RFC 4180 apabila membaca atau menulis CSV, dan menjangkakan tatasusunan rata objek untuk JSON atau YAML yang beralih ke CSV: nilai objek atau tatasusunan bersarang di bawah satu kunci tidak menerima perataan notasi titik automatik, jadi ratakan medan tersebut sendiri sebelum menukar jika anda memerlukannya sebagai lajur berasingan. Jika anda perlu memindahkan data ke atau daripada XML, tukarkan kepada JSON atau YAML dengan alat XML khusus dahulu, kemudian bawa hasilnya ke sini.
Alat dalam artikel ini
Soalan lazim
Bolehkah saya membalik-ulang JSON melalui CSV dan mendapatkan semula yang asal?
Hanya jika JSON ialah tatasusunan rata objek tanpa medan bersarang dan tanpa tatasusunan sebagai nilai. Sebaik sahaja anda mempunyai objek bersarang atau nilai tatasusunan, perwakilan CSV memerlukan keputusan struktur (lajur notasi titik, berbilang baris, atau rentetan yang dikodkan) yang tidak boleh dibalikkan secara automatik. Jika data anda mempunyai penyarangan, JSON, XML, atau YAML akan berputar balik dengan bersih; CSV tidak.
Mengapa CSV saya kelihatan salah dalam Excel selepas mengeksport dari aplikasi Eropah?
Lokasi Eropah sering menggunakan koma bertitik sebagai pembatas CSV kerana koma dikhaskan untuk notasi perpuluhan. Excel pada lokasi Eropah mengharapkan koma bertitik. Jika fail menggunakan koma, Excel merawat keseluruhan baris sebagai satu lajur. Pembetulannya ialah sama ada mengubah pembatas dalam tetapan eksport, atau menggunakan wizard Import Data Excel, yang membolehkan anda menentukan pembatas secara manual. Isu UTF-8 BOM adalah berasingan: tanpa BOM, Excel juga boleh membaca aksara bertanda sebagai teks rosak.
Apakah perbezaan antara YAML dan JSON dalam amalan?
Kedua-duanya mewakili model data asas yang sama: objek, tatasusunan, rentetan, nombor, boolean, dan null. YAML menambah ulasan (baris bermula dengan #), literal rentetan berbilang baris, dan rujukan sauh untuk blok berulang. JSON ialah subset ketat YAML yang sah, tetapi penghurai JSON tidak membaca YAML. Peraturan praktikal: gunakan JSON untuk muatan API dan storan data; gunakan YAML untuk fail konfigurasi yang manusia edit dan mendapat manfaat daripada ulasan sebaris.