TOON vs JSON vs CSV — Das richtige Format wählen

Drei Formate betreten ein Planungsmeeting. JSON sagt, es kann alles verarbeiten. CSV sagt, es ist schnell und schlank. TOON sagt, es ist hier, um mit der KI zu sprechen. Sie alle haben recht — für unterschiedliche Aufgaben. Das Frustrierende ist nicht, dass diese Formate existieren, sondern dass die Wahl des falschen für deinen Anwendungsfall auf konkrete Weise kostet: ausführliche Payloads, kaputte Importe, teure LLM-Rechnungen oder Parsing-Kopfschmerzen. Dieser Leitfaden gibt dir ein klares Framework für die Entscheidung.

Ein kurzes Porträt jedes Formats

JSON (JavaScript Object Notation) entstand Anfang der 2000er aus JavaScript und wurde dank seiner Einfachheit und Ausdrucksstärke zum dominanten Format für Web-APIs. Es verarbeitet verschachtelte Strukturen nativ, unterscheidet ohne Umständlichkeit zwischen Strings, Zahlen, Booleans und Nullwerten und ist durch RFC 8259 spezifiziert. Jede moderne Sprache hat eine erstklassige JSON-Bibliothek.

CSV (Comma-Separated Values) ist älter als das Web. Es ist durch RFC 4180 definiert und ist im Wesentlichen die Lingua franca flacher tabellarischer Daten. Öffne eine CSV in Excel, Google Sheets oder Numbers und sie funktioniert einfach. Für reine flache Tabellen ist es das kompakteste und universell importierbare Format, das es gibt.

TOON ist ein neueres Format, das speziell für LLM-Workflows entwickelt wurde. Es lässt sich von beiden inspirieren — wie CSV verwendet es eine Header-einmal-dann-Zeilen-Struktur für tabellarische Daten, aber wie JSON kann es auch verschachtelte Objekte und Arrays kodieren. Sein gesamtes Design ist auf die Minimierung der Token-Anzahl ausgerichtet, wenn Daten an und von großen Sprachmodellen übergeben werden.

Dieselben Daten in allen drei Formaten

Um dies konkret zu machen, verwenden wir einen Produktkatalog, der ein verschachteltes specs-Objekt enthält — eine reale Form, die alle drei Formate sinnvoll herausfordert. Hier sind vier Produkte aus einem Elektronikhändler:

JSON — ausdrucksstark, verarbeitet Verschachtelung natürlich, aber ausführlich für repetitive Zeilendaten:

[
  {
    "id": "P001",
    "name": "Wireless Headphones",
    "category": "Audio",
    "price": 79.99,
    "inStock": true,
    "specs": { "weight": "250g", "connectivity": "Bluetooth 5.2", "battery": "30h" }
  },
  {
    "id": "P002",
    "name": "USB-C Docking Station",
    "category": "Peripherals",
    "price": 129.99,
    "inStock": true,
    "specs": { "ports": 11, "maxPower": "100W", "display": "4K@60Hz" }
  },
  {
    "id": "P003",
    "name": "Mechanical Keyboard",
    "category": "Input",
    "price": 94.99,
    "inStock": false,
    "specs": { "layout": "TKL", "switches": "Cherry MX Red", "backlight": "RGB" }
  },
  {
    "id": "P004",
    "name": "27" IPS Monitor",
    "category": "Display",
    "price": 299.99,
    "inStock": true,
    "specs": { "resolution": "2560x1440", "refreshRate": "165Hz", "panel": "IPS" }
  }
]

CSV — kompakt, Excel-freundlich, aber das verschachtelte specs-Objekt muss abgeflacht werden. Es gibt keinen Standard-Weg, es darzustellen, also verliert man entweder die Verschachtelung oder quetscht sie in einen String:

id,name,category,price,inStock,specs_weight,specs_ports,specs_layout,specs_resolution
P001,Wireless Headphones,Audio,79.99,true,250g,,,
P002,USB-C Docking Station,Peripherals,129.99,true,,11,,
P003,Mechanical Keyboard,Input,94.99,false,,,TKL,
P004,27" IPS Monitor,Display,299.99,true,,,,2560x1440

TOON — Header einmal deklariert, Zeilen kompakt, verschachtelte Objekte inline kodiert:

products[4]{id,name,category,price,inStock,specs}:
  P001,Wireless Headphones,Audio,79.99,true,{weight:250g,connectivity:Bluetooth 5.2,battery:30h}
  P002,USB-C Docking Station,Peripherals,129.99,true,{ports:11,maxPower:100W,display:4K@60Hz}
  P003,Mechanical Keyboard,Input,94.99,false,{layout:TKL,switches:Cherry MX Red,backlight:RGB}
  P004,27" IPS Monitor,Display,299.99,true,{resolution:2560x1440,refreshRate:165Hz,panel:IPS}

Wo jedes Format versagt

Die Fehlermodi zu verstehen ist genauso wichtig wie die Stärken zu kennen.

• JSON versagt bei Tabellen. Jeden Schlüsselnamen in jeder Zeile zu wiederholen ist wirklich verschwenderisch. Ein 1000-Zeilen-Datensatz, bei dem jede Zeile 8 Schlüssel hat, bedeutet "id", "name", "price" und so weiter jeweils 1000 Mal geschrieben. Bei LLM-Eingaben schlägt sich das direkt in Token-Kosten nieder; für menschliche Inspektion ist es einfach Rauschen.
• CSV versagt bei verschachtelten Daten. Das Format hat kein Konzept für Verschachtelung. Man kann ein verschachteltes Objekt in eine Zelle umwandeln, aber dann muss der Verbraucher wissen, diese Zelle zu parsen — man hat das Problem nur verlagert. CSV hat auch kein natives Typensystem: true ist ein String, 42 ist ein String, null ist mehrdeutig. Tools verarbeiten dies inkonsistent.
• TOON versagt außerhalb von LLM-Kontexten. Es ist ein Nischen-Format mit einem schmaleren Ökosystem. In PostgreSQL, im REST-Framework oder in Excel findet man keine native TOON-Unterstützung. Das npm-Paket deckt JavaScript/TypeScript-Workflows gut ab, aber wenn man TOON in einem Kontext verwendet, der nichts mit KI zu tun hat, entwickelt man wahrscheinlich zu komplex.
• CSV versagt bei Werten, die Kommas oder Zeilenumbrüche enthalten. Die RFC 4180 Quotierungsregeln behandeln dies, aber viele CSV-Produzenten und -Konsumenten implementieren sie inkonsistent. Ein Produktname wie 27" IPS Monitor, Black oder eine Beschreibung mit Zeilenumbrüchen wird zu einem Zuverlässigkeitsrisiko.

Entscheidungsmatrix

Hier ist ein praktischer Leitfaden. Passe deine Situation dem geeigneten Format an:

• Deine Daten gehen in einen LLM-Prompt → TOON. Besonders wenn sie tabellarisch sind. Verwende JSON zu TOON, um vor dem API-Aufruf zu konvertieren.
• Deine Daten kommen von einem LLM zurück und müssen verarbeitet werden → TOON (für Ausgabe), dann zu JSON oder einem nativen Objekt für die nachgelagerte Verwendung dekodieren mit TOON zu JSON.
• Deine Daten sind rein flach tabellarisch (gleiche Schlüssel in jeder Zeile) und gehen zu/von Tabellenkalkulation → CSV. Es ist die kleinste Darstellung und universell importierbar.
• Deine Daten sind flach tabellarisch, werden aber durch Code transformiert (nicht Tabellenkalkulation) → Entweder CSV oder JSON. JSON ist sicherer, wenn Typen wichtig sind (man will nicht "true" statt true).
• Deine Daten haben verschachtelte Objekte oder Arrays → JSON. Kämpfe nicht gegen CSVs Nur-flach-Beschränkung. Wenn die Verschachtelung zu einem LLM geht, nach dem Aufbau der Struktur zu TOON kodieren.
• Deine Daten gehen an eine REST-API oder werden in einer Datenbank gespeichert → JSON. Immer.
• Deine Daten sind eine Konfigurationsdatei → JSON oder YAML. Weder CSV noch TOON gehören hier hin.
• Du brauchst maximale Portabilität und einen Zero-Dependency-Parser → JSON oder CSV. Beide haben native oder nahezu native Unterstützung überall.

Alle drei in einer Pipeline verwenden

Eine realistische Pipeline könnte alle drei verwenden. Stell dir einen E-Commerce-Workflow vor, der Produktdaten mit KI-generierten Beschreibungen anreichert:

import { encode, decode } from '@toon-format/toon';

// Step 1: Products arrive as JSON from your REST API
const products = await fetch('/api/products').then(r => r.json());

// Step 2: Encode to TOON to minimise tokens before the LLM call
const toonInput = encode(products);

const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [
    {
      role: 'user',
      content: `Here is our product catalogue in TOON format:\n\n${toonInput}\n\n
                For each product, write a one-sentence marketing description.
                Return results as TOON with fields: id, description`
    }
  ]
});

// Step 3: Decode the LLM's TOON response back to objects
const enriched = decode(response.choices[0].message.content);

// Step 4: Export to CSV for the marketing team's spreadsheet
const csvRows = enriched.map(row => `${row.id},"${row.description}"`);
const csv = ['id,description', ...csvRows].join('\n');

JSON für die API-Schicht, TOON durch die LLM-Schicht, CSV für die menschlich konsumierbare Ausgabe. Jedes Format erledigt genau den Job, für den es konzipiert wurde.

Schnelle Tool-Referenz

Wenn du zwischen diesen Formaten wechselst, decken diese Tools die gängigen Konvertierungen ab. Der TOON Formatter ist der schnellste Weg, TOON-Strings zu validieren und zu bereinigen. Der JSON-zu-TOON-Konverter erledigt den LLM-Vorbereitungsschritt. In die andere Richtung nach einem LLM-TOON-Return kann TOON zu CSV direkt einen tabellenkalkulationsfreundlichen Export erzeugen, und CSV zu JSON ist die erste Wahl zur Normalisierung von Importen aus Excel oder Drittanbieter-Datenanbietern. Für TOON-spezifische Details lebt das offizielle Paket auf npm.

Zusammenfassung

JSON, CSV und TOON haben jeweils eine klare Domäne. JSON ist das universelle Format für strukturierten Datenaustausch — verschachtelt oder flach, APIs, Config, Speicherung. CSV ist das universelle Format für flache tabellarische Daten, die zwischen Systemen und Menschen reisen müssen — Tabellenkalkulation, Importe, Exporte. TOON ist das Format für die effiziente Übergabe strukturierter Daten durch KI-Systeme, wo jeder Token zählt. Der Fehler, den die meisten Entwickler machen, ist, JSON für alles einschließlich LLM-Prompts zu verwenden, oder CSV und dann in der Mitte des Projekts Verschachtelungsanforderungen zu entdecken. Kenne die Form deiner Daten, kenne ihr Ziel, und das richtige Format wählt sich meist von selbst.

Für einen tieferen Einblick in den JSON-vs-TOON-Kompromiss speziell, schau dir den TOON vs JSON Vergleich an. Für Hintergrund zur CSV-Spezifikation und ihren Eigenheiten deckt der Wikipedia-Artikel über CSV die Geschichte und Formatvariationen gut ab.