TOON vs JSON vs CSV — Choosing the Right Format

Tre formater går inn til et planleggingsmøte. JSON sier at det kan håndtere alt. CSV sier at det er raskt og magert. TOON sier at det er der for å snakke med AI-en. De har alle rett — til forskjellige oppgaver. Den frustrerende delen er ikke at disse formatene eksisterer, det er å velge feil for ditt brukstilfelle koster deg på virkelige, konkrete måter: omfangsrike payloads, ødelagte importer, dyre LLM-regninger, eller parsing-hodepine. Denne veiledningen gir deg et klart rammeverk for å velge.

Et raskt portrett av hvert format

JSON (JavaScript Object Notation) oppstod fra JavaScript i begynnelsen av 2000-tallet og ble det dominerende formatet for web-API-er takket være sin enkelhet og uttryksevne. Det håndterer nestede strukturer naturlig, skiller mellom strenger, tall, boolske verdier og nuller uten ekstra seremoni og er spesifisert av RFC 8259. Alle moderne språk har et førsteklasses JSON-bibliotek.

CSV (Comma-Separated Values) er eldre enn nettet. Det er definert av RFC 4180 og er i det vesentlige lingua franca for flate tabelldata. Åpne en CSV-fil i Excel, Google Sheets, eller Numbers, og den virker bare. For rene flate tabeller er det det mest kompakte og universelt importerbare formatet som finnes.

TOON er et nyere format bygget spesielt til LLM-arbeidsflyter. Det henter inspirasjon fra begge — som CSV bruker det en overskrift-én-gang-deretter-rader-struktur for tabelldata, men som JSON kan det også kode nestede objekter og arrays. Hele designet er orientert mot å minimere tokenantall når data sendes til og fra store språkmodeller.

De samme dataene i alle tre formater

For å gjøre dette konkret, la oss bruke et produktkatalog som inneholder et nestet specs-objekt — en virkelighetsnær form som meningsfullt tester alle tre formater. Her er fire produkter fra en elektronikkbutikk:

JSON — uttryksfullt, håndterer nesting naturlig, men omfangsrikt for gjentatte raddata:

[
  {
    "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-vennlig, men det nestede specs-objektet må flates ut. Det finnes ingen standardmåte å representere det på, så vi enten mister nestingen 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 — overskrift erklært én gang, rader er kompakte, nestede 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 svikter

Å forstå feilmoduser er like viktig som å kjenne styrkene.

• JSON svikter for tabeller. Å gjenta hvert nøkkelnavn på hver rad er genuint sløsende. Et 1000-raders datasett der hver rad har 8 nøkler, betyr at "id", "name", "price" og så videre skrives 1000 ganger hver. For LLM-inndata oversettes dette direkte til tokenkostnader; for menneskelig inspeksjon er det bare støy.
• CSV svikter for nestede data. Formatet har inget konsept om nesting. Du kan stringify et nestet objekt til en celle, men da må forbrukeren vite at den cellen skal parses — du har bare flyttet problemet. CSV har heller ikke et nativt typesystem: true er en streng, 42 er en streng, null er tvetydig. Verktøy håndterer dette inkonsekvent.
• TOON svikter utenfor LLM-kontekster. Det er et nisjeformat med et snevrere økosystem. Du finner ikke nativ TOON-støtte i PostgreSQL, i REST-rammeverket ditt eller i Excel. npm-pakken dekker JavaScript/TypeScript-arbeidsflyter godt, men hvis du griper etter TOON i en kontekst som ikke har noe med AI å gjøre, over-ingenierer du sannsynligvis.
• CSV svikter for verdier som inneholder kommaer eller linjeskift. RFC 4180s sitatregler håndterer det, men mange CSV-produsenter og -forbrukere implementerer dem inkonsekvent. Et produktnavn som 27" IPS Monitor, Black eller en beskrivelse med linjeskift blir et pålitelighets-problem.

Beslutningsmatrise

Her er en praktisk veiledning. Match situasjonen din til det passende formatet:

• Dataene dine går inn i en LLM-prompt → TOON. Spesielt hvis de er tabellformat. Bruk JSON til TOON til å konvertere før API-kallet.
• Dataene dine kommer tilbake fra en LLM og skal behandles → TOON (til utdata), deretter dekode til JSON eller et nativt objekt til nedstrømsbruk med TOON til JSON.
• Dataene dine er rent flatt tabellformat (samme nøkler på alle rader) og går til/fra regneark → CSV. Det er den minste representasjonen og universelt importerbar.
• Dataene dine er flatt tabellformat, men vil bli transformert av kode (ikke regneark) → Enten CSV eller JSON. JSON er sikrere hvis typer har betydning (du vil ikke ha "true" i stedet for true).
• Dataene dine har nestede objekter eller arrays → JSON. Ikke kjemp mot CSVs flate begrensning. Hvis nesting går til en LLM, kode til TOON etter å ha bygget strukturen.
• Dataene dine går til et REST API eller lagres i en database → JSON. Alltid.
• Dataene dine er en konfigurasjonsfil → JSON eller YAML. Verken CSV eller TOON hører hjemme her.
• Du trenger maksimal portabilitet og en null-avhengighets-parser → JSON eller CSV. Begge har native eller nesten-native støtte overalt.

Bruk av alle tre i én pipeline

En realistisk pipeline kan bruke alle tre. Forestill deg en e-handels-arbeidsflyt som beriker produktdata med AI-genererte 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 gjennom LLM-laget, CSV til det menneskelig-forbrukelige utdata. Hvert format gjør nøyaktig den jobben det ble designet for.

Rask verktøyreferanse

Hvis du beveger deg mellom disse formatene, vil disse verktøyene dekke de vanlige konverteringene. TOON Formatter er den raskeste måten å validere og rydde opp i TOON-strenger. JSON til TOON-konvertereren håndterer LLM-forberedelsestrinnet. Går den andre veien etter at en LLM returnerer TOON, kan TOON til CSV produsere et regneark-klar eksport direkte, og CSV til JSON er go-to til å normalisere importer fra Excel eller tredjeparts-dataleverandører. For TOON-spesifikke detaljer lever den offisielle pakken på npm.

Oppsummering

JSON, CSV og TOON har hvert sitt klare domene. JSON er det universelle formatet for strukturert datautveksling — nestet eller flatt, API-er, konfigurasjon, lagring. CSV er det universelle formatet for flate tabelldata som skal reise mellom systemer og mennesker — regneark, importer, eksporter. TOON er formatet for effektivt å sende strukturerte data gjennom AI-systemer, der hvert token teller. Feilen de fleste utviklere gjør er å standardisere på JSON for alt inkludert LLM-prompter, eller å standardisere på CSV og deretter oppdage nestingskrav midt i et prosjekt. Kjenn formen på dataene dine, vit hvor de er på vei, og det riktige formatet velger seg selv som regel.

For en dypere gjennomgang av JSON vs. TOON-avveiningen spesifikt, sjekk TOON vs. JSON-sammenligning. For bakgrunn om CSV-spesifikasjonen og dens særheter dekker Wikipedia-artikkelen om CSV historien og formatvariantene godt.