TOON vs JSON vs CSV — Choosing the Right Format

Tre formater går ind til et planlægningsmøde. JSON siger, at det kan håndtere alt. CSV siger, at det er hurtigt og magert. TOON siger, at det er her for at tale med AI'en. De har alle ret — til forskellige opgaver. Den frustrerende del er ikke, at disse formater eksisterer, det er at vælge den forkerte til dit anvendelsestilfælde koster dig på rigtige, konkrete måder: omfangsrige payloads, ødelagte imports, dyre LLM-regninger, eller parsing-hovedpine. Denne guide giver dig et klart rammeværk til at vælge.

Et hurtigt portræt af hvert format

JSON (JavaScript Object Notation) opstod fra JavaScript i begyndelsen af 2000'erne og blev det dominerende format for web-API'er takket være sin enkelhed og udtryksevne. Det håndterer indlejrede strukturer naturligt, skelner mellem strenge, tal, booleaner og nuller uden ekstra ceremoniel og er specificeret af RFC 8259. Alle moderne sprog har et førsteklasses JSON-bibliotek.

CSV (Comma-Separated Values) er ældre end nettet. Det er defineret af RFC 4180 og er i det væsentlige lingua franca for flade tabeldata. Åbn en CSV-fil i Excel, Google Sheets, eller Numbers, og den virker bare. For rene flade tabeller er det det mest kompakte og universelt importerbare format, der findes.

TOON er et nyere format bygget specielt til LLM-workflows. Det henter inspiration fra begge — som CSV bruger det en header-én-gang-derefter-rækker-struktur til tabeldata, men som JSON kan det også kode indlejrede objekter og arrays. Hele dets design er orienteret mod at minimere tokenantal, når data sendes til og fra store sprogmodeller.

De samme data i alle tre formater

For at gøre dette konkret, lad os bruge et produktkatalog, der indeholder et indlejret specs-objekt — en virkelighedsnær form, der meningsfuldt tester alle tre formater. Her er fire produkter fra en elektronikbutik:

JSON — udtryksfuldt, håndterer indlejring naturligt, men omfangsrigt for gentagne rækkedata:

[
  {
    "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-venlig, men det indlejrede specs-objekt skal flades ud. Der er ingen standard måde at repræsentere det på, så vi enten mister indlejringen eller mangler den til en streng:

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 erklæret én gang, rækker er kompakte, indlejrede objekter kodet inline:

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}

Hvor hvert format fejler

At forstå fejltilstande er lige så vigtigt som at kende styrkerne.

• JSON fejler for tabeller. At gentage hvert nøglenavn på hver række er genuint spildsomt. Et 1000-rækkers datasæt, hvor hver række har 8 nøgler, betyder, at "id", "name", "price" og så videre skrives 1000 gange hver. For LLM-input oversættes dette direkte til tokenomkostninger; for menneskelig inspektion er det bare støj.
• CSV fejler for indlejrede data. Formatet har inget koncept om indlejring. Du kan stringify et indlejret objekt til en celle, men derefter skal forbrugeren vide, at den celle skal parses — du har bare flyttet problemet. CSV har heller ikke et native type-system: true er en streng, 42 er en streng, null er tvetydigt. Værktøjer håndterer dette inkonsekvent.
• TOON fejler uden for LLM-kontekster. Det er et niche-format med et snævrere økosystem. Du finder ikke native TOON-understøttelse i PostgreSQL, i dit REST-framework eller i Excel. npm-pakken dækker JavaScript/TypeScript-workflows godt, men hvis du rækker efter TOON i en kontekst, der intet har med AI at gøre, over-ingenierer du sandsynligvis.
• CSV fejler for værdier indeholdende kommaer eller linjeskift. RFC 4180's citatregler håndterer det, men mange CSV-producenter og -forbrugere implementerer dem inkonsekvent. Et produktnavn som 27" IPS Monitor, Black eller en beskrivelse med linjeskift bliver et pålideligheds-problem.

Beslutningsmatrix

Her er en praktisk guide. Match din situation til det passende format:

• Dine data går ind i en LLM-prompt → TOON. Især hvis de er tabelformat. Brug JSON til TOON til at konvertere før API-kaldet.
• Dine data kommer tilbage fra et LLM og skal behandles → TOON (til output), derefter afkode til JSON eller et native objekt til downstream-brug med TOON til JSON.
• Dine data er rent fladt tabelformat (samme nøgler på alle rækker) og går til/fra regneark → CSV. Det er den mindste repræsentation og universelt importerbar.
• Dine data er fladt tabelformat, men vil blive transformeret af kode (ikke regneark) → Enten CSV eller JSON. JSON er sikrere, hvis typer har betydning (du vil ikke have "true" i stedet for true).
• Dine data har indlejrede objekter eller arrays → JSON. Kæmp ikke mod CSVs flade begrænsning. Hvis indlejring går til et LLM, kode til TOON efter at have bygget strukturen.
• Dine data går til et REST API eller gemmes i en database → JSON. Altid.
• Dine data er en konfigurationsfil → JSON eller YAML. Hverken CSV eller TOON hører hjemme her.
• Du har brug for maksimal portabilitet og en nul-afhængigheds-parser → JSON eller CSV. Begge har native eller næsten-native understøttelse overalt.

Brug af alle tre i én pipeline

En realistisk pipeline kan bruge alle tre. Forestil dig et e-handels-workflow, der beriger produktdata med AI-genererede beskrivelser:

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 til API-laget, TOON gennem LLM-laget, CSV til det menneskelig-forbrugelige output. Hvert format gør præcis det job, det blev designet til.

Hurtig værktøjsreference

Hvis du bevæger dig mellem disse formater, vil disse værktøjer dække de almindelige konverteringer. TOON Formatter er den hurtigste måde at validere og rydde op i TOON-strenge. JSON til TOON-konverteren håndterer LLM-forberedelsestrinnet. Går den anden vej efter at et LLM returnerer TOON, kan TOON til CSV producere et regneark-klar eksport direkte, og CSV til JSON er go-to til at normalisere importer fra Excel eller tredjeparts-dataleverandører. For TOON-specifikke detaljer lever den officielle pakke på npm.

Opsummering

JSON, CSV og TOON har hvert sit klare domæne. JSON er det universelle format til struktureret dataudveksling — indlejret eller fladt, API'er, konfiguration, lagring. CSV er det universelle format for flade tabeldata, der skal rejse mellem systemer og mennesker — regneark, importer, eksporter. TOON er formatet til effektivt at sende strukturerede data gennem AI-systemer, hvor hvert token tæller. Fejlen de fleste udviklere begår er at standardisere på JSON til alt inklusive LLM-prompts, eller at standardisere på CSV og derefter opdage indlejringskrav midt i et projekt. Kend formen på dine data, vid, hvor de er på vej hen, og det rigtige format vælger sig selv som regel.

For en dybere gennemgang af JSON vs. TOON-afvejningen specifikt, tjek TOON vs. JSON-sammenligning. For baggrund om CSV-specifikationen og dens særheder dækker Wikipedia-artiklen om CSV historien og formatvarianterne godt.