JSON und CSV beschreiben tabellarische Daten unterschiedlich. JSON unterscheidet Zeichenketten, Wahrheitswerte, Zahlen, null, fehlende Eigenschaften, Arrays und verschachtelte Objekte. CSV besteht aus Datensätzen und Feldern; ein einheitliches Typsystem oder native Verschachtelung gibt es nicht. Vor einer sinnvollen Konvertierung muss deshalb klar sein, was eine Spalte wird, was serialisiert wird und welche Unterschiede verloren gehen.
Diese Anleitung exportiert synthetische Kundendaten mit dem JSON-zu-CSV-Werkzeug. Das Beispiel enthält Kennungen mit führenden Nullen, eine fehlende Eigenschaft, null, verschachtelte Werte und Texte, die ein Tabellenprogramm als Formel lesen könnte.
Die Tabelle vor dem Download festlegen
Die Eingabe muss ein JSON-Array aus Objekten sein. Das Werkzeug bildet eine stabile Vereinigung aller Eigenschaftsnamen. Spalten erscheinen in der Reihenfolge ihres ersten Auftretens beim Durchlaufen sämtlicher Datensätze. Eine Eigenschaft, die im ersten Objekt fehlt, kann daher später eine Spalte erzeugen. Ein einzelner Datensatz reicht nicht, um die Kopfzeile vorherzusagen.
CSV bewahrt nicht jede JSON-Unterscheidung. Eine fehlende Eigenschaft und ausdrücklich gesetztes null ergeben beide ein leeres Feld. Verschachtelte Objekte und Arrays werden als JSON-Text in einer Zelle gespeichert, statt mehrdeutige Pfade wie address.city zu bilden. Tabellenprogramme behandeln diesen Inhalt als Text. Diese Umformungen sind bewusst und dokumentiert; sie machen die Formate nicht gleichwertig.
Ein festes Beispiel mit schwierigen Werten
Verwende unverändert diese Eingabe:
[
{
"id": "0012",
"name": "Ana",
"note": "=SUM(A1:A2)",
"profile": { "tier": "pro" },
"tags": ["docs", "qa"],
"active": true,
"score": null
},
{
"id": "0013",
"name": "Bela",
"note": "+441234",
"tags": [],
"active": false
}
]
Mit Komma, ohne BOM und mit Formelschutz lautet die Kopfzeile id,name,note,profile,tags,active,score. Kennungen bleiben Text. profile und tags werden als JSON serialisiert. In Zeile zwei bleibt profile wegen der fehlenden Eigenschaft leer. Beide score-Zellen sind leer, einmal wegen null, einmal wegen Abwesenheit. Formelähnliche Notizen erhalten ein vorangestelltes Apostroph; eine Warnung erklärt die Änderung.
Konvertieren, prüfen und wieder importieren
Füge das Beispiel ein und lasse den Formelschutz aktiv. Wähle Komma, wenn der Empfänger kommagetrennte Daten verlangt, Semikolon bei entsprechender regionaler Importkonfiguration oder Tabulator nur für TSV-Unterstützung. Das Trennzeichen ist Bestandteil der Schnittstelle, keine Darstellungsoption.
Konvertiere und prüfe die Vorschau. Sie zeigt höchstens 100 Datensätze, der Download enthält jedoch alle gültigen Zeilen bis 10.000. Öffne die Datei zuerst in einem Texteditor. Prüfe Spaltenreihenfolge, verdoppelte Anführungszeichen der verschachtelten JSON-Texte und Apostrophe vor beiden Notizen. Importiere anschließend ausdrücklich als UTF-8 mit demselben Trennzeichen.
Aktiviere ein UTF-8-BOM nur, wenn die Zielanwendung es zur Erkennung von Akzenten benötigt. Es ist Metadatum am Dateianfang und keine Spalte. Importiere die Datei danach gemäß der CSV-zu-JSON-Anleitung zurück. Vergleiche Kennungen, Wahrheitswerte, serialisierte Zellen und Leerfelder mit der beschriebenen Regel, nicht mit der ursprünglichen JSON-Struktur.
Warum die Ausgabe so aussieht
RFC 8259 definiert JSON-Werte, RFC 4180 beschreibt die verbreitete CSV-Konvention mit Datensätzen, Feldern, CRLF-Zeilenenden und verdoppelten Anführungszeichen. Keine Spezifikation legt eine allgemeine Abbildung fest. Der Konverter macht seine Entscheidungen sichtbar: stabile Spaltenvereinigung, JSON-Serialisierung verschachtelter Werte und leere Zellen für fehlend sowie null.
Formelschutz betrifft eine weitere Ebene. Tabellenprogramme können Zellen, die mit =, +, - oder @ beginnen, als Ausdruck behandeln. Bei aktivem Schutz setzt der Export ein Apostroph davor und meldet die Änderung. Das löst nicht jedes Sicherheitsproblem, verhindert aber, dass formelähnlicher Benutzereingabetext unbemerkt unverändert übergeben wird. Deaktiviere die Option nur bei ausdrücklich geforderter Zeichengenauigkeit und separat kontrollierten Daten.
CSV-Anführungszeichen sind Struktur. Felder mit Trennzeichen, Anführungszeichen oder Zeilenumbruch müssen zitiert werden; ein inneres Anführungszeichen wird verdoppelt. Entferne diese Zeichen nicht, auch wenn um {"tier":"pro"} viele sichtbar sind. Nur so erhält ein Parser die vollständige Zelle.
Fehler nachvollziehbar beheben
„Array aus Objekten“ bedeutet, dass die Wurzel kein Array ist oder ein Element primitiv, null oder selbst ein Array ist. Verpacke ein Einzelobjekt nur dann, wenn es wirklich eine Tabellenzeile darstellt. Gemischte Eingaben sollten vor dem Export normalisiert werden.
Mehr als 2 MiB UTF-8, 10.000 Datensätze oder eine Matrix über einer Million Zellen werden abgewiesen statt abgeschnitten. Teile an einer fachlichen Grenze und bewahre eine Batch-Kennung auf. Die 100-Zeilen-Vorschau ist keine unvollständige Ausgabedatei.
Wirkt eine verschachtelte Zelle beschädigt, prüfe zunächst rohes CSV und analysiere danach ihren Text als JSON. Ein Tabellenprogramm kann führende Nullen aufgrund eigener Typableitung entfernen; importiere solche Spalten als Text. Bei sichtbaren Formeln prüfe Formelschutz und Apostroph. Unsichere Ganzzahlen können bereits beim JSON-Parsen Präzision verlieren; die Warnung macht das sichtbar, doch große Kennungen sollten vom Ursprung als Zeichenkette geliefert werden.
Die Übergabe reproduzierbar machen
Dokumentiere Trennzeichen, BOM, Formelschutz, Kopfzeilen, Datensatzanzahl und Bedeutung leerer Felder. Empfänger können nicht erkennen, ob leer ursprünglich null, fehlend oder eine leere Zeichenkette war. Wenn das wichtig ist, füge vorher eine Statusspalte hinzu oder nutze ein Format, das die Unterscheidung trägt.
Verschachtelte JSON-Zellen sind ein dokumentierter Ausweg, kein bequemes manuelles Schema. Sie eignen sich, wenn ein Folgeprogramm sie erneut parst. Für Menschen sind getrennte Spalten oder relationale Tabellen oft verständlicher. Automatisches Abflachen braucht vereinbarte Namen und Kollisionsregeln.
Die Verarbeitung läuft im Browser und muss die Eingabe nicht zum Anwendungsserver hochladen. Der Download ist trotzdem eine neue Datei im normalen Browser- und Betriebssystemspeicher. Nutze synthetische Testdaten und beachte Zugriff sowie Aufbewahrung. Die Anleitung zu privaten Entwicklerwerkzeugen ergänzt diese Prüfung.
Grenzen der Konvertierung
CSV besitzt kein universelles Schema, Typsystem, Nullkennzeichen, Verschachtelungsformat oder einheitlichen Formelschutz. Ein erfolgreicher Download beweist nicht, dass Excel, LibreOffice, Datenbank-Loader und eigener Parser alle Felder gleich lesen. Das Werkzeug wertet keine Formeln aus, leitet keine regionalen Zahlen ab, flacht nichts ab und bewahrt den Unterschied zwischen fehlend und null nicht.
Formelschutz verändert Text absichtlich. Verschachtelte Werte benötigen einen zweiten Parse-Schritt. Die Vorschau endet bei 100 Zeilen, der Export nicht. Grenzen sind 2 MiB, 10.000 Datensätze und eine Million Zellen; zusätzlich schützt eine geschätzte 16-MiB-Grenze bei CSV-zu-JSON vor riesiger Ausgabe. Für geregelte Prozesse sind Schema, Audit und Zieltests erforderlich.
Abschließende Exportprüfung
Bestätige ein Array aus Objekten sowie Größen-, Zeilen- und Zellgrenzen. Prüfe die vereinigte Kopfzeile, besonders spät auftretende Eigenschaften. Wähle das Trennzeichen des Importers, BOM nur bei Bedarf und Formelschutz, solange keine begründete Ausnahme besteht.
Prüfe den Download außerhalb der Vorschau. Zähle Zeilen, kontrolliere 0012, profile, tags und die Apostrophe bei =SUM(A1:A2) sowie +441234. Dokumentiere den Verlust der Unterscheidung von fehlend und null. Importiere mit UTF-8 und gleichem Trennzeichen zurück und vergleiche das Ergebnis vor der Weitergabe.
Führe zusätzlich zwei Negativtests durch. Erweitere die Eingabe kurzzeitig auf mehr als 10.000 Objekte und bestätige, dass kein Teil-Download entsteht. Erzeuge dann viele Spalten, bis die Million-Zellen-Grenze greift. Stelle anschließend das feste Beispiel wieder her. Diese Tests belegen, dass ein Größenfehler sichtbar stoppt und nicht als vollständige Datei weitergereicht wird.
Prüfe Akzente und tatsächliche Zeilenenden in der heruntergeladenen Datei. Ein Texteditor zeigt, ob CRLF verwendet und das optionale BOM vorhanden ist; ein Tabellenimport zeigt, ob seine eigene Zeichenerkennung korrekt konfiguriert ist. Halte beide Beobachtungen auseinander. Wenn ein Zielprogramm Zeichen verändert, ist das nicht automatisch ein Fehler der JSON-Konvertierung.
Vereinbare vor der Übergabe auch, ob serialisierte Objekte unverändert bleiben oder vom Empfänger erneut geparst werden. Für den zweiten Fall braucht jede betroffene Spalte eine erwartete JSON-Form und eine verständliche Fehlermeldung. Für manuelle Empfänger ist eine getrennte Datei mit Schema und Feldbeschreibung hilfreicher als eine immer breitere Tabelle. Bewahre Eingabe, Optionen, Download und Prüfergebnis als reproduzierbares Paket auf.
Notiere die Werkzeugversion.
Quellen: RFC 8259: JSON, RFC 4180: CSV und OWASP CSV Injection.