Artikel
Konvertierung zwischen CSV, XML, JSON und YAML: ein praktischer Leitfaden
CSV, JSON, XML und YAML sind die vier Formate, denen Entwickler in Datenpipelines, Konfigurationsdateien und APIs am häufigsten begegnen. Die Konvertierung zwischen ihnen ist unkompliziert, wenn die Datenmodelle übereinstimmen, und überraschend verlustreich, wenn das nicht der Fall ist. Dieser Leitfaden erklärt, was jedes Format darstellen kann und was nicht, wo bei der Konvertierung Informationen verloren gehen und welche Kodierungsfallen zu stiller Datenverfälschung führen. Das data-converter-Tool auf dieser Website verarbeitet drei der vier Formate (CSV, JSON und YAML) vollständig im Browser; die XML-Abschnitte hier dienen als Hintergrundwissen, wenn Sie Daten von Hand oder mit einem separaten Tool bewegen.
Die vier Formate und ihre Datenmodelle
CSV organisiert Daten als flaches Raster aus Zeilen und Spalten. Die erste Zeile benennt in der Regel die Spalten; jede nachfolgende Zeile ist ein Datensatz. Es gibt keine Verschachtelung, keine Typinformationen und keinen Standard für mehr als einfachen Text in Zellen. Jeder Wert ist eine Zeichenkette, sofern die verarbeitende Anwendung keinen Typ erzwingt. JSON modelliert Daten als Baum aus Objekten (Schlüssel-Wert-Maps) und Arrays. Werte können Zeichenketten, Zahlen, Boolesche Werte, null, verschachtelte Objekte oder Arrays beliebiger Tiefe sein. So kann ein einzelnes JSON-Dokument einen Kundendatensatz mit eingebetteten Adressobjekten, Positionsarrays und typisierten numerischen Summen darstellen. XML modelliert Daten als Baum aus Elementen. Jedes Element kann benannte Attribute tragen und untergeordnete Elemente oder Textinhalt enthalten. Es gibt keinen eingebauten numerischen oder Booleschen Typ; alles ist Text. Schemata wie XSD können Typen bei der Validierung erzwingen, aber das Übertragungsformat ist immer Zeichendaten. YAML verwendet Einrückung, um dasselbe Objekt-und-Array-Modell wie JSON auszudrücken, mit saubererer, für Menschen lesbarer Syntax. YAML ist eine Obermenge von JSON: jedes gültige JSON-Dokument ist auch gültiges YAML. Es fügt mehrzeilige Zeichenketten, Kommentare und Anker-Alias-Referenzen für wiederholte Blöcke hinzu. YAML ist in Konfigurationsdateien verbreitet; JSON in API-Antworten.
Verlustbehaftete Konvertierungen: Abflachung und die XML-Mehrdeutigkeit
Die häufigste verlustbehaftete Konvertierung ist das Abflachen von verschachteltem JSON oder XML in CSV. Ein JSON-Objekt mit einem verschachtelten Adressfeld lässt sich nicht sauber auf eine CSV-Zeile abbilden. Die übliche Lösung sind Spaltennamen mit Punktnotation: customer.address.city wird zur eigenen Spalte. Das funktioniert bei einer Verschachtelungsebene, scheitert aber vollständig, wenn ein Array auftaucht. Ein Kunde mit drei Telefonnummern erfordert entweder drei separate Spalten (mit fest kodierter Maximalanzahl), die Aufteilung in eine zweite CSV-Datei oder die Kodierung des Arrays als durch Trennzeichen getrennte Zeichenkette in einer einzelnen Zelle. Keine dieser Optionen lässt sich ohne zusätzliche Metadaten wieder zurück in das ursprüngliche JSON umwandeln. XML führt eine separate Mehrdeutigkeit ein: die Wahl zwischen Attribut und untergeordnetem Element. Der Wert Paris könnte als Attribut gespeichert werden (<city name="Paris">) oder als untergeordnetes Element (<city><name>Paris</name></city>). Wenn ein Konverter XML liest und JSON erzeugt, muss er entscheiden, wie Attribute abgebildet werden. Gängige Konventionen sind das Voranstellen von @ bei Attributschlüsseln oder deren Platzierung unter einem "_attributes"-Schlüssel. Die Wahl ist nicht standardisiert, was bedeutet, dass zwei Konverter, die dasselbe XML lesen, strukturell unterschiedliches JSON erzeugen können. Wenn Sie Daten durch XML und JSON hin- und herkonvertieren wollen, legen Sie eine Konvention fest, bevor Sie beginnen.
CSV-Tücken: Trennzeichen, Anführungszeichen und Kodierung
CSV hat keinen einzigen formalen Standard, nur RFC 4180 als häufig zitierten Referenzpunkt. Das gebräuchlichste Trennzeichen ist ein Komma, aber Semikolons (in europäischen Ländern üblich, wo Kommas als Dezimaltrennzeichen dienen), Tabulatoren (TSV) und senkrechte Striche kommen in der Praxis ebenfalls vor. Eine Datei mit der Endung .csv kann jedes dieser Zeichen verwenden, ohne darauf hinzuweisen. Wenn ein Feldwert das Trennzeichen selbst enthält, verlangt RFC 4180, das Feld in doppelte Anführungszeichen einzuschließen: "San Francisco, CA". Ein doppeltes Anführungszeichen innerhalb eines in Anführungszeichen gesetzten Felds muss durch Verdopplung maskiert werden: "Er sagte ""hallo""". Ein Feld mit einem wörtlichen Zeilenumbruch muss ebenfalls in Anführungszeichen stehen. Parser, die diesen Schritt überspringen, produzieren Zeilenzählfehler, die schwer nachzuverfolgen sind. Die Kodierung ist eine separate Falle. CSV-Dateien aus Windows-Programmen enthalten oft ein UTF-8 BOM (Byte Order Mark: die drei Bytes EF BB BF am Dateianfang). Das BOM hilft Excel, die Kodierung zu erkennen, aber viele Programmiersprachenparser behandeln das BOM als Teil des ersten Spaltennamens und erzeugen eine Spalte mit dem Namen "id" statt "id". Das bricht jeden nachgelagerten Code, der Spalten nach Namen abruft. Beim programmgesteuerten Lesen einer CSV-Datei das BOM vor dem Parsen entfernen oder eine Bibliothek verwenden, die es explizit behandelt.
Formatwahl: Konfiguration, Datenaustausch und Tabellen
Die Formatwahl wird in der Regel durch den Kontext bestimmt, nicht durch persönliche Vorlieben. JSON ist der Standard für REST-APIs und den Datenaustausch zwischen Browser und Server. Es ist kompakt, wird in jeder Programmiersprache nativ geparst und enthält Typinformationen für Zahlen und Boolesche Werte. Seine Schwäche ist das Fehlen von Kommentaren, was es für Dateien ungeeignet macht, die Entwickler von Hand lesen und bearbeiten. YAML wird für Konfigurationsdateien bevorzugt (Kubernetes-Manifeste, CI-Pipeline-Definitionen, Ansible-Playbooks), weil es Inline-Kommentare erlaubt und bei vielen Einrückungsebenen leichter lesbar ist als JSON. Das Hauptrisiko ist, dass Einrückungsfehler lautlos sind: ein falsch eingerückter Schlüssel wechselt in einen anderen Gültigkeitsbereich, ohne Parsing-Fehler zu erzeugen. XML ist nach wie vor Standard in älteren Unternehmenssystemen, SOAP-Webdiensten, Dokumentformaten (DOCX, SVG, RSS) und Kontexten, die Schemavalidierung oder Namespace-Disambiguierung erfordern. Es ist ausführlich, aber XPath- und XSLT-Werkzeuge sind ausgereift. CSV ist die richtige Wahl, wenn die Daten tatsächlich flach sind und der Empfänger eine Tabellenkalkulationsanwendung oder ein Datenanalytiker ist. Es ist für Konfiguration oder API-Datenaustausch nicht geeignet, da es kein Typsystem und keine Verschachtelung hat.
Lokal konvertieren mit data-converter
Das data-converter-Tool auf dieser Seite parst und konvertiert zwischen CSV, JSON und YAML vollständig im Browser; es liest oder schreibt kein XML. Zu keinem Zeitpunkt werden Daten an einen Server übertragen. Die Konvertierung läuft in Ihrer lokalen JavaScript-Laufzeitumgebung, und die Ausgabe steht zum Herunterladen oder Kopieren bereit, ohne dass irgendetwas Ihr Gerät verlässt. Das ist wichtig bei Daten, die Sie nicht weitergeben dürfen: API-Antworten mit persönlichen Informationen, Konfigurationsdateien mit internen Hostnamen oder CSV-Exporte aus internen Datenbanken. Das Einfügen solcher Daten in einen webbasierten Konverter, der auf einem Server läuft, bedeutet, dass der Inhalt über das Netzwerk gesendet und auf Hardware verarbeitet wird, die Sie nicht kontrollieren. Mit data-converter ist der Browser-Tab die Verarbeitungsumgebung. Das Tool wendet RFC 4180-Anführungszeichen beim Lesen oder Schreiben von CSV an und erwartet für JSON oder YAML, die nach CSV konvertiert werden, ein flaches Array von Objekten: Ein verschachtelter Objekt- oder Array-Wert unter einem Schlüssel wird nicht automatisch per Punkt-Notation abgeflacht, also flachen Sie diese Felder vor der Konvertierung selbst ab, wenn Sie sie als separate Spalten benötigen. Müssen Sie Daten zu oder von XML bewegen, konvertieren Sie sie zunächst mit einem dedizierten XML-Tool zu JSON oder YAML und bringen Sie das Ergebnis dann hierher.
Tools in diesem Artikel
Häufige Fragen
Kann ich JSON über CSV hin- und herkonvertieren und das Original zurückbekommen?
Nur wenn das JSON ein flaches Array von Objekten ohne verschachtelte Felder und ohne Arrays als Werte ist. Sobald Sie ein verschachteltes Objekt oder einen Array-Wert haben, erfordert die CSV-Darstellung eine strukturelle Entscheidung (Punkt-Notation-Spalten, mehrere Zeilen oder kodierte Zeichenketten), die nicht automatisch umgekehrt werden kann. Wenn Ihre Daten Verschachtelungen aufweisen, können JSON, XML oder YAML verlustfrei hin- und herkonvertiert werden; CSV nicht.
Warum sieht mein CSV nach dem Export aus einer europäischen Anwendung in Excel falsch aus?
Europäische Ländereinstellungen verwenden häufig Semikolons als CSV-Trennzeichen, weil Kommas für die Dezimalnotation reserviert sind. Excel mit europäischer Ländereinstellung erwartet Semikolons. Wenn die Datei Kommas verwendet, behandelt Excel die gesamte Zeile als eine einzelne Spalte. Die Lösung ist entweder, das Trennzeichen in den Exporteinstellungen zu ändern, oder den Datenimport-Assistenten von Excel zu verwenden, der das manuelle Angeben des Trennzeichens erlaubt. Das UTF-8 BOM-Problem ist davon getrennt: Ohne BOM kann Excel akzentuierte Zeichen auch als unlesbaren Text darstellen.
Was ist der praktische Unterschied zwischen YAML und JSON?
Beide stellen dasselbe zugrundeliegende Datenmodell dar: Objekte, Arrays, Zeichenketten, Zahlen, Boolesche Werte und null. YAML fügt Kommentare (Zeilen beginnend mit #), mehrzeilige Zeichenkettenliterale und Ankerreferenzen für wiederholte Blöcke hinzu. JSON ist streng eine Teilmenge von gültigem YAML, aber JSON-Parser lesen kein YAML. Die praktische Regel: JSON für API-Payloads und Datenspeicherung verwenden; YAML für Konfigurationsdateien, die Menschen bearbeiten und die von Inline-Kommentaren profitieren.