JSON ve CSV: Hangi Biçimi Kullanmalısınız?

Bunu neden yazıyoruz: Biz Geonode olarak, veri toplayan kişilere proxy satıyoruz; bu nedenle, kazınmış birçok veri kümesinin diske yanlış formatta kaydedildiğini sık sık görüyoruz. Uyarı kısmı basit: format seçimi proxy’lerle hiçbir ilgisi yoktur ve buradaki kararınızdan hiçbir kazanç elde etmiyoruz. Bunun etkilediği şeyler ise depolama faturanız, işleme süreniz ve virgül içeren bir alanın neden sonraki aşamadaki içe aktarmayı bozduğunu bulmak için haftanızın ne kadarını hata ayıklamaya harcadığınızdır. Bunlar gerçek maliyetlerdir ve ilk kaydı yazmadan önce tamamen sizin kontrolünüz altındadır.

Temel Fark: Biri Standart, Diğeri Alışkanlık

İlk olarak anlaşılması gereken nokta budur, çünkü geri kalan her şey bundan kaynaklanır.

JSON standartlaştırılmıştır. RFC 8259 bir İnternet Standartları Yolu belgesidir. Resmi bir dilbilgisi ve zorunlu gereklilikleri vardır; "JSON'un diğer spesifikasyonlarıyla tutarsızlıkları" ortadan kaldırmak ve "spesifikasyon hatalarını" düzeltmek amacıyla açıkça oluşturulmuştur. İki JSON ayrıştırıcısı arasında uyuşmazlık varsa, en az biri yanlıştır ve spesifikasyon hangisinin yanlış olduğunu belirtir.

CSV ise standartlaştırılmamıştır. RFC 4180 bilgilendirme amaçlıdır ve bunu en yalın şekilde kendisi de belirtir:

CSV biçimi için çeşitli spesifikasyonlar ve uygulamalar bulunsa da... mevcut resmi bir spesifikasyon bulunmamaktadır; bu da CSV dosyalarının çok çeşitli şekillerde yorumlanmasına olanak tanır. Bu bölüm, çoğu uygulamada izlendiği görülen biçimi belgelemektedir.

"Çoğu uygulamada izlendiği görülen" ifadesi, bu cümlede büyük önem taşımaktadır. RFC 4180, bir tanım değil, yaygın uygulamaların bir açıklamasıdır. İki CSV ayrıştırıcısı birbiriyle uyuşmuyorsa, her ikisi de haklı olabilir.

CSV sorunlarının bu tür bir karakterde olmasının nedeni budur. Bunlar, hatalardan ziyade, hiç kimsenin tam olarak tanımlamadığı bir formatla ilgili meşru anlaşmazlıklardır — bu da, dosyanın yazılmasından aylar sonra, başka birinin araçlarında entegrasyon sınırlarında ortaya çıkmalarının nedenidir.

CSV’nin Aslında Neleri Garanti Ettiği

RFC 4180, yaygın olarak kabul edilen kuralları belgelemektedir ve bu kuralların neler olduğunu bilmek önemlidir; zira sorunlar genellikle bu kurallardan sapmalardan kaynaklanır.

Kayıtlar CRLF ile ayrılır. Son kaydın sonunda satır sonu olabilir veya olmayabilir. İsteğe bağlı bir başlık satırı olabilir. Alanlar virgülle ayrılır, her satırda aynı sayıda alan bulunmalıdır ve "Boşluklar bir alanın parçası olarak kabul edilir ve göz ardı edilmemelidir."

Tırnak işaretleri konusu işleri ilginç hale getirir:

Her alan çift tırnak içine alınabilir veya alınmayabilir (ancak Microsoft Excel gibi bazı programlar çift tırnak işaretlerini hiç kullanmaz).

Ayrıca, "satır sonu karakterleri (CRLF), çift tırnak işaretleri ve virgül içeren alanlar çift tırnak işaretleri içine alınmalıdır"; gömülü bir çift tırnak işareti ise "önüne başka bir çift tırnak işareti eklenerek" kaçırılmalıdır.

Modal fiillere dikkat edin. "Olabilir veya olmayabilir." "Olmalıdır." RFC, eğilimleri açıklamaktadır. Excel ile ilgili parantez içi açıklama ise, belgenin 2005 yılında, dünyada en yaygın olarak kullanılan CSV aracının bu kuralı takip etmediğini kabul ettiğini göstermektedir.

Pratik sonuçlar, sizi ne kadar zorlayacaklarına göre sıralanmış şekilde:

Sınırlayıcılar yerel ayarlara göre değişir. Ondalık ayırıcı olarak virgül kullanan ülkeler, genellikle alan sınırlayıcısı olarak noktalı virgül kullanır. Almanya’daki bir iş arkadaşınız tarafından dışa aktarılan bir dosya, virgül tabanlı bir okuyucu ile ayrıştırılamayabilir ve ikiniz de yanlış bir şey yapmamış olursunuz.

Kodlama belirtilmemiştir. CSV dosyasında karakter kodlamasını belirten hiçbir şey yoktur. UTF-8, Latin-1, Windows-1252 ve UTF-16, hepsi CSV'ye benzeyen dosyalar üretir; ancak yanlış ayrıştırıcıda bu dosyalar bozuk karakterler olarak okunur. Bayt sırası işaretleri tutarsız bir şekilde görünür ve basit başlık ayrıştırmasını bozar.

Satır sonları değişkenlik gösterir. CRLF, LF ve — satır sonu karakterleri içeren alanlarda — tırnak işaretleri içindeki “”.

Veri türleri yoktur. Her şey metindir. 007, 7 olur; 2026-09-02, bir araçta tarih, başka bir araçta ise bir dize haline gelir; baştaki + ise kaybolur. Bir CSV dosyasını elektronik tablo aracılığıyla iki yönlü aktarmak, gerçekten de veri kaybına neden olur.

Ayrıca CSV dosyaları kod çalıştırabilir. =, +, - veya @ ile başlayan bir alan, elektronik tablo yazılımı tarafından bir formül olarak yorumlanabilir. Bu, formül enjeksiyonudur; kullanıcıların sağladığı verileri, birisinin Excel'de açacağı bir CSV dosyasına yazdığınızda ortaya çıkan gerçek bir güvenlik açığıdır. Bu sorunu önlemek için, bu tür alanların başına tek tırnak işareti eklemeli veya yazmadan önce başka bir şekilde etkisiz hale getirmelisiniz. İş akışınız, web'den toplanan veya kullanıcılar tarafından gönderilen içerikten CSV dosyaları oluşturuyorsa, bu konuyu özenle ele almanızda fayda vardır.

JSON'un Sağladığı Garantiler ve Hala Sorun Çıkaran Noktalar

JSON'un spesifikasyonu daha katıdır ve buna bağlı olarak sağladığı garantiler de daha güçlüdür.

Kodlama konusu kesinleşmiştir. RFC 8259 §8.1: "Kapalı bir ekosistemin parçası olmayan sistemler arasında alışverişi yapılan JSON metni, UTF-8 kullanılarak kodlanmalıdır." Ayrıca, uygulamaların ağ üzerinden aktarılan JSON metinlerine "bayt sırası işareti EKLEYMEMELİ" olduğunu belirtirken, ayrıştırıcıların bu işareti yok saymasına izin verir. CSV'yi zorlayan kodlama tahminiyle ilgili sorunların tamamı burada mevcut değildir.

Türler mevcuttur. Dizgiler, sayılar, boole değerleri, null, nesneler ve diziler dilbilgisinde birbirinden ayırt edilebilir. "007" ve 7 farklı değerlerdir ve farklı kalırlar.

İç içe geçme yapısı doğaldır. Hiyerarşik veriler, kimsenin üzerinde anlaşamadığı bir kural gerektirmek yerine, açık bir temsil biçimine sahiptir.

JSON'un insanların sandığı kadar mutlak olmadığı iki nokta:

Yinelenen anahtarlar sadece tavsiye edilmez. Spesifikasyon şöyle der: "Bir nesne içindeki isimler benzersiz OLMALIDIR" — OLMALIDIR, ZORUNLU DEĞİLDİR. Ve sonuç konusunda da açıktır: isimler benzersiz olmadığında, "böyle bir nesneyi alan yazılımın davranışı öngörülemez. Birçok uygulama yalnızca son isim/değer çiftini bildirir. Diğer uygulamalar ise bir hata bildirir veya ayrıştırmada başarısız olur."

Sayı hassasiyeti bir kural değil, bir kılavuzdur. Spesifikasyon, uygulamaların aralık ve hassasiyet konusunda sınırlar belirlemesine izin verir ve iyi bir birlikte çalışabilirliğin, IEEE 754 binary64 standardının sağladıklarından fazlasını beklememekten kaynaklandığını belirtir. Hata durumunu doğrudan şu şekilde belirtir: "1E400 veya 3.141592653589793238462643383279 gibi bir JSON sayısı, potansiyel birlikte çalışabilirlik sorunlarına işaret edebilir."

Uygulamada bu, ürünle birlikte gelen sessiz bir hatadır. Büyük 64-bit tanımlayıcılar, JavaScript sayıları olarak ayrıştırıldığında hassasiyet kaybeder; hiçbir hata atılmaz ve iki farklı kayıt aynı değer haline gelebilir. Standart çözüm, büyük tamsayıları dize olarak serileştirmektir — bunu, verileri son aşamada keşfetmek yerine, verileri yazarken yapmakta fayda vardır. Bu konunun ayrıştırıcı tarafını JSON.parse kılavuzumuzda ele aldık.

Boyut ve Hız

Bu ikilem gerçektir ve sonuç her zaman insanların beklediği gibi olmaz.

CSV, düz tablo verileri için daha küçüktür; genellikle büyük bir farkla, çünkü alan adları her kayda değil, başlıkta bir kez görünür. Beş alandan oluşan bir milyon satır, CSV'de beş alan adı depolarken, JSON'da beş milyon alan adı depolar.

Sıkıştırma, bu farkı önemli ölçüde azaltır. Tekrarlanan anahtarlar son derece iyi sıkıştırılır. gzip uygulandıktan sonra, tekdüze kayıtlarda JSON'un getirdiği ek yük genellikle makul bir düzeye düşer — bazen de tamamen ortadan kalkar. Sıkıştırılmış verileri depoluyorsanız (ki depolamalısınız), CSV'nin boyut avantajı, ham rakamların gösterdiği kadar güçlü değildir.

CSV, basit durumlarda daha hızlı, doğru durumlarda ise daha yavaş ayrıştırılır. Basit bir split(',') çok hızlıdır ancak yanlıştır. Tırnak işaretlerini, gömülü satır sonlarını ve kaçış karakterli tırnak işaretlerini doğru şekilde işleyen, standartlara uygun bir ayrıştırıcı, maliyet açısından JSON ayrıştırmasına daha yakındır. Çoğu CSV hız karşılaştırması, yanlış bir ayrıştırıcıyı doğru olanla sessizce karşılaştırmaktadır.

JSON’un gerçek maliyeti CPU değil, bellektir. Tek bir büyük JSON belgesinin ayrıştırılması için genellikle bellekte tutulması gerekir. Bir CSV ise sabit bellekteki bir akıştan satır satır işlenebilir. On gigabaytlık bir dosya için bu fark, bir performans detayı değildir; belirli bir makinede neyin mümkün neyin imkansız olduğu arasındaki farktır.

İşte bir sonraki bölümde çözülecek sorun tam da budur.

Orta Yol: JSON Lines

JSON Lines — NDJSON veya satır sonu ile sınırlandırılmış JSON olarak da bilinir — her satırda tek bir JSON belgesi barındırır ve sarma dizisi içermez. Bu, çoğu kişinin kullanması gereken ancak nispeten az kişinin bildiği bir biçimdir.

{"id": 1, "name": "Ada", "tags": ["engineer"]}
{"id": 2, "name": "Grace", "tags": ["engineer", "admiral"]}

Size sunduğu avantajlar:

Akış işleme. Her satır bağımsız olarak ayrıştırılır, böylece yüz gigabaytlık bir dosyayı sabit bellek içinde işleyebilirsiniz. Bu, JSON’un en büyük pratik dezavantajını ortadan kaldırır.

Yalnızca ekleme yazma. Yeni kayıtlar dosyanın sonuna eklenir. Kapatılması gereken bir sarmalayıcı dizi yoktur; bu da, dosyanın yeniden yazılmasına gerek kalmadığı ve yazma işlemi sırasında bir işlem durursa çıktının bozulmayacağı anlamına gelir.

Kısmi kurtarma. Kesik bir dosyadan bile her tam satır elde edilebilir. Kesik bir JSON dizisi ise hiçbir şey vermez — tek bir köşeli parantez eksik olsa bile tüm belge ayrıştırılamaz hale gelir. Uzun süren bir iş tarafından yazılan her şey için, bu özellik tek başına bu seçimi haklı kılar.

Basit paralellik. Satırlara bölünür ve parçalar bağımsız olarak işlenir. Satırlar arası durum bilgisi yoktur.

Tam JSON semantiği. Türler, iç içe geçme ve belirsizliğe yer bırakmayan kodlama; hepsi korunur.

Maliyetler makul ve düşüktür: CSV'den biraz daha büyüktür, elektronik tabloda doğrudan açılamaz ve her kayıt kendi anahtarlarını taşır. Kazınmış veriler, günlük çıktıları, olay akışları ve aşamalı olarak eklenen her şey için bu, doğru varsayılan seçenektir — ve koleksiyon çıktısını diske yazan herkese önerdiğimiz seçenektir.

İkisinin Ötesinde: Parquet ve Benzerleri

Bilmeniz gereken bir konu; zira analitik iş yükleri söz konusu olduğunda, “JSON mu, CSV mi?” sorusu bazen tamamen yanlış bir sorudur.

Parquet, sütun tabanlı ve ikili bir formatıdır. Her sütunu bitişik olarak depolar; bu da, kırk değer içeren üç sütuna dokunan bir sorgunun yalnızca bu üç sütunu okuduğu anlamına gelir. Bir şema içerir, benzer değerler bir arada olduğu için satır odaklı metinlere kıyasla çok daha iyi sıkıştırma sağlar ve veri türlerini tam olarak korur.

Avantajları: Büyük veri kümeleri üzerinde yapılan analitik sorgular, büyük boyutlu verilerin uzun vadeli depolanması ve veri ambarına veri besleyen tüm iş akışları. CSV'ye kıyasla sıkıştırma oranları genellikle birkaç kat daha yüksektir ve sorgu performansı farkları ise daha da büyüktür.

Zayıf olduğu alanlar: insan tarafından okunamaz, JSON Lines'ta olduğu gibi sonuna ekleme yapılamaz ve bir metin düzenleyicisi yerine bir kütüphane gerektirir. Akış, kişilerle veri alışverişi ve küçük veriler için metin biçimleri hâlâ en uygun seçenektir.

Yaygın ve mantıklı bir mimari: ekleme yapmaya elverişli ve veri kaybına dayanıklı olduğu için verileri JSON Lines formatında toplayın, ardından analiz ve arşivleme amacıyla toplu olarak Parquet formatına dönüştürün. Her format, özelliklerinin faydalı olduğu alanlarda kullanılmalıdır.

İşe Göre Seçim

Tabloya ihtiyaç duymadan çoğu durumu çözen üç kural.

Veriler düz, tek tipse ve bir elektronik tabloya veya toplu yükleyiciye aktarılacaksa, CSV kullanın. Bunlar gerçekten de CSV’nin güçlü yanlarıdır ve başka hiçbir format bunları bu kadar rahat bir şekilde gerçekleştiremez. Özellikle veritabanına toplu içe aktarma gerçek bir avantajdır — çoğu motor, JSON için değil, CSV için hızlı bir yol sunar.

Veriler iç içe geçmişse, şekli değişkense veya kullanıcının yazdığı herhangi bir şey içeriyorsa, JSON veya JSON Lines kullanın. İç içe geçmiş verileri CSV'ye düzleştirmek için bir kural sistemi oluşturmak gerekir ve bu amaçla oluşturulan her kural sistemi hataların kaynağı olmuştur. Öte yandan, kullanıcı metinleri virgül, tırnak işareti ve satır sonu karakterleri içerir; bunlar ise tam olarak CSV'nin en az güvenilir şekilde işlediği unsurlardır.

Kayıtları sürekli olarak yazıyorsanız, JSON Lines kullanın. CSV kullanmayın, çünkü CSV’de veri türleri yoktur ve bunları kaybedersiniz. JSON dizisi de kullanmayın, çünkü bu diziye güvenli bir şekilde ekleme yapılamaz ve bir işlemin çökmesi durumunda dosyayı çözümleyemeyeceğiniz bir dosya kalır.

İnsanlar Ayrıca Şunu Soruyor

JSON, CSV’den daha mı iyidir?

Farklı kullanım alanlarına göre, hem evet hem hayır. JSON, veri türleri, iç içe geçme ve zorunlu UTF-8 kodlaması içeren resmi bir standarttır. CSV ise düz tablo verileri için daha az yer kaplar, akışa doğal olarak uygundur ve elektronik tablolarda açılabilir. Daha güçlü bir argüman ise, CSV'nin resmi bir spesifikasyonu olmamasıdır — RFC 4180 bunu açıkça belirtir — bu da onu farklı araçlar arasında daha az öngörülebilir kılar.

CSV dosyam neden Excel'de bozuluyor?

Genellikle kodlama veya sınırlayıcıdan kaynaklanır. CSV dosyaları karakter kodlamalarını belirtmez, bu nedenle Excel tahminde bulunur; ondalık ayırıcı olarak virgül kullanan yerel ayarlar ise noktalı virgül sınırlayıcısını bekler. Her iki sorun da, bu özelliklerin hiçbirinin belirtilmediği bir biçimin doğasında vardır. BOM ile UTF-8 olarak dışa aktarma, diğer ayrıştırıcıları karıştırma pahasına, özellikle Excel için genellikle yardımcı olur.

JSON Lines nedir ve ne zaman kullanmalıyım?

Satır başına bir JSON belgesi ve sarma dizisi içermez. Kayıtları aşamalı olarak yazdığınızda kullanın — kazınmış veriler, günlükler, olay akışları. Sabit bellekte akış sağlar, güvenli bir şekilde ekleme yapar, her tam satırın bozulmadan kalmasıyla kesilmeye dayanır ve tam JSON türlerini ve iç içe geçme yapısını korur.

CSV, JSON'dan daha mı küçüktür?

Sıkıştırılmamış ve düz, tek tip veriler için genellikle büyük bir farkla daha küçüktür; çünkü alan adları her kayıt için ayrı ayrı değil, yalnızca bir kez görünür. Sıkıştırma sonrasında, tekrarlanan anahtarlar çok iyi sıkıştırıldığından aradaki fark keskin bir şekilde azalır. Sıkıştırılmış verileri depoluyorsanız, CSV'nin boyut avantajı ham rakamların gösterdiği kadar güçlü değildir.

CSV, iç içe geçmiş verileri işleyebilir mi?

Doğal olarak işleyemez. Herhangi bir iç içe geçme, sizin oluşturacağınız bir kural gerektirir — noktalı sütun adlarıyla düzleştirme, hücrelerin içindeki JSON dizeleri veya birbiriyle ilişkili birden fazla dosya. Bunların hepsi işe yarar, ancak hepsi de CSV dosyanızın, sizin belirlediğiniz özel kural olmadan genel araçlar tarafından artık okunamaz hale gelmesi anlamına gelir; oysa CSV’yi kullanmanın başlıca nedeni de budur.

JSON mu, CSV mi daha hızlı ayrıştırılır?

Basit durumlarda CSV daha hızlıdır, ancak bu karşılaştırma genellikle adil değildir — hızlı bir split(',') doğru bir CSV ayrıştırıcısı değildir ve tırnak işaretlerini ve gömülü satır sonlarını düzgün işleyen bir ayrıştırıcının maliyet açısından JSON’a çok daha yakındır. Daha önemli fark bellek kullanımıdır: CSV satır satır işlenirken, bir JSON belgesinin genellikle bir bütün olarak yüklenmesi gerekir; bu sorunu JSON Lines giderir.

JSON’da yinelenen anahtarlar izin verilir mi?

Spesifikasyon, isimlerin “MUTLAKA” değil, “BENZERSİZ OLMALIDIR” diyor; dolayısıyla teknik olarak izin verilir. Ayrıca, yinelenen anahtarlar olduğunda davranışın öngörülemez olduğu konusunda da uyarıyor — bazı ayrıştırıcılar sonuncuyu korur, bazıları hata verir, bazıları ise tamamen başarısız olur. Yinelenen anahtarları, belgeyi üreten her neyse, onun bir hatası olarak değerlendirin.

Kazınmış veriler için hangi formatı kullanmalıyım?

Çoğu durumda JSON Lines. Kazınmış kayıtlar sıklıkla iç içe geçmiş ve değişken şekillere sahiptir; CSV bu tür verileri kötü işler. Ayrıca, koleksiyon artımlıdır; bu da JSON dizilerinin kötü işlediği bir durumdur. Veriler gerçekten düz bir yapıya sahipse ve bir elektronik tabloya aktarılacaksa veya toplu yükleme yapılacaksa CSV uygun bir seçenektir — ayrıca, kazınan metinden CSV dosyası oluştururken, formül enjeksiyonunu önlemek için =, +, - veya @ ile başlayan alanları etkisiz hale getirin.

Sonuç

Bu kararı kolaylaştıran bakış açısı, “yapılandırılmış mı, yoksa basit mi” sorusu değildir. Asıl fark, bu formatlardan birinin bir teknik şartnameye sahip olması, diğerinin ise yaygın uygulamaların açıklamasını içermesidir. RFC 8259, JSON'un ne yapması gerektiğini belirtir; RFC 4180 ise CSV dosyalarının genellikle ne yaptığını gösterir ve bunu kendi sözleriyle ifade eder.

Bu fark, temelde her CSV sorununun kaynağıdır — bildirilmemiş kodlamalar, yerel ayara bağlı sınırlayıcılar, tutarsız tırnak işaretleri, elektronik tablo aracılığıyla sessizce kaybolan türler ve formüllere dönüşen alanlar. Bunların hiçbiri, herhangi birinin ayrıştırıcısındaki hatalar değildir. Bunlar, hiçbir zaman tam olarak tanımlanmamış bir formatın öngörülebilir sonuçlarıdır.

Verileri okumak yerine yazan çoğu kişi için çözüm JSON Lines’tır, ancak bu format yeterince benimsenmemiştir. JSON’un türlerini, iç içe geçme yapısını ve yerleşik kodlamasını korurken, tek gerçek zayıflığını ortadan kaldırır — akış sağlar, güvenli bir şekilde ekleme yapar ve kesik bir yazma işleminde bile her tam kaydı bozulmadan korur. CSV’yi, gerçekten en iyi yaptığı iki iş için saklayın: düz bir tabloyu bir elektronik tabloda açacak birine aktarmak ve bir veritabanına toplu yükleme yapmak. Veri kümesi büyük ve analitik ise, bu iki metin biçimi de doğru nihai hedef değildir; sütunlu bir biçime dönüştürün ve her biçimin tasarlandığı işi yapmasına izin verin.