Ein Rechteck und ein Baum
CSV ist ein Rechteck. Jeder Datensatz ist eine Zeile, jedes Trennzeichen bewegt sich in die nächste Spalte und die optionale erste Zeile gibt diesen Positionen Namen. Ein Feld kann in Anführungszeichen ein Trennzeichen oder einen Zeilenumbruch enthalten, die Struktur bleibt jedoch flach: Zeile, Spalte, Zelle.
JSON ist ein Baum. Seine beiden Behälter haben unterschiedliche Bedeutungen:
- Ein Objekt ordnet Namen Werten zu. - Ein Array sorgt für die Reihenfolge der Werte.
Beide können ein anderes Objekt oder Array enthalten, und keine Regel besagt, dass zwei Objekte nebeneinander denselben Namen tragen müssen. Diese Flexibilität ist der Grund, warum JSON für eine API-Antwort funktioniert und warum „JSON in CSV konvertieren“ keine vollständige Anweisung ist. Ein Konverter muss entscheiden, wo der Baum in Reihen geschnitten werden soll und wie die Pfade benannt werden sollen, die zu den einzelnen Blättern führen.
Drei Formen, die ehrlich tafelförmig sind
Es gibt drei gängige Formen der obersten Ebene mit vertretbaren Reihenregeln.
Ein Objekt
{ "name": "Ada", "city": "London" }
Dies kann eine Zeile mit zwei Spalten sein. Es ist ein kleiner Tisch, aber immer noch ein Tisch.
Ein Array von Objekten
[
{ "name": "Ada", "city": "London" },
{ "name": "Grace", "city": "New York", "language": "COBOL" }
]
Jedes Objekt ist eine Zeile und die Schlüsselvereinigung ist der Header: name, city, dann language. Adas Sprachzelle ist leer. Wenn nur Überschriften vom ersten Objekt übernommen würden, würde das Grace-Feld stillschweigend verworfen, weshalb bei einer korrekten Konvertierung jeder Datensatz überprüft werden muss, bevor der Header geschrieben wird.
Ein Array von Arrays
[
["Ada", "London"],
["Grace", "New York"]
]
Jedes innere Array ist eine Zeile und die Position ist die Spalte. Was Position Null bedeutet, fehlt, so dass ein allgemeiner Konverter es column_1 nennen kann, aber die Überschrift name nicht ehrlich erfinden kann. Arrays sind kompakt und nützlich, wenn ein Schema separat übertragen wird. Sie sind spröde, wenn eine Person nur die Feile hat.
Vor dem Weiterlesen
Das erste JSON-Objekt verfügt über die Schlüssel „Name“ und „Stadt“. Das Hundertste hat auch Sprache. Wann darf der CSV-Header sicher geschrieben werden?
Nach Prüfung des gesamten Datensatzes. Ein JSON-Objekt wird nicht durch die Schlüssel des Objekts davor eingeschränkt, und spärliche Daten sind normal: Ein Kunde hat einen zweiten Vornamen, eine Rechnung hat eine Steuernummer, ein API-Ergebnis enthält eine optionale Warnung. Wenn das erste Objekt allein den Header definiert, verschwinden spätere Felder und die Ausgabe sieht immer noch vollkommen gültig aus. Der sichere Header ist die Vereinigung von Schlüsseln, die in der zuerst sichtbaren Reihenfolge gehalten werden, sodass das Ergebnis deterministisch und lesbar ist. Datensätze, denen einer dieser Schlüssel fehlt, erhalten eine leere Zelle unter dieser Überschrift.
Warum Objekte normalerweise die sicherere JSON-Zeile sind
Vergleichen Sie einen Datensatz, nachdem ein Feld hinzugefügt wurde.
// positional
["Ada", "Lovelace", "London"]
// named
{ "first": "Ada", "last": "Lovelace", "city": "London" }
Geben Sie nun einen zweiten Vornamen ein. Im Array muss jeder Verbraucher wissen, dass die Stadt von Platz zwei auf Platz drei gerückt ist. Ein älterer Verbraucher kann "Byron" als Stadt lesen, ohne einen Fehler auszulösen. Im Objekt ändert das Hinzufügen von "middle": "Byron" nicht die Bedeutung von city und ein Verbraucher, der das neue Feld nicht benötigt, kann es ignorieren.
Arrays gewinnen durch Wiederholung: Tausende von Zeilen wiederholen nicht dieselben Schlüsselnamen. Diese Einsparung ist in einem hochvolumigen Protokoll mit einem versionierten Schema wichtig. Normalerweise spielt es keine Rolle, wenn eine 20-MB-Datei an eine Person weitergegeben wird, da die Fähigkeit, die Daten zu lesen und zu diagnostizieren, mehr wert ist als ein paar komprimierte Kilobyte.
Aus diesem Grund verwendet CSV zu JSON sinnvollerweise standardmäßig ein Objekt pro Kopfzeile und bietet Arrays als explizite Alternative. Der Header lieferte bereits Namen; Sie zu verwerfen sollte eine Entscheidung und kein Nebeneffekt sein.
Auch der umgekehrte Fall ist erwähnenswert. Eine Verhältnistabelle ist bereits ein Rechteck: Jeder Multiplikator ist eine Zeile und die beiden skalierten Größen sind stabile Spalten. Es kann in eine CSV-Datei umgewandelt werden, ohne dass ein Schema erfunden werden muss, da die Berechnung selbst bereits entschieden hat, was jede Zeile und Spalte bedeutet.
Durch die Verschachtelung wird das Modell sichtbar
Betrachten Sie einen Wert:
{
"name": "Ada",
"address": {
"city": "London",
"postcode": "SW1A"
},
"roles": ["mathematician", "writer"]
}
Ein Rechteck hat keine verschachtelte Zelle. Zwei häufige Antworten sind sowohl legitim als auch nicht gleichwertig.
Serialisieren Sie den verschachtelten Wert. Die address-Zelle enthält kompaktes JSON und die roles-Zelle enthält das JSON-Array. Die Werte bleiben wiederherstellbar, aber eine Tabelle kann nicht direkt nach Stadt sortieren, ohne die Zelle erneut zu analysieren.
Objektpfade reduzieren. Die Überschriften werden zu address.city und address.postcode. Dies ist praktisch zum Filtern und behält den übergeordneten Namen in jeder Überschrift bei. Arrays sollten normalerweise eine JSON-Zelle bleiben: Durch die Erweiterung von roles[0], roles[1] und höher wird das Schema durch die Listenlänge vorgegeben und impliziert, dass das erste Element in jeder Zeile eine stabile Bedeutung hat.
Keine der beiden Antworten kann allgemein als richtig angesehen werden. JSON zu CSV macht die Wahl offen, weil das Verstecken hinter „automatisch“ einen Anwendungsfall stillschweigend falsch machen würde.
Typen verschwinden an der CSV-Grenze
Diese JSON-Werte sind unterschiedlich:
{ "number": 42, "word": "42", "nothing": null, "missing": "not present at all" }
CSV enthält nur Zeichen zwischen den Grenzen. Beide 42 Werte werden zu den beiden Zeichen 42; null und ein fehlendes Feld werden gemäß der üblichen Konvention beide zu einer leeren Zelle. Eine Kalkulationstabelle kann beim Öffnen der Datei auf eine Zahl, ein Datum oder eine Formel schließen, aber diese Schlussfolgerung ist das Verhalten des Importeurs und nicht die Typinformationen, die von CSV übertragen werden.
Das erklärt auch den Formelschutz. Eine JSON-Zeichenfolge, die mit =, +, - oder @ beginnt, ist explizit Text. CSV kann dies nicht sagen und die Tabellenkalkulationssoftware könnte es als Ausdruck interpretieren. Wenn dem Feld ein Apostroph vorangestellt wird, bleibt die Absicht der Quelle – der Text – erhalten, während eine echte JSON-Nummer wie -2 numerischer Text ohne Präfix bleibt.
Beim Formatieren von JSON wird das Modell nicht konvertiert
Das hübsche Drucken von Klammern und Einrückungen scheint der Schritt mit der geringsten Konsequenz in diesem Arbeitsablauf zu sein, aber die übliche Verknüpfung zum Parsen und Stringifizieren überschreitet die gleichen Modellgrenzen wie ein Konverter. Sobald eine JSON-Zahl zu einer binären64-Sprachzahl wird, kann eine Ganzzahl außerhalb des genauen Bereichs unterschiedliche Ziffern annehmen. Sobald ein Objekt mit doppelten Namen zu einer normalen Anwendungszuordnung wird, kann eines dieser Mitglieder verschwinden. Ein Serialisierer schreibt dann seine eigenen Werte und legt nicht nur die Quelle dar.
Ein Token-erhaltender Formatierer geht einen engeren Weg: Validieren Sie das gesamte Dokument, verfolgen Sie Zeichenfolgen und Escapezeichen in Anführungszeichen und ändern Sie nur die vier Leerzeichen, die die JSON-Grammatik zwischen Token zulässt. Dadurch bleibt eine lesbare Datei lesbar, ohne dass festgestellt werden muss, dass die Tastenreihenfolge, doppelte Namen oder die Schreibweise von Exponenten versehentlich erfolgt sind. Verwenden Sie die Modellkonvertierung, wenn sich das Modell ändern soll. Verwenden Sie einen Formatierer, wenn das Layout die einzige gewünschte Änderung ist.
Bei einem Roundtrip bleiben Entscheidungen und nicht Bytes erhalten
Angenommen, eine CSV-Datei mit Headern wird zu einem Array von JSON-Objekten und wird dann wieder zur CSV. Die Tabelle hat möglicherweise immer noch dieselben Werte, aber die Byteidentität ist keine vernünftige Erwartung:
- Zitate können unter Beibehaltung ihrer Äquivalenz hinzugefügt oder entfernt werden. - Zeilenenden können auf CRLF normalisiert werden. – Eine Semikolon- oder Tabulatoreingabe kann als durch Kommas getrennte Ausgabe zurückgegeben werden. – Die JSON-Phase kann nicht sicherstellen, ob
42absichtlich Text war. - Null, fehlend und eine leere Zeichenfolge können alle in einer leeren Zelle zusammentreffen. - Aus Gründen der Excel-Kompatibilität kann ein UTF-8-Marker hinzugefügt werden.
Verwenden Sie eine Prüfsumme, wenn zwei Dateien identisch sein sollen. Verwenden Sie einen Strukturtest – dieselben Überschriften, Zeilen und deklarierten Wertkonventionen –, wenn ein Datenmodell absichtlich ein anderes durchlaufen hat.
Die praktische Regel
Verwenden Sie ein Array von Objekten, wenn Personen die Datei überprüfen, die Datensätze möglicherweise spärlich sind oder sich das Schema weiterentwickelt. Verwenden Sie Arrays von Arrays, wenn es sich bei der Position bereits um einen formellen Vertrag handelt und eine kompakte Übertragung wichtig ist. Behalten Sie verschachtelte Werte als JSON bei, wenn es auf Roundtriping ankommt; Reduzieren Sie Objektpfade, wenn es auf die Tabellenkalkulation ankommt.
Am wichtigsten ist, dass Sie diese Entscheidungen neben dem Artefakt aufschreiben. Bei der Konvertierung werden nicht nur Klammern durch Kommas ersetzt. Es ist der Moment, in dem ein Baum in ein Rechteck umgewandelt wird und die dort getroffenen Entscheidungen darüber entscheiden, ob spätere Zeilen immer noch das bedeuten, was die Quelle bedeutete.
Fragen
Kann CSV JSON-Zahlen, Boolesche Werte und Nullen exakt beibehalten?
Nein. CSV-Felder sind Textfelder und enthalten keine Standardtypdeklaration. Der Text 42 kann später als Zahl abgeleitet werden, „true“ kann in einem Importer zu einem Booleschen Wert und in einem anderen zu einem Wort werden, und eine leere Zelle kann ein fehlendes Feld nicht von JSON Null unterscheiden, ohne eine vereinbarte Konvention außerhalb von CSV.
Ist jedes JSON-Array eine Tabelle?
Nein. Ein Array kann Grundelemente, gemischte Werte, verschachtelte Listen unabhängiger Längen oder Objekte ohne gemeinsame Bedeutung enthalten. Es ist nur dann tabellarisch, wenn jedes Element dieselbe Art von Zeile darstellt und es eine stabile Möglichkeit gibt, jeden Wert einer Spalte zuzuweisen.
Warum können zwei JSON-Datensätze unterschiedliche Schlüssel haben?
JSON-Objekte sind unabhängige Karten, keine Zeilen, die durch ein Schema eingeschränkt sind. In API-Antworten mit geringer Dichte werden häufig nicht verfügbare Werte weggelassen, und spätere Datensätze führen möglicherweise Felder ein, die der erste Datensatz nicht enthielt. Daher muss ein Konverter den gesamten Satz prüfen, anstatt das erste Objekt als Gesetz zu behandeln.
Wird CSV zu JSON zu CSV die ursprünglichen Bytes reproduzieren?
Normalerweise nicht. Äquivalente CSV-Dateien können unterschiedliche Anführungszeichen, Trennzeichen, Zeilenenden oder Spaltenreihenfolgen verwenden, und bei der JSON-Konvertierung gehen Unterscheidungen verloren, z. B. ob eine 42 ohne Anführungszeichen als Text oder Zahl gedacht war. Ein Roundtrip kann die Werte einer Tabelle gemäß deklarierten Regeln beibehalten, ohne dass die Originaldatei Byte für Byte erhalten bleibt.
Ändert die Formatierung von JSON das Datenmodell?
Ein Formatierer, der nur Leerzeichen enthält, muss dies nicht tun. Es kann den JSON validieren und die Schlüsselreihenfolge, doppelte Namen, die Schreibweise von Zahlen und Zeichenfolgen-Escapezeichen beibehalten, während nur unbedeutende Leerzeichen geändert werden. Das Parsen in Anwendungswerte und das erneute Serialisieren ist ein umfassenderer Vorgang, der einige dieser Unterschiede auf Quellenebene normalisieren oder verwerfen kann.