Methodik
Wie der JSON-zu-CSV-Converter auf json-csv.de arbeitet
Jede Konvertierung auf json-csv.de läuft in vier Schritten: JSON parsen, Spalten ableiten, Verschachtelung flachklopfen und CSV nach RFC 4180 serialisieren. Die gesamte Verarbeitung passiert im Browser. Diese Seite dokumentiert die Regeln dahinter und die Standards, auf die sie sich stützt.
Wichtiger Hinweis
json-csv.de ist ein technisches Werkzeug zur Format-Umwandlung. Bei sehr großen oder tief verschachtelten Strukturen kann die flache CSV-Form Informationen zusammenfassen oder über mehrere Spalten verteilen. Prüfe die Ausgabe vor dem Import in nachgelagerte Systeme, insbesondere bei heterogenen Objekten mit unterschiedlichen Schlüsseln und bei Werten, die selbst Trennzeichen oder Zeilenumbrüche enthalten.
Schritt 1: JSON parsen nach RFC 8259
Die Eingabe wird zunächst als JSON nach RFC 8259 geparst. JSON kennt sechs Werttypen: Objekt, Array, String, Zahl, Boolean und null. Schlägt das Parsen fehl (etwa wegen eines fehlenden Anführungszeichens, eines abschließenden Kommas oder einfacher statt doppelter Anführungszeichen), bricht die Engine mit einer konkreten Fehlermeldung samt Position ab, statt eine halbe Datei auszugeben. Akzeptiert werden ein Array von Objekten (der Normalfall, jedes Objekt wird eine Zeile) sowie ein einzelnes Objekt (wird eine Zeile mit einer Header-Zeile).
Schritt 2: Spalten aus der Schlüssel-Union ableiten
CSV ist tabellarisch und braucht eine feste Spaltenmenge. Die Engine bildet die Union aller Schlüssel über alle Objekte des Arrays, in der Reihenfolge des ersten Auftretens. Fehlt ein Schlüssel in einem Objekt, bleibt die entsprechende Zelle leer. So gehen bei heterogenen Datensätzen, in denen nicht jedes Objekt dieselben Felder hat, keine Spalten verloren.
Schritt 3: Verschachtelung flachklopfen
JSON ist beliebig tief verschachtelbar, CSV nicht. Verschachtelte Objekte werden über
Dot-Notation in Spaltenpfade übersetzt: aus {"user":{"adresse":{"stadt":"Hamburg"}}}
wird die Spalte user.adresse.stadt. Arrays werden je nach Inhalt behandelt:
Arrays primitiver Werte können als ein zusammengefasster String (Trennung per Semikolon)
oder über Index-Spalten (tags.0, tags.1) abgebildet werden.
Diese Stelle ist die wichtigste Entwurfsentscheidung jeder JSON-zu-CSV-Umwandlung, weil
sie bestimmt, wie viele Spalten entstehen.
Schritt 4: CSV serialisieren nach RFC 4180
Die Ausgabe folgt RFC 4180. Ein Feld wird in doppelte Anführungszeichen gesetzt, sobald
es das Trennzeichen, ein doppeltes Anführungszeichen oder einen Zeilenumbruch enthält.
Ein im Wert enthaltenes Anführungszeichen wird durch Verdopplung escaped
(" wird zu ""). Der Standard sieht CRLF als Zeilenende und eine
optionale Header-Zeile vor. Diese Regeln sorgen dafür, dass Werte mit Kommata,
Zitaten oder Umbrüchen beim Re-Import nicht die Spalten verschieben.
Trennzeichen und Zeichenkodierung
Standardmäßig trennt CSV mit Komma. Für das deutsche Excel-Gebietsschema, das Komma als
Dezimaltrennzeichen interpretiert, lässt sich auf Semikolon umstellen. Die Ausgabe ist
UTF-8 kodiert. Damit deutsches Excel Umlaute korrekt erkennt, kann der Datei ein
Byte-Order-Mark (BOM) vorangestellt werden. Ohne BOM zeigt Excel sonst häufig Mojibake
(etwa ä statt ä).
Clientseitige Verarbeitung
Die Konvertierung läuft vollständig im Browser über JavaScript. Es findet keine Übertragung der Eingabedaten an einen Server statt, es wird nichts gespeichert und nichts protokolliert. Wer das überprüfen will, kann das Tool im Netzwerk-Tab der Browser-Devtools beobachten oder die Seite offline (ohne Netzverbindung) nutzen.
Validierungs-Regeln
- Eingabe muss valides JSON nach RFC 8259 sein, sonst Abbruch mit Positionsangabe
- Top-Level: Array von Objekten oder einzelnes Objekt
- Spaltenmenge: Union aller Objekt-Schlüssel, Reihenfolge nach erstem Auftreten
- Felder mit Trennzeichen, Anführungszeichen oder Umbruch werden RFC-4180-konform gequotet
- Trennzeichen wählbar (Komma oder Semikolon), Encoding UTF-8 mit optionalem BOM
Quellen und Standards
- RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files
- RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
- RFC 7111: URI Fragment Identifiers for the text/csv Media Type
- Unicode Standard: UTF-8, Byte-Order-Mark und Mojibake-Ursachen
- W3C / WHATWG Encoding Standard: Verhalten von Browsern beim Lesen und Schreiben von Text
Review-Zyklus
Wir prüfen halbjährlich die folgenden Punkte:
- Korrektheit aller Code-Beispiele in den Ratgebern (Python, JavaScript, jq und weitere)
- RFC-4180-Konformität der Ausgabe, vor allem beim Quoting von Sonderfällen
- Verhalten von aktuellem Excel und Google Sheets beim Import (Trennzeichen, BOM)
- Reproduzierbarkeit der dokumentierten Konvertierungen über die Engine
Korrektur-Policy
Wir machen Fehler. Wenn dir eine fehlerhafte Konvertierung, ein nicht lauffähiges Code-Beispiel oder eine inhaltliche Unstimmigkeit auffällt, schreib an info@akara-solutions.de. Bestätigte Korrekturen dokumentieren wir öffentlich auf Korrekturen.
Was wir nicht machen
json-csv.de ist kein Datenbank-Importer und keine ETL-Pipeline. Für wiederkehrende Massen-Konvertierungen, sehr große Dateien jenseits des Arbeitsspeichers oder automatisierte Workflows sind die programmatischen Wege (Python, jq, Node) der passendere Ansatz, die wir in den Ratgebern beschreiben.
Verantwortung
Für die hier beschriebene Methodik und ihre redaktionelle Pflege sind Mateusz Viola (Converter-Engine, Parsing und Serialisierung), Jan-Tristan Rudat (Format-Standards, Encoding und Code-Beispiele) und Eike-Christian Ramcke (Datenschutz und Verantwortung) zuständig. Inhaltlich Verantwortlicher gem. § 18 Abs. 2 MStV ist Eike-Christian Ramcke, Geschäftsführer der AKARA Solutions GmbH (vollständige Angaben im Impressum).