CSV Formatına Bir Aşk Mektubu

• CSV’nin yerini alacak "üstün" formatlar sık sık tanıtılıyor, ancak bunların çoğu önyargılı karşılaştırmalara dayanıyor ve CSV’nin gerçek güçlü yanlarını göz ardı ediyor
• Bu yazı CSV’nin kusursuz olduğunu söylemiyor; amaç, yeterince takdir edilmeyen avantajlarını görünür kılmak
• CSV’den nefret etmenin havalı göründüğü havaya karşı, CSV’nin gerçek değerini yeniden hatırlatıyor

1. CSV son derece basittir

• CSV’nin tanımı başlığında saklıdır: "virgülle ayrılmış değerler"
• Satırlar satır sonlarıyla, sütunlar virgüllerle ayrılır
• Bir değerde virgül ya da satır sonu varsa tırnak içine alınır; tırnağın kendisi ise çift tırnakla gösterilir
• Karmaşık bir spesifikasyon olmadan herkes tarafından sezgisel olarak anlaşılabilir ve kullanılabilir
• Yine de doğru ayrıştırma için özel bir CSV ayrıştırıcısı kullanmak hâlâ gereklidir

2. CSV kolektif bir fikirdir

• Bir sahibi yoktur, özelleştirilmemiştir
• RFC 4180 vardır, ancak çoğu kişi bunu yalnızca referans olarak görür
• Dünya çapındaki geliştiricilerin örtük biçimde paylaştığı ortak kurallara dayanan özgür bir formattır

3. CSV bir metindir

• JSON, YAML ve XML gibi insan tarafından okunabilen saf metin formatıdır
• Herhangi bir metin düzenleyiciyle açılabilir, ek araç olmadan içeriği kontrol etmek mümkündür
• Kodlama biçimi de serbestçe seçilebilir

4. CSV streaming için optimize edilmiştir

• Satır satır okunan bir yapı olduğu için bellek tüketimi çok düşüktür
• Basit bir kodla bile birkaç KB bellek kullanarak birkaç gigabayt veriyi işlemek mümkündür
• Parquet gibi sütun odaklı formatlarda streaming işleme zordur ve karmaşık buffering gerekir
• Dezavantajı ise yalnızca belirli sütunlara bakmak istediğinizde bile tüm satırı okumanız gerekmesidir

5. CSV’ye veri eklemek kolaydır

• Dosyayı append modunda(a+) açıp sona yeni satırlar eklemek son derece kolaydır
• Buna karşılık Parquet gibi sütun odaklı formatlarda satır eklemek verimsiz ve karmaşıktır

6. CSV dinamik tipleri destekler

• Sabit tipler olmadığı için veriyi esnek biçimde yorumlamak mümkündür
• Örneğin JavaScript 64 bit tamsayıları düzgün biçimde gösteremez, ancak CSV bu tür kısıtlar olmadan kullanılabilir
• Diller arası uyumluluk ve esneklik açısından avantaj sağlar
• Ancak yanlış yorumlanırsa hata oluşabilir → kullanırken dikkat gerekir
• Yüksek performans gerektiğinde metni decode etmeden, doğrudan binary düzeyde işlemek de mümkündür

7. CSV sadedir

• Header yalnızca dosyanın en başında bulunduğundan format tekrarı neredeyse yoktur
• JSON ve XML’de anahtarların tekrarlanması nedeniyle overhead yüksektir
• String gösterimi zaten sadedir ve formatın kendi overhead’i de (virgül, tırnak vb.) çok düşüktür

8. Ters çevrilmiş CSV de hâlâ geçerlidir

• CSV bayt düzeyinde ters çevrilse bile hâlâ geçerli bir CSV’dir
• Bunun nedeni çift tırnak escape yöntemidir; çünkü palindromik bir escape biçimidir
• Bu özellik sayesinde CSV dosyasının son kısmını çok verimli biçimde okumak mümkündür
• Örneğin yarıda kesilmiş bir süreci sürdürürken, yeniden başlatmak için dosyanın yalnızca son birkaç satırını okumak yeterli olabilir

9. Excel CSV’den hoşlanmaz

• Excel’in rahatsız olduğu bir formatsa, bu belki de aslında doğru yolda olduğunuzun işaretidir

[ng0301]

En basiti en iyisidir!

[ethanhur]

Daha kötüsü daha iyidir!

[GN⁺]

Hacker News görüşü

• CSV ve INI dosyalarını sevme nedenim, basit, metin tabanlı olmaları, biçimde kodlanmış tipler içermemeleri ve yalnızca dizelerden oluşmaları

  • Resmî bir standardının olmaması bir dezavantaj, ama işlerini iyi yapıyorlar
  • INI'ye yönelik TOML eleştirisini yer imlerime eklemiştim
  • TOML eleştirisinin ilk satırının CSV için de geçerli olduğunu düşünüyorum: farklı lehçelerin bir birleşimi

• CSV zarif, ama ölümcül bir kusuru var: tırnak işaretleri "yerel olmayan" bir etkiye sahip

  • Örneğin, 1. bayttaki tek bir tırnak işareti, 1000000. bayttaki virgülün anlamını değiştirebilir
  • Bu da iki rahatsız edici sonuca yol açıyor
    • CSV işlemesini paralelleştirmek zor
    • Veri bozulması dosyanın okunabilirliğini ciddi biçimde etkiliyor (tek bir tırnak işaretinin eksik ya da fazla olması her şeyi bozabilir)
  • Bu yüzden bugünlerde basit tablo verisi serileştirmede CSV yerine basit escaping tercih ediyorum

• CSV'nin en iyi yanı, herkesin 30 dakikada bir parser yazabilmesi

  • 90'ların başındaki verileri modern web servislerine kolayca aktarabiliyorsunuz
  • En kötü yanı da, herkesin 30 dakikada bir parser yazabilmesi
  • Hatalı uygulamalar, bozuk veriler ve tuhaf tanımsız davranışlar ortaya çıkması çok kolay
  • JSON ve YAML'de de benzer sorunlar var
  • XML biraz çirkin görünse de en sağlamı o gibi duruyor

• CSV'yi seven biri muhtemelen kurumsal ortamda CSV injection önleme işiyle uğraşmak zorunda kalmamıştır

  • Web'de iyi kaynak sayısı az
  • En iyi kaynak <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">burada</a>

• CSV'yi sevmek için birçok neden var

  • C ile program yazıp çeşitli şeyleri doğrudan CSV olarak çıktılayabilirsiniz
  • Neredeyse her veritabanından ya da genel herhangi bir "şey"den CSV'ye kolayca dönüştüren basit bir middleware yazabilirsiniz
  • CSV'yi Excel'e atıp istediğiniz her şeyi yapabilirsiniz
  • ini dosyalarını da seviyorum. Not Defteri'nde doğrudan düzenlenebiliyorlar
  • Ama keşke genel bir taslak/yapı olsaydı

• Son zamanlarda Raspberry Pi tabanlı bir çözüm geliştiriyorum

  • İlk uygulama SQLite veritabanı kullanıyordu, ancak birkaç gün içinde, güç döngülerinden sonra bozuldu
  • Parquet dosyalarına baktım ama append-only iş yüklerine pek uygun değiller
  • Olayları bir IPC dosyasına kaydedip bunları periyodik olarak Parquet dosyalarına "flush" eden bir yöntem uyguladım
  • Çalışıyor ve verimli, ama doğru şekilde uygulamak kolay değil
  • Ortalama geliştirici için CSV (veya JSONL) hâlâ en iyisi

• CSV'nin sıkıcı tarafı, hızlıca yazılmış parser ve serializer'ların tırnak işaretlerini yanlış ele alma gibi yaygın hataları tekrar etmesi

  • Uzun süre CSV'ye mesafeli durdum, ama Python öğrenip mükemmel csv standart kütüphane modülünü kullanınca fikrim değişti

• Eğer bu gerçekten bir aşk mektubu olsaydı, CSV formatında yazılmış olurdu

• JSON lehine karşı argümanlar pek ikna edici değil

  • Her alana isim eklemek gerekli değil
  • CSV ile JSON karşılaştırıldığında JSON biraz daha büyük, ama parantezlerin basit ya da karmaşık olabilen yapıları ifade etme yeteneğini gösteriyor
  • CSV basit olduğu için çoğu zaman parsing/encoding kütüphaneleri kullanılmıyor
  • JSON parser'ları her zaman beklenen değeri üretir ve diliniz muhtemelen çok verimli bir SIMD tabanlı parser kullanıyordur
  • Standardizasyon sorunu da var. CSV dosyasının virgül, boşluk, noktalı virgül, pipe vb. mi kullandığı; CR, LF, CRLF mi kullandığı; tırnak işaretlerinin escape edilip edilemediği gibi sorular var
  • JSON'da bu sorunlar yok
  • JSON tip içerir. 6 tip, hiç olmamasından iyidir
  • JSON mükemmel değil, ama genel olarak CSV'den daha iyi

• Modern formatları seven biri olarak, şüphe duyduğumda CSV ya da JSONL kullanıyorum

  • Çoğunlukla düz metin oldukları için grep ile kolayca aranabiliyor ve stream edilebiliyorlar
  • Belgede listelenen özelliklerin çoğu JSONL için de geçerli
  • gzip ya da zstd ile iyi sıkışıyorlar
  • Sıkıştırma, düz metnin bazı avantajlarını ortadan kaldırıyor, ama ripgrep sıkıştırılmış dosyalarda da arama yapabiliyor
  • JSONL'nin bir başka avantajı da daha küçük dosyalara kolayca bölünebilmesi