Surat Cinta untuk Format CSV

• Format yang disebut-sebut lebih "unggul" untuk menggantikan CSV sering diperkenalkan, tetapi kebanyakan didasarkan pada perbandingan yang bias dan mengabaikan kekuatan sejati CSV
• Tulisan ini bukan mengatakan CSV itu sempurna, melainkan ingin menyoroti kelebihan-kelebihannya yang sering diremehkan
• Di tengah suasana yang menganggap membenci CSV terlihat keren, tulisan ini mengingatkan kembali nilai sejati CSV

1. CSV sangat sederhana

• Definisi CSV persis seperti judulnya: "nilai yang dipisahkan koma"
• Baris dipisahkan dengan baris baru, kolom dipisahkan dengan koma
• Jika sebuah nilai mengandung koma atau baris baru, nilai itu dibungkus dengan tanda kutip, dan tanda kutip itu sendiri direpresentasikan dengan tanda kutip ganda
• Tanpa spesifikasi yang rumit, siapa pun dapat memahaminya dan menggunakannya secara intuitif
• Meski begitu, untuk parsing yang akurat tetap disarankan memakai parser CSV khusus

2. CSV adalah gagasan kolektif

• Tidak ada pemilik, tidak diprivatisasi
• RFC 4180 memang ada, tetapi kebanyakan orang menganggapnya hanya sebagai referensi
• Ini adalah format bebas yang bertumpu pada aturan bersama yang dibagikan secara implisit oleh para pengembang di seluruh dunia

3. CSV adalah teks

• Seperti JSON, YAML, dan XML, CSV adalah format teks murni yang dapat dibaca manusia
• Bisa dibuka dengan editor teks apa pun, dan isinya dapat diperiksa tanpa alat tambahan
• Cara encoding-nya juga bisa dipilih dengan bebas

4. CSV dioptimalkan untuk streaming

• Karena strukturnya dibaca per baris, konsumsi memorinya sangat rendah
• Dengan kode sederhana saja, data berukuran beberapa gigabita bisa diproses hanya dengan beberapa KB memori
• Format berorientasi kolom seperti Parquet sulit diproses secara streaming dan memerlukan buffering yang kompleks
• Kekurangannya, jika hanya ingin melihat kolom tertentu pun seluruh baris tetap harus dibaca

5. CSV mudah ditambahkan

• Sangat mudah membuka file dalam mode append(a+) lalu menambahkan baris baru di bagian akhir
• Sebaliknya, format berorientasi kolom seperti Parquet tidak efisien dan lebih rumit untuk penambahan baris

6. CSV mendukung tipe dinamis

• Karena tidak memiliki tipe tetap, data bisa ditafsirkan dengan fleksibel
• Contoh: JavaScript tidak bisa merepresentasikan integer 64-bit dengan baik, tetapi CSV bisa digunakan tanpa batasan seperti itu
• Ini memberi keunggulan dalam kompatibilitas lintas bahasa dan fleksibilitas
• Namun, jika ditafsirkan keliru bisa menimbulkan kesalahan → perlu kehati-hatian saat digunakan
• Jika membutuhkan performa tinggi, teks juga bisa diproses langsung di level biner tanpa mendekodekannya terlebih dahulu

7. CSV ringkas

• Karena header hanya ada di bagian paling awal file, hampir tidak ada pengulangan format
• JSON dan XML memiliki overhead besar karena pengulangan key
• Representasi string-nya pun sudah ringkas, dan overhead dari format itu sendiri (koma, tanda kutip, dll.) sangat kecil

8. CSV yang dibalik pun tetap valid

• CSV tetap merupakan CSV yang valid bahkan jika dibalik pada level byte
• Ini dimungkinkan berkat cara escape tanda kutip ganda, karena skemanya bersifat palindromik
• Berkat sifat ini, bagian akhir file CSV bisa dibaca dengan sangat efisien
• Contoh: saat melanjutkan proses yang terhenti, cukup baca beberapa baris terakhir file untuk memulai lagi

9. Excel membenci CSV

• Jika Excel merasa suatu format merepotkan, itu justru bisa menjadi tanda bahwa Anda berada di jalan yang benar

[ng0301]

Yang sederhana adalah yang terbaik!

[ethanhur]

Yang lebih buruk itu lebih baik!

[GN⁺]

Komentar Hacker News

• Alasan menyukai file CSV dan INI adalah karena keduanya sederhana, berbasis teks, tidak memiliki tipe yang dikodekan dalam formatnya, dan hanya terdiri dari string

  • Memang ada kelemahan karena tidak ada standar resmi, tetapi keduanya tetap menjalankan fungsinya dengan baik
  • Saya sudah menandai kritik terhadap INI oleh TOML
  • Saya pikir baris pertama kritik terhadap TOML juga berlaku untuk CSV: ia adalah gabungan dari berbagai dialek

• CSV itu elegan, tetapi punya cacat fatal — tanda kutip memiliki efek "non-lokal"

  • Misalnya, satu tanda kutip di byte 1 dapat mengubah makna koma di byte 1000000
  • Ini menyebabkan dua konsekuensi yang tidak menyenangkan
    • Sulit memparalelkan pemrosesan CSV
    • Kerusakan data sangat memengaruhi keterbacaan file (satu tanda kutip yang hilang atau tambahan bisa merusak semuanya)
  • Karena itu, belakangan ini untuk serialisasi data tabel sederhana saya lebih memilih escaping sederhana daripada CSV

• Hal terbaik dari CSV adalah siapa pun bisa menulis parser dalam 30 menit

  • Data dari awal 90-an bisa dengan mudah dibawa ke layanan web modern
  • Hal terburuk dari CSV juga adalah siapa pun bisa menulis parser dalam 30 menit
  • Implementasi yang salah, data yang salah, dan perilaku aneh yang tidak terdefinisi mudah terjadi
  • JSON dan YAML juga memiliki masalah serupa
  • XML agak jelek dilihat, tetapi tampaknya paling tangguh

• Orang yang menyukai CSV mungkin belum pernah diminta menangani pencegahan injeksi CSV di lingkungan perusahaan

  • Sumber daya yang bagus di web masih kurang
  • Sumber terbaik adalah <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">ini</a>

• Ada banyak alasan untuk menyukai CSV

  • Anda bisa menulis program dalam C dan langsung mengeluarkan berbagai hal dalam format CSV
  • Anda bisa menulis middleware sederhana yang dengan mudah mengubah hampir semua database atau "sesuatu" umum menjadi CSV
  • Anda bisa memasukkan CSV ke Excel dan melakukan apa pun yang Anda mau
  • Saya juga suka file ini. Anda bisa langsung mengeditnya di Notepad
  • Namun, saya berharap ada semacam garis besar/struktur umum

• Baru-baru ini saya sedang mengembangkan solusi berbasis Raspberry Pi

  • Implementasi pertama menggunakan database SQLite, tetapi rusak setelah beberapa hari siklus daya
  • Saya sempat melihat file Parquet, tetapi format itu tidak ramah untuk pekerjaan append-only
  • Saya mengimplementasikan cara mencatat event ke file IPC dan secara berkala "flush" ke file Parquet
  • Ini berfungsi dan efisien, tetapi tidak mudah untuk diimplementasikan dengan benar
  • Bagi pengembang biasa, CSV (atau JSONL) masih yang terbaik

• Hal yang tidak menyenangkan dari CSV adalah parser dan serializer yang ditulis cepat sering mengulangi kesalahan umum dalam menangani tanda kutip

  • Saya sudah lama waspada terhadap CSV, tetapi itu berubah setelah belajar Python dan memakai modul pustaka standar csv yang sangat bagus

• Jika ini benar-benar surat cinta, maka seharusnya ditulis dalam format CSV

• Sanggahan terhadap JSON tidak terlalu meyakinkan

  • Menambahkan nama ke setiap field tidak selalu diperlukan
  • Jika membandingkan CSV dan JSON, JSON memang sedikit lebih besar, tetapi itu merepresentasikan kemampuan bahwa kurung/struktur bisa sederhana atau kompleks
  • Karena CSV sederhana, orang sering tidak menggunakan pustaka parsing/encoding
  • Parser JSON selalu menghasilkan nilai yang diharapkan, dan bahasa yang dipakai kemungkinan menggunakan parser berbasis SIMD yang sangat efisien
  • Ada juga masalah standardisasi. Apakah file CSV memakai koma, spasi, titik koma, pipe, dan sebagainya; apakah memakai CR, LF, CRLF; apakah tanda kutip bisa di-escape; dan seterusnya
  • JSON tidak punya masalah ini
  • JSON punya tipe. Enam tipe lebih baik daripada tidak punya sama sekali
  • JSON memang tidak sempurna, tetapi secara umum lebih baik daripada CSV

• Sebagai orang yang menyukai format modern, ketika ragu saya menggunakan CSV atau JSONL

  • Karena pada dasarnya berupa teks biasa, format ini mudah dicari dengan grep dan bisa di-stream
  • Sebagian besar fitur yang tercantum dalam dokumen itu juga dimiliki JSONL
  • Format ini terkompresi dengan baik menggunakan gzip atau zstd
  • Kompresi memang sedikit menghilangkan keunggulan teks biasa, tetapi ripgrep tetap bisa mencari di file terkompresi
  • Keunggulan lain JSONL adalah mudah dipecah menjadi file-file yang lebih kecil