Entwicklertools · Syntaxkonverter
CSVs fehlender Standard: Was RFC 4180 abdeckt und was es offen lässt
· Hintergrund
csv json Datenformate
CSV ist älter als jede Spezifikation, und der einzige RFC, der sie beschreibt, ist informativ und bewusst eng gefasst. In diesem Beitrag wird erklärt, was RFC 4180 definiert, worüber es nichts aussagt und warum die Konvertierung von CSV daher immer eine Verhandlung ist.
Wessen CSV ist richtig? – zwei Exporte derselben Tabelle, einer mit Semikolons und einer mit Kommas, beide mit dem Namen CSV
ToolAcre kann durch Kommas, Semikolons oder Tabulatoren getrennte Ausgaben von JSON ausgeben. Es liest nicht zwei konkurrierende CSV-Exporte und erklärt auch keinen von beiden als korrekt. CSV ist hier schreibgeschützt, daher ist die Wahl des Trennzeichens eine explizite Ausgabeoption und kein Erkennungsalgorithmus.
Diese Unterscheidung verhindert einen allgemeinen Sachverhalt. Eine Schnittstelle, die Semikolons schreiben kann, hat nicht bewiesen, dass sie Semikolons in einer unbekannten Datei identifizieren, Gebietsschema-Dezimalzahlen verarbeiten oder Header interpretieren kann. Hierbei handelt es sich um separate Eingabeverantwortungen, die bewusst ausgeschlossen werden.
Zwei Trennzeichen sind Ausgabeoptionen und kein Beweis dafür, dass dieses Panel eine der beiden Dateien liest
Das Repository enthält keine Quelle für den frühen Tabellenkalkulations- oder Datenbankverlauf, daher wird im Artikel keine Chronologie erstellt. Es beginnt mit dem aktuellen Writer und seinen Tests: Datensätze, Felder, Trennzeichen, CRLF-Terminierung und Anführungszeichen-Escape.
Historischer Kontext kann später mit überprüften Quellen hinzugefügt werden. Eine Konverterimplementierung ist ein Beweis dafür, was das Produkt heute schreibt, nicht dafür, wann eine Konvention zum ersten Mal erschien oder warum die Anbieter voneinander abweichen.
CSV Verlauf vor RFC 4180 liegt außerhalb des Repository-Beweises
Ein Feld, das Trennzeichen, doppelte Anführungszeichen, Wagenrücklauf oder Zeilenvorschub enthält, wird in doppelte Anführungszeichen eingeschlossen und jedes eingebettete Anführungszeichen wird verdoppelt. Führende oder nachgestellte Leerzeichen werden ebenfalls in Anführungszeichen gesetzt, um das häufige Abschneiden von Tabellenkalkulationen zu verhindern. Datensätze enden mit CRLF und die Datei wird beendet.
Diese Verhaltensweisen folgen im Repository getesteten RFC-4180-Regeln. Der Artikel vermeidet den Anspruch auf universelle Konformität, da der Autor auch alternative Trennzeichen unterstützt und eine Sicherheitsbehandlung außerhalb der engen Grammatik hinzufügt.
Der Autor verwendet Zitate im RFC-4180-Stil und CRLF, ohne Anspruch auf vollständige Standardkonformität zu erheben
CSV-Zellen behalten nicht die Typen JSON bei. Null- und leere Zeichenfolgen werden beide zu leeren Zellen, während boolesche Werte und Zahlen zu Textdarstellungen werden. UTF-8-Inhalte werden weitergeleitet und für Verbraucher, die sie benötigen, kann eine optionale Stückliste vorangestellt werden.
Die Interpretation des Gebietsschemas ist nicht eingebettet. Ein Semikolon-Trennzeichen kann mit Dezimalkommas koexistieren, der Writer formatiert Zahlen jedoch nicht nach Gebietsschema neu und codiert keinen Datumstyp. Die empfangende Anwendung entscheidet weiterhin, wie jedes Feld interpretiert wird.
Codierung, Typ- und Gebietsschemagrenzen bleiben in diesem Writer explizit
Die implementierten Varianten sind Komma, Semikolon und Tabulator sowie eine optionale Stückliste. Formelähnlicher Text, der mit `=`, `+`, `-`, `@`, Tabulator oder Wagenrücklauf beginnt, wird standardmäßig mit einem Apostroph vorangestellt, sodass er in Tabellenkalkulationen als Text behandelt wird. Benutzer können diesen Schutz deaktivieren und eine Warnung erhalten.
In diesem Writer gibt es keinen `sep=`-Hinweis oder Backslash-Escape-Modus. Es wäre falsch, diese als ausgelieferte Optionen zu erwähnen. Eingebettete Anführungszeichen nutzen die Verdoppelung, genau wie die Tests bestätigen.
Die beobachteten Tabellenkalkulationsvariationen beschränken sich auf die hier implementierten Optionen und Schutzmaßnahmen
Jede Annahme in dieser Route beginnt mit dem analysierten JSON: Welcher Wert liefert Zeilen, wie wird die Verschachtelung in gepunktete Spalten abgeflacht und welche Schlüssel werden zu Überschriften. Über einen eingehenden CSV-Dialekt wird keine Annahme getroffen, da eingehender CSV abgelehnt wird.
Diese Korrektur kehrt die gewünschte Richtung der Arbeitsmappe um. Ein CSV-to-JSON-Workflow muss Trennzeichen, Anführungszeichen, Kopfzeile und Zelltypen in einem anderen Tool auswählen. Der Fehler von ToolAcre erklärt diese Weigerung und nicht eine stille Vermutung.
Konvertierungsannahmen gelten nur für JSON-zu-CSV, weil die Eingabe von CSV abgelehnt wird
Das Reparieren fehlerhafter CSV liegt außerhalb des Rahmens. Unterbrochene Anführungszeichen, gemischte Kodierungen und versehentliche Trennzeichen erfordern den CSV Cleaner oder einen anderen Parser mit expliziter Diagnose. Der Syntaxkonverter empfängt strengen JSON-Text, nicht beschädigten CSV-Text.
Die Ausgabe kann für ein Ziel immer noch ungeeignet sein, wenn ein verschachtelter Baum mehrdeutige gepunktete Spalten erstellt oder 2,000 Spalten überschreitet. Warnungen und Obergrenzen machen diese Tabellenfehler vor dem Download sichtbar.
Fazit: CSV ist eine Konvention, kein Format – und wie das Syntaxkonverter-Bedienfeld eine wohlgeformte Datei in JSON umwandelt, können Sie überprüfen
Behandeln Sie CSV als eine Konvention, deren Auswahl sichtbar sein muss. ToolAcre dokumentiert seine Ausgabeoptionen und lehnt die unterspezifizierte Umkehrung ab. Das ist zuverlässiger, als eine Taste für zwei grundlegend unterschiedliche Aufgaben zu verwenden.
Überprüfen Sie Trennzeichen, Anführungszeichen, CRLF, BOM und Formel-Escapezeichen gegenüber dem empfangenden System. Wenn eine Eingabeanalyse erforderlich ist, verwenden Sie ein Tool, das nachfragt, anstatt die Konventionen des Autors auf eine unbekannte Datei zu übertragen.
Eine praktische Akzeptanzprüfung öffnet die generierte Datei im vorgesehenen Consumer und untersucht auch die Rohbytes oder den Text. Die Verbraucheransicht fängt Anzeige- und Importprobleme auf; Die Rohansicht bestätigt Trennzeichen, doppelte Anführungszeichen, CRLF und eine optionale Stückliste ohne Neuinterpretation der Tabellenkalkulation. Testen Sie formelähnliche Zeichenfolgen als inerten Text und eine negative Zahl als Zahl. Diese gepaarten Prüfungen überprüfen den tatsächlichen Vertrag des Autors, ohne zu behaupten, dass jedes Programm die CSV-Konventionen identisch implementiert.