JSON vs YAML vs CSV: Welches Datenformat sollten Sie nutzen?

Wenn Sie seit mehr als ein paar Jahren Software ausliefern, haben Sie mit ziemlicher Sicherheit jedes dieser drei Formate irgendwann in eine Datei getippt. JSON sprudelt aus jedem REST-Endpunkt. YAML ist die Lingua franca von Kubernetes-Manifesten, GitHub-Actions-Workflows und der Hälfte der CLIs, die Sie installieren. CSV ist das, was Marketing Ihnen mailt, wenn es "die Rohdaten" haben will. Sie wirken austauschbar, und Tools wie Multilities machen das Konvertieren trivial - aber dass Sie konvertieren können, heißt nicht, dass Sie zufällig wählen sollten.

Dieser Artikel beschreibt, wie jedes Format wirklich funktioniert, wo es glänzt, wo es zusammenbricht und welche Faustregeln erfahrene Teams zur Auswahl nutzen. Wir betrachten denselben Datensatz in drei Darstellungen, damit die Abwägungen konkret und nicht abstrakt sind.

Ein schnelles mentales Modell

Bevor Sie in Syntax ertrinken, halten Sie die Formate so im Kopf:

• JSON ist ein Serialisierungsformat für strukturierte Objekte. Sie greifen darauf zurück, wenn eine Maschine mit einer anderen sprechen muss und Menschen die Ausgabe nur gelegentlich lesen.
• YAML ist eine Art Obermenge von JSON, optimiert für Menschen, die Konfigurationsdateien von Hand bearbeiten. Es geht davon aus, dass eine Person scrollen, diffen und reviewen wird.
• CSV ist ein tabellarisches Format. Es geht davon aus, dass jede Zeile dieselbe Form hat und der Konsument vermutlich eine Tabellenkalkulation, ein Datenbank-COPY-Befehl oder ein schnelles pandas-read_csv ist.

JSON: der Standard für APIs und JS

JSON, JavaScript Object Notation, wurde Anfang der 2000er aus JavaScript extrahiert und als RFC 8259 standardisiert. Es kennt sechs primitive Typen: Object, Array, String, Number, Boolean und null. Das ist das gesamte Vokabular. Es gibt keine Datumstypen, keine Kommentare, keine nachgestellten Kommas und keine Referenzen. Der Minimalismus ist der Punkt: Jede Sprache kann JSON in ein paar hundert Codezeilen parsen, weshalb sich jede HTTP-API auf dem Planeten irgendwann darauf einigt.

Browser parsen JSON nativ mit JSON.parse, jede Backend-Standardbibliothek hat ein JSON-Modul, und binärfreundliche Varianten wie MessagePack und CBOR existieren, wenn Sie der Textdarstellung entwachsen. Für Request/Response-Payloads, Log-Versand, persistierten JS-State und Dokumentdatenbanken ist JSON nahezu immer die richtige Standardwahl.

YAML: der Sweet Spot für Konfiguration

YAML, ursprünglich Yet Another Markup Language und später rekursiv in YAML Ain't Markup Language umbenannt, ist in Version 1.2 eine strenge Obermenge von JSON. Alles, was in JSON legal ist, ist auch legales YAML, doch YAML ergänzt Kommentare, mehrzeilige Strings, Anker und Aliasse zur Wiederverwendung, explizite Typ-Tags und vor allem eine einrückungsbasierte Syntax, die den Großteil des Interpunktionslärms entfernt.

Diese Lesbarkeit ist der Grund, warum YAML die Konfiguration dominiert. Kubernetes-Manifeste, Helm-Charts, Ansible-Playbooks, GitHub Actions, GitLab CI, Docker Compose, OpenAPI-Specs, dbt-Projekte und die meisten modernen CLIs lesen YAML. Wenn ein Mensch eine Datei in einem Editor bearbeiten und in einem Pull Request reviewen wird, gewinnt YAML.

CSV: der universelle Tabellenkalkulations-Handschlag

CSV, Comma-Separated Values, ist älter als das Web und wird locker von RFC 4180 beschrieben. Es ist denkbar einfach: Die erste Zeile ist meist eine Kopfzeile, jede folgende Zeile ist ein Datensatz, und Felder werden durch ein Trennzeichen getrennt (oft ein Komma, aber Tab, Semikolon und Pipe sind ebenfalls verbreitet). Strings, die das Trennzeichen, einen Zeilenumbruch oder ein doppeltes Anführungszeichen enthalten, werden in doppelte Anführungszeichen gesetzt, und innere Anführungszeichen werden durch Verdoppelung escaped.

CSV ist das Format, das jede Tabellenkalkulation auf der Erde, jedes BI-Tool, jeder Datenbank-Bulk-Loader und jede Analystin mit einem Python-Notebook ohne Umstände versteht. Es ist ein schreckliches Format für verschachtelte Daten und ein wundervolles Format für flache Tabellen. Wenn der Konsument ein Mensch mit geöffnetem Excel ist, ist CSV fast immer die richtige Antwort.

Dieselben Daten, drei Formate

Verankern wir die Unterschiede mit einem konkreten Beispiel. Stellen Sie sich eine Liste von drei Nutzern vor, jeder mit einer ID, einem Namen, einer E-Mail, einer Rolle und einer Liste von Tags. Hier die JSON-Version.

[
  {
    "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"]
  }
]

Dieselbe Nutzlast als YAML

Beachten Sie, wie die Interpunktion verschwindet. Die Struktur wird vollständig durch Einrückung vermittelt, und die Tag-Liste kann sowohl inline (Flow-Stil, identisch zu JSON) als auch als Block geschrieben werden. Kommentare sind erlaubt und häufig hilfreich.

# Seed users for the staging environment
- 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]   # flow style is fine for short lists
- id: 3
  name: Grace Hopper
  email: grace@example.com
  role: admin
  tags:
    - compiler
    - navy

Und als CSV

CSV kann das verschachtelte Tags-Array nicht nativ ausdrücken, also müssen wir es flachklopfen. Eine gängige Konvention ist, die Liste mit einem sekundären Trennzeichen wie Pipe oder Semikolon zu verbinden und diese Wahl irgendwo zu dokumentieren. Die Kopfzeile ersetzt die Feldnamen, und jeder Datensatz steht in seiner eigenen Zeile.

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

Drei Formate, drei Größen

Die Dateigröße zählt mehr, als die Leute zugeben. Logging-Pipelines, Browser-Bundles und Speicherrechnungen kümmern sich darum. Für das obige Beispiel sind die ungefähren Byte-Zahlen: JSON rund 410 Bytes formatiert und 290 minifiziert; YAML rund 320 Bytes; CSV rund 200 Bytes. CSV gewinnt bei flachen Daten klar, weil es die Feldnamen über alle Zeilen amortisiert, statt sie zu wiederholen.

Sobald Sie zu verschachteln beginnen, dreht sich das Bild. JSON und YAML bleiben pro Datensatz ungefähr konstant, während CSV entweder mit selbst erfundenen Konventionen flach geklopft werden muss oder in mehrere Tabellenblätter zerfällt. Für einen einzelnen tief verschachtelten Nutzer mit zwanzig Feldern werden JSON und YAML kleiner und klarer sein als jedes konstruierbare CSV.

Wo jedes Format in der Praxis gewinnt

Die Mustererkennung dessen, was reale Teams nutzen:

• JSON für HTTP-APIs, WebSocket-Payloads, Browser-localStorage, Log-Zeilen (besonders JSON Lines), Dokumentdatenbanken wie MongoDB und jeden Vertrag zwischen Diensten.
• YAML für Kubernetes, Helm, Argo, Terraform-Cloud-Workspaces, GitHub- oder GitLab-CI-Pipelines, OpenAPI- und AsyncAPI-Spezifikationen, Anwendungs-Konfiguration, die Menschen bearbeiten, und Infrastructure-as-Code, wo Lesbarkeit über Parsing-Geschwindigkeit steht.
• CSV für Analytics-Exporte, CRM-Importe, ETL-Staging-Tabellen, ML-Datensätze, Finanzberichte und alles, was für Excel oder Google Sheets bestimmt ist.
• Greifen Sie zu keinem davon, wenn Ihre Daten binär, sehr durchsatzintensiv oder über Dienste hinweg streng typisiert sind. Protobuf, Avro oder Parquet sind dort meist die richtige Antwort.

JSON-Stolperfallen, die beißen

JSONs Minimalismus ist ein Feature, schafft aber ein paar Fallen. Die Spezifikation verbietet Kommentare, sodass JSON-Konfigurationsdateien sich nicht selbst erklären können. Nachgestellte Kommas nach dem letzten Array- oder Objektelement sind unzulässig, obwohl jede moderne Sprache sie akzeptiert. Zahlen sind standardmäßig 64-Bit-Floats, sodass jede Ganzzahl größer als 2 hoch 53 still an Präzision verliert - weshalb viele APIs große IDs als Strings serialisieren.

JSON kennt zudem keinen nativen Datumstyp. ISO-8601-Strings sind die De-facto-Konvention, aber Sie und Ihr Konsument müssen sich einig sein. Doppelte Schlüssel im selben Objekt sind grammatikalisch erlaubt, erzeugen aber undefiniertes Verhalten in den Parsern, also verlassen Sie sich nicht darauf.

YAML-Stolperfallen, die härter beißen

YAMLs Flexibilität ist seine Schwäche. Einrückung ist signifikant, sodass das Mischen von Tabs und Leerzeichen oder das Verlieren von zwei Zeichen führender Leerzeichen die Bedeutung Ihrer Datei still verändert. Das berüchtigte Norway-Problem taucht in YAML-1.1-Parsern weiterhin auf: Das nicht zitierte Token NO wird als Boolean false geparst, was schon mehrfach Länderkennungslisten zerstört hat. YAML 1.2 behebt das, aber viele Tools liefern noch 1.1-Semantik aus.

Strings, die wie Zahlen, Datumsangaben oder Booleans aussehen, werden zwangsweise konvertiert, wenn Sie sie nicht zitieren. Anker und Aliasse (die &foo- und *foo-Syntax) sind mächtig, laden aber zu Billion-Laughs-artigen Denial-of-Service ein, wenn Sie nicht vertrauenswürdiges YAML akzeptieren. Parsen Sie nutzergeliefertes YAML immer mit einem sicheren Loader.

CSV-Stolperfallen, die leise beißen

CSV ist das Format, das am ehesten korrekt aussieht und doch subtil kaputt ist. Es gibt keinen Standard für das Trennzeichen; europäische Locales exportieren mit Semikolons, weil das Komma ein Dezimaltrenner ist, und Ihr Importer muss das erkennen. Zeilenumbrüche innerhalb zitierter Felder sind erlaubt, lassen aber naive Zeilensplitter stolpern. Excel formatiert Telefonnummern und lange IDs beim Öffnen einer CSV gerne als wissenschaftliche Notation neu und verstümmelt Ihre Daten, bevor ein Mensch sie sieht.

Die Kodierung ist die andere Tretmine. CSV hat keine Kodierungsdeklaration, sodass eine Datei, die unter macOS sauber öffnet, unter Windows wegen UTF-8 versus Windows-1252 Mojibake zeigen kann. Im Zweifel schreiben Sie ein UTF-8-BOM, dokumentieren das Trennzeichen und zitieren jedes Stringfeld.

Sicher zwischen ihnen konvertieren

Die meisten realen Systeme leben in mehr als einem dieser Formate. Sie nehmen ein CSV von einem Lieferanten auf, transformieren es in JSON für eine API und geben YAML aus, um den Worker zu konfigurieren, der das Ergebnis verarbeitet. Diese Konvertierungen von Hand zu machen ist die Quelle von Bugs, weshalb Multilities dedizierte Konverter ausliefert.

Wenn Sie zwischen JSON und YAML hin- und herwechseln, verarbeitet der Konverter unter /tools/yaml-json beide Richtungen und bewahrt Kommentare, wo möglich. Für tabellarische Daten verwandelt /tools/csv-json CSV-Exporte in JSON-Arrays, die Sie direkt in eine Fixture-Datei oder einen Postman-Request einfügen können, und wieder zurück, wenn Sie Finance eine Tabelle übergeben müssen. Und wenn Sie nur einen JSON-Blob wollen, der sich liest, als hätte ein Mensch ihn geschrieben, sortiert /tools/json-formatter Schlüssel, korrigiert Einrückung und validiert die Struktur in einem Durchgang.

Eine Entscheidungs-Checkliste

Wenn Sie unsicher sind, gehen Sie diese Liste von oben nach unten durch und stoppen Sie beim ersten Ja.

• Ist der Konsument eine Tabellenkalkulation oder ein SQL-Bulk-Loader und sind die Daten flach? Nutzen Sie CSV.
• Wird ein Mensch diese Datei in einem Code-Editor bearbeiten und in einem Pull Request reviewen? Nutzen Sie YAML.
• Ist der Konsument ein Programm, besonders über das Netzwerk hinweg, und Sie wollen minimale Zeremonie und maximales Tooling? Nutzen Sie JSON.
• Serialisieren Sie Millionen Datensätze mit hohem Durchsatz und festem Schema? Lassen Sie alle drei aus und greifen Sie zu Protobuf, Avro oder Parquet.

Zum Abschluss

Die drei Formate sind weniger Konkurrenten als Spezialisten. JSON ist das universelle Austauschformat, YAML die menschenfreundliche Konfigurationssprache und CSV der Tabellenkalkulations-Handschlag, der nicht sterben will, weil nichts anderes von Nicht-Entwicklern so universell verstanden wird. Zu wissen, für welche Aufgabe jedes entworfen wurde, und die Stolperfallen zu kennen, ist das, was Teams, die saubere Datenpipelines ausliefern, von Teams unterscheidet, die jeden Freitagnachmittag Escaping-Bugs bekämpfen.

Behalten Sie die Konverter-Tools als Lesezeichen, notieren Sie das Trennzeichen und die Kodierung Ihrer CSVs, zitieren Sie YAML-Strings im Zweifel, und vertrauen Sie nie darauf, dass eine vorzeichenlose 64-Bit-ID einen Roundtrip durch JavaScript überlebt. Tun Sie das, und das gewählte Format verschwindet meist im Hintergrund - genau das, was ein gutes Datenformat tun soll.