JSON, YAML, CSV: Hangi Veri Formatını Ne Zaman Kullanmalı?

Birkaç yıldır kod yazıyorsanız bu üç formatın da bir dosyada karşınıza çıktığına eminim. JSON her REST endpoint'inden akıyor. YAML; Kubernetes manifestlerinin, GitHub Actions workflow'larının ve kurduğunuz CLI'ların yarısının ortak dili. CSV ise pazarlama ekibinin "ham veri lazım" dediğinde mail attığı şey. Hepsi birbirine benziyor gibi görünür ve Multilities gibi araçlar formatlar arasında dönüşümü kolaylaştırır, ama dönüştürebiliyor olmak rastgele seçmek için bir gerekçe değildir.

Bu yazı her formatın nasıl çalıştığını, nerede parladığını, nerede dağıldığını ve deneyimli ekiplerin hangi durumda hangisini seçtiğini anlatıyor. Aynı veriyi üç farklı formatta göstereceğiz ki JSON YAML CSV fark soyut kalmasın.

Hızlı bir zihin haritası

Söz dizimine boğulmadan önce formatları kafanızda şöyle tutun:

• JSON, yapısal nesneler için bir serileştirme formatıdır. Bir makinenin başka bir makineyle konuştuğu, insanın nadiren okuduğu yerlerde tercih edilir.
• YAML, JSON'un neredeyse üst kümesi gibi davranan, insanların elle düzenlediği config dosyaları için optimize edilmiş bir formattır. Birinin scroll edip diff'leyeceğini ve PR'da review edeceğini varsayar.
• CSV ise tablo formatıdır. Her satırın aynı şekle sahip olduğunu ve tüketicinin muhtemelen bir spreadsheet, bir database COPY komutu ya da hızlı bir pandas read_csv çağrısı olduğunu varsayar.

JSON: API'lar ve JS için varsayılan

JSON yani JavaScript Object Notation, 2000'lerin başında JavaScript'ten ayrıştırıldı ve RFC 8259 olarak standartlaştırıldı. Altı temel tipi vardır: object, array, string, number, boolean ve null. Tüm söz dağarcığı bu kadar. Tarih yok, comment yok, trailing comma yok, referans yok. Bu minimalizm bilinçlidir: herhangi bir dil JSON'u birkaç yüz satır kodla parse edebilir, bu yüzden de gezegendeki neredeyse her HTTP API eninde sonunda JSON'da karar kılar.

Tarayıcılar JSON'u JSON.parse ile native parse eder, her backend stdlib'inde bir JSON modülü vardır, metin temsili dar geldiğinde MessagePack ya da CBOR gibi binary varyantlar devreye girebilir. Request/response payload'ları, log shipping, kalıcı JS state ve döküman veritabanları için JSON neredeyse her zaman doğru varsayılandır.

YAML: konfigürasyonun tatlı noktası

YAML başlangıçta Yet Another Markup Language idi, sonra YAML Ain't Markup Language olarak özyineli bir şekilde yeniden adlandırıldı. 1.2 sürümünde JSON'un katı bir üst kümesidir; JSON'da geçerli olan her şey aynı zamanda geçerli YAML'dır. Üzerine comment, multiline string, tekrar kullanım için anchor ve alias, açık tip etiketleri ve en önemlisi noktalama gürültüsünün çoğunu kaldıran indentation tabanlı bir söz dizimi ekler.

Bu okunabilirlik YAML'ın konfigürasyonda neden hakim olduğunu açıklar. Kubernetes manifestleri, Helm chart'ları, Ansible playbook'ları, GitHub Actions, GitLab CI, Docker Compose, OpenAPI spec'leri, dbt projeleri ve modern CLI'ların büyük çoğunluğu YAML okur. Bir insan dosyayı editör'de düzenleyip pull request'te review edecekse, YAML kazanır.

CSV: evrensel spreadsheet tokalaşması

CSV yani comma-separated values, web'den önce vardı ve RFC 4180 onu gevşekçe tanımlar. Çok basittir: ilk satır genelde başlıktır, sonraki her satır bir kayıttır ve alanlar bir ayraçla (genelde virgül, ama tab, noktalı virgül ve pipe da yaygındır) ayrılır. Ayraç, newline veya çift tırnak içeren stringler çift tırnağa alınır ve içerideki çift tırnaklar ikiye katlanarak escape edilir.

CSV; dünyadaki her spreadsheet'in, her BI aracının, her veritabanı bulk loader'ının ve elinde Python notebook olan her analistin tören yapmadan anladığı formattır. Nested veri için berbat, düz tablolar için harika bir formattır. Tüketici Excel'i açık bir insansa CSV neredeyse her zaman doğru cevaptır.

Aynı veri, üç format

Farkları somut bir örnekle netleştirelim. Üç kullanıcıdan oluşan bir liste düşünün; her birinin id, name, email, role ve tags alanları olsun. Önce JSON sürümü:

[
  {
    "id": 1,
    "name": "Ada Lovelace",
    "email": "ada@example.com",
    "role": "admin",
    "tags": ["founder", "math"]
  },
  {
    "id": 2,
    "name": "Linus Torvalds",
    "email": "linus@example.com",
    "role": "maintainer",
    "tags": ["kernel", "git"]
  },
  {
    "id": 3,
    "name": "Grace Hopper",
    "email": "grace@example.com",
    "role": "admin",
    "tags": ["compiler", "navy"]
  }
]

Aynı payload, YAML olarak

Noktalama nasıl ortadan kalkıyor görüyor musunuz? Yapı tamamen indentation ile aktarılıyor; tags listesini ister inline (flow stili, JSON'la aynı) ister blok olarak yazabiliyorsunuz. Comment'ler legal ve sıklıkla işe yarıyor.

# Staging ortamı için seed kullanıcılar
- id: 1
  name: Ada Lovelace
  email: ada@example.com
  role: admin
  tags:
    - founder
    - math
- id: 2
  name: Linus Torvalds
  email: linus@example.com
  role: maintainer
  tags: [kernel, git]   # kısa listelerde flow stili gayet temiz
- id: 3
  name: Grace Hopper
  email: grace@example.com
  role: admin
  tags:
    - compiler
    - navy

Ve CSV olarak

CSV iç içe geçmiş tags array'ini doğal olarak ifade edemez, bu yüzden düzleştirmek zorundayız. Yaygın bir konvansiyon listeyi pipe veya noktalı virgül gibi ikincil bir ayraçla birleştirmek ve bu seçimi bir yerde dokümante etmektir. Başlık satırı alan adlarının yerini alır ve her kayıt kendi satırındadır.

id,name,email,role,tags
1,Ada Lovelace,ada@example.com,admin,founder|math
2,Linus Torvalds,linus@example.com,maintainer,kernel|git
3,Grace Hopper,grace@example.com,admin,compiler|navy

Üç format, üç farklı boyut

Dosya boyutu insanların kabul ettiğinden daha önemli. Logging pipeline'ları, tarayıcı bundle'ları ve storage faturaları hep önemser. Yukarıdaki örnek için kabaca byte sayıları: pretty-print JSON yaklaşık 410 byte, minified 290; YAML yaklaşık 320 byte; CSV yaklaşık 200 byte. CSV düz veride rahat kazanıyor çünkü alan adlarını her satırda tekrarlamak yerine bir kez başlıkta yazıyor.

Nesting'e başladığınız anda tablo değişiyor. JSON ve YAML kayıt başına neredeyse sabit kalırken CSV ya sizin uydurduğunuz konvansiyonlarla düzleşmek zorunda kalıyor ya da birden fazla sheet'e patlıyor. Yirmi alanlı, derinlemesine nested tek bir kullanıcı için JSON ve YAML, kurabileceğiniz herhangi bir CSV'den daha küçük ve daha net olacaktır.

Pratikte hangi format nerede kazanıyor

Gerçek ekiplerin desenleri:

• JSON: HTTP API'lar, WebSocket payload'ları, tarayıcı localStorage'ı, log satırları (özellikle JSON Lines), MongoDB gibi döküman veritabanları ve servisler arası kontratlar.
• YAML: Kubernetes, Helm, Argo, Terraform Cloud workspace'leri, GitHub veya GitLab CI pipeline'ları, OpenAPI ve AsyncAPI spec'leri, insanların düzenlediği uygulama config'leri ve okunabilirliğin parse hızını yendiği infrastructure-as-code.
• CSV: analytics export'ları, CRM import'ları, ETL staging tabloları, makine öğrenmesi veri setleri, finans raporları ve Excel ya da Google Sheets'e gidecek her şey.
• Veriniz binary, çok yüksek throughput'lu veya servisler arasında güçlü tipliyse hiçbirine uzanmayın. Protobuf, Avro veya Parquet genelde doğru cevaptır.

Sizi ısıran JSON tuzakları

JSON'un minimalizmi avantaj ama birkaç tuzak da yaratıyor. Spec comment yasaklar; bu yüzden JSON ile yazılmış config dosyaları kendini açıklayamaz. Son array veya object elemanından sonraki trailing comma her modern dilin kabul etmesine rağmen yasadışıdır. Number'lar varsayılan olarak 64-bit float'tır; bu yüzden 2 üzeri 53'ten büyük herhangi bir integer sessizce hassasiyet kaybeder ve bu yüzden pek çok API büyük ID'leri string olarak serialize eder.

JSON'un native bir tarih tipi de yoktur. ISO 8601 string'leri de facto konvansiyondur ama siz ve tüketici üzerinde anlaşmak zorundasınız. Aynı object'te tekrarlanan key'ler grammar tarafından teknik olarak izinli ama parser'lar arasında undefined davranış üretir; güvenmeyin.

Sizi daha sert ısıran YAML tuzakları

YAML'ın esnekliği aynı zamanda zayıflığıdır. Indentation anlamlıdır; tab ile space'i karıştırmak ya da iki karakter boşluk kaybetmek dosyanızın anlamını sessizce değiştirir. Meşhur Norway problem hâlâ YAML 1.1 parser'larında ortaya çıkar: tırnaksız NO token'ı boolean false olarak parse edilir ve bu, ülke kodu listelerini birden fazla kez mahvetmiştir. YAML 1.2 bunu düzeltir ama pek çok araç hâlâ 1.1 semantiği ile geliyor.

Sayı, tarih veya boolean gibi görünen string'ler tırnak içine almazsanız zorla dönüştürülür. Anchor ve alias (&foo ve *foo söz dizimi) güçlüdür ama güvensiz YAML kabul ediyorsanız billion-laughs tarzı denial of service'e davetiye çıkarır. Kullanıcıdan gelen YAML'ı her zaman safe loader ile parse edin.

Sizi sessizce ısıran CSV tuzakları

CSV, doğru görünürken alttan alta bozuk olma ihtimali en yüksek formattır. Ayraç için standart yoktur; Avrupa locale'leri noktalı virgülle export eder çünkü virgül onlarda ondalık ayraçtır ve import eden tarafın bunu tespit etmesi gerekir. Tırnak içindeki newline'lar yasaldır ama naif satır parçalayıcıları yıkar. Excel bir CSV'yi açtığında telefon numaralarını ve uzun ID'leri seve seve bilimsel notasyona çevirir; bir insan görmeden veriniz mahvolmuş olur.

Encoding diğer mayın. CSV'nin encoding bildirimi yoktur; macOS'ta temiz açılan bir dosya UTF-8 ile Windows-1252 farkı yüzünden Windows'ta mojibake gösterebilir. Şüpheniz varsa UTF-8 BOM yazın, ayracı dokümante edin ve her string alanı tırnak içine alın.

Aralarında güvenle dönüştürmek

Gerçek sistemlerin çoğu birden fazla formatta yaşar. Vendor'dan CSV alırsınız, API için JSON'a çevirirsiniz, sonucu işleyen worker'ı konfigüre etmek için YAML üretirsiniz. Bu dönüşümleri elle yapmak hata kaynağıdır; bu yüzden Multilities adanmış dönüştürücülerle gelir.

JSON ve YAML arasında gidip geliyorsanız /tools/yaml-json her iki yönü de halleder ve mümkün olduğunda comment'leri korur. Tablo verisi için /tools/csv-json, CSV export'larını fixture dosyasına ya da Postman isteğine yapıştırabileceğiniz JSON array'lerine çevirir, finans birimine spreadsheet vermeniz gerektiğinde aynı yolu geri alır. Sadece bir JSON blob'unun insan eliyle yazılmış gibi okunmasını istediğinizde de /tools/json-formatter key'leri sıralar, indentation'ı düzeltir ve yapıyı tek seferde valide eder. JSON to YAML dönüşümünden CSV'yi JSON'a çevirmeye kadar veri formatı seçimi sürecinde elinizin altında olsun.

Karar listesi

Emin değilseniz bu listeyi yukarıdan aşağı okuyun ve ilk evet'te durun. Hangi format ne zaman sorusunun cevabı çoğu zaman bu kadar basit.

• Tüketici bir spreadsheet veya SQL bulk loader mı ve veri düz mü? CSV.
• Bir insan bu dosyayı code editor'de düzenleyip pull request'te review edecek mi? YAML.
• Tüketici bir program mı, özellikle network üzerinden, ve minimum tören maksimum araç desteği mi istiyorsunuz? JSON.
• Sabit şemaya sahip milyonlarca kaydı yüksek throughput'la serileştiriyor musunuz? Üçünü de bırakın, Protobuf, Avro veya Parquet'e uzanın.

Toparlarsak

Bu üç format birbiriyle yarışmaktan çok birer uzman. JSON evrensel değişim formatı, YAML insan dostu konfigürasyon dili, CSV ise developer olmayanların en iyi bildiği dil olduğu için ölmeyi reddeden spreadsheet tokalaşması. Hangisinin hangi iş için tasarlandığını ve tuzaklarını bilmek, temiz veri pipeline'ları üreten ekiplerle her cuma akşamı escaping bug'larıyla boğuşan ekipleri ayırır.

Dönüştürücü araçları yer imlerinde tutun, CSV'lerinizin ayraç ve encoding'ini bir yere yazın, YAML string'lerinizi şüphelendiğinizde tırnak içine alın ve unsigned 64-bit ID'lerin JavaScript'ten sağ çıkacağına asla güvenmeyin. Bunu yaparsanız seçtiğiniz format çoğunlukla arka plana çekilir ki iyi bir veri formatının yapması gereken tam olarak budur.