CSV ist nicht „nur Text“ ── CSV in der Praxis für C#-Business-Anwendungen (Zeichenkodierung, Excel-Kompatibilität, Schutz vor Injection)

Datenaustausch über CSV ist in der Welt der Business-Anwendungen bis heute ein fester Bestandteil des Alltags. Gerade weil es so aussieht, als würde man dabei „nur Text mit Kommas verbinden“, ist es zugleich ein Bereich, in dem sich bestimmte Fehler immer wieder wiederholen: Ein selbstgebauter Parser bricht an einem Komma innerhalb eines Feldes zusammen, beim Öffnen in Excel entsteht Zeichensalat, oder die führende Null einer Telefonnummer verschwindet.

Dieser Artikel geht von einer Business-Anwendung aus, die in C# CSV-Dateien liest und schreibt, und ordnet – in der Reihenfolge, in der in der Praxis üblicherweise Entscheidungsbedarf entsteht – die CSV-Spezifikation (RFC 4180) und ihre real vorkommenden Dialekte, die Wahl der Zeichenkodierung, Kompatibilitätsprobleme mit Excel, Schutzmaßnahmen gegen CSV-Injection sowie typische Betriebsfallen ein.

1. Zunächst das Fazit (Entscheidungstabelle)

Designentscheidungen zu CSV leitet man am besten rückwärts davon ab, wer (bzw. was) die Datei letztlich öffnet.

Vorab die wichtigsten Erkenntnisse:

• Das Parsen von CSV mit String.Split(',') ist spezifikationsgemäß fehlerhaft, auch wenn es scheinbar funktioniert. Der Grund ist, dass Kommas, Zeilenumbrüche und Anführungszeichen innerhalb eines Feldes nicht verarbeitet werden können. Verwenden Sie im Rahmen der .NET-Standardbibliothek TextFieldParser (Kapitel 3).
• Probleme mit der Zeichenkodierung entstehen dadurch, wie Excel die Datei interpretiert. Für CSV-Dateien, die von Menschen in Excel geöffnet werden, ist UTF-8 mit BOM derzeit die solide Wahl. Zudem gibt es in .NET die Falle, dass es von der Art der Angabe der Encoding abhängt, ob ein BOM ausgegeben wird oder nicht (Kapitel 4).
• In .NET (Core) lässt sich Shift_JIS ohne ein zusätzliches Paket nicht verwenden. Erst wenn der CodePagesEncodingProvider aus dem Paket System.Text.Encoding.CodePages registriert wird, gelingt der Aufruf von Encoding.GetEncoding("shift_jis"). Das ist ein klassischer Stolperstein, an dem eine von .NET Framework migrierte CSV-Verarbeitung erstmals im Produktivbetrieb eine Ausnahme wirft.
• Verlorene führende Nullen und die Umwandlung in ein Datum lassen sich auf CSV-Seite nicht verhindern. Wichtig ist dabei die Tatsache, dass auch das Einschließen in doppelte Anführungszeichen dies nicht verhindert (Kapitel 5).
• Anwendungen, die Benutzereingaben in CSV ausgeben, benötigen einen Schutz gegen CSV-Injection. Felder, die mit = oder + beginnen, interpretiert Excel als Formel (Kapitel 6).

2. Die „Spezifikation“ von CSV ── RFC 4180 und reale Dialekte

Für CSV existiert mit RFC 4180 ein De-facto-Standard¹. In der Praxis müssen dabei lediglich die folgenden vier Regeln beachtet werden.

1. Datensätze werden durch einen Zeilenumbruch (CRLF) getrennt, Felder durch ein Komma.
2. Enthält ein Feld ein Komma, einen Zeilenumbruch oder ein doppeltes Anführungszeichen, wird das gesamte Feld in doppelte Anführungszeichen eingeschlossen.
3. Ein doppeltes Anführungszeichen innerhalb eines Feldes wird durch Verdopplung als "" maskiert.
4. Felder, die nicht eingeschlossen werden müssen, dürfen wahlweise eingeschlossen werden oder nicht.

Die folgende Zeile ist somit ein Datensatz mit drei Feldern.

1001,"株式会社サンプル 営業部","住所は""東京都○○区1-2-3""です,と入力された備考"

RFC 4180 ist jedoch nur ein „De-facto-Standard“, und in der Praxis gibt es unzählige Dialekte von CSV: Zeilenumbrüche nur als LF, keine Anführungszeichenverarbeitung, Tabulator oder Semikolon als Trennzeichen, mit oder ohne Kopfzeile. Genau deshalb ist es die Maßnahme mit dem besten Kosten-Nutzen-Verhältnis zur Vermeidung späterer Probleme, in der Integrationsspezifikation den Hinweis „konform zu RFC 4180“ sowie Zeichenkodierung, BOM, Zeilenumbruchzeichen und Vorhandensein einer Kopfzeile ausdrücklich festzuhalten.

3. Nicht mit Split(‘,’) selbst bauen ── Praxis des Einlesens

Vor dem Hintergrund der Regeln aus dem vorigen Kapitel wird deutlich, warum String.Split(',') versagt: Ein Komma innerhalb eines Feldes führt zu einer zusätzlichen, ungewollten Aufteilung, und ein Zeilenumbruch innerhalb von Anführungszeichen zerschneidet die Zeile mittendrin. Dass es „funktioniert, weil die aktuell eingehende Datei zufällig keine Daten mit Kommas enthält“, ist reiner Zufall – abhängig von den Daten kann es jederzeit zusammenbrechen.

Möchte man im Rahmen der .NET-Standardbibliothek korrekt einlesen, kann Microsoft.VisualBasic.FileIO.TextFieldParser verwendet werden. Der Namespace stammt zwar aus Visual Basic, lässt sich aber ganz normal auch aus C# heraus nutzen.

using Microsoft.VisualBasic.FileIO; // Microsoft.VisualBasic.Core (im SDK für Windows-Desktop-Anwendungen enthalten)

using var parser = new TextFieldParser(path, System.Text.Encoding.UTF8)
{
    TextFieldType = FieldType.Delimited,
    HasFieldsEnclosedInQuotes = true, // verarbeitet in Anführungszeichen eingeschlossene Felder korrekt
    TrimWhiteSpace = false, // Standardwert ist true (führende/nachfolgende Leerzeichen werden stillschweigend entfernt). Bei Daten, in denen Leerzeichen Bedeutung tragen, deaktivieren
};
parser.SetDelimiters(",");

while (!parser.EndOfData)
{
    try
    {
        string[]? fields = parser.ReadFields();
        if (fields is null) break;
        // fields[0], fields[1], ... verarbeiten
    }
    catch (MalformedLineException ex)
    {
        // Fehlerhafte Zeile: Inhalt und Zeilennummer lassen sich über ErrorLine / ErrorLineNumber protokollieren
        logger.LogWarning("Zeile {Line} der CSV-Datei hat ein ungültiges Format: {Content}",
            ex.LineNumber, parser.ErrorLine);
    }
}

Der praktische Vorteil von TextFieldParser liegt neben der Anführungszeichenverarbeitung (HasFieldsEnclosedInQuotes) darin, dass sich fehlerhafte Zeilen als MalformedLineException mitsamt Zeilennummer erkennen lassen. Beim Einlesen von CSV-Dateien in Business-Anwendungen ist häufig genau das die entscheidende Weichenstellung in der Spezifikation: Wird bei einer fehlerhaften Zeile die gesamte Datei zurückgewiesen, oder wird nur diese Zeile übersprungen und gemeldet? Dieses Exception-Handling lässt sich direkt in die Spezifikation übernehmen.

Werden zusätzlich das Mapping von Spalten auf Objekte, Typkonvertierung oder Performance im Bereich mehrerer Millionen Zeilen benötigt, sollte der Einsatz einer bewährten CSV-Bibliothek (weit verbreitet über NuGet) geprüft werden. Unabhängig davon, welche Bibliothek gewählt wird, sind vier Punkte zu prüfen: die Anführungszeichenverarbeitung gemäß RFC 4180, die Angabe der Zeichenkodierung, der Umgang mit fehlerhaften Zeilen und die Möglichkeit eines Streaming-Einlesens.

Da die Spezifikation beim Schreiben einfacher ist, ist eine Eigenimplementierung praktikabel – die Escape-Verarbeitung sollte dabei aber unbedingt in einer einzigen Funktion gebündelt werden.

// Die Escape-Logik der Ausgabeseite wird in dieser einen Funktion gebündelt
static string ToCsvField(string? value)
{
    value ??= string.Empty;
    bool needsQuoting = value.Contains(',') || value.Contains('"')
        || value.Contains('\r') || value.Contains('\n');
    return needsQuoting ? $"\"{value.Replace("\"", "\"\"")}\"" : value;
}

Bleibt auch nur eine Stelle übrig, an der etwa „nur die Betragsspalte“ manuell per string.Join zusammengesetzt wird, wird genau diese Stelle zum künftigen Fehlerherd.

4. Zeichenkodierung ── Excel-Verhalten und Fallstricke in .NET

4.1 Für das Öffnen in Excel: UTF-8 mit BOM

Der Großteil des Zeichensalats bei CSV entsteht dadurch, dass Excel die Zeichenkodierung der Datei falsch erkennt. Öffnet man eine UTF-8-CSV-Datei ohne BOM (die wenige Bytes am Dateianfang, die als Kennzeichen dienen) per Doppelklick, wird sie je nach Umgebung als ANSI interpretiert (in japanischen Umgebungen als Shift_JIS), wodurch japanischer Text komplett unlesbar wird. Bei UTF-8 mit BOM wird die Datei dagegen korrekt als UTF-8 erkannt. Deshalb ist es derzeit die solide Wahl, CSV-Dateien, die Menschen per Doppelklick in Excel öffnen, als UTF-8 mit BOM auszugeben.

Hinzu kommt eine Falle auf .NET-Seite: Ob ein BOM ausgegeben wird, hängt davon ab, wie die Encoding übergeben wird.

// UTF-8 ohne BOM: Standardverhalten, wenn keine Kodierung angegeben wird
File.WriteAllText(path, csv);

// UTF-8 mit BOM: Encoding.UTF8 (statische Eigenschaft) ist so konfiguriert, dass ein BOM ausgegeben wird
File.WriteAllText(path, csv, Encoding.UTF8);

// Um die Absicht eindeutig zu machen, empfiehlt sich die Angabe über den Konstruktor – so entstehen keine Missverständnisse
File.WriteAllText(path, csv, new UTF8Encoding(encoderShouldEmitUTF8Identifier: true));

Dass sich die resultierende Datei unterscheidet, je nachdem, ob Encoding.UTF8 übergeben oder die Angabe weggelassen wird, ist ein Verhalten, das man ohne entsprechendes Wissen kaum bemerkt. Wurde in der Spezifikation festgelegt, „Systemintegration ohne BOM“ und „für Excel mit BOM“ zu verwenden, empfiehlt es sich, diese Absicht auch im Code über new UTF8Encoding(...) explizit zu machen.

4.2 Shift_JIS in .NET (Core) erfordert eine Registrierung

Bei der Integration mit Legacy-Systemen sind CSV-Dateien in Shift_JIS (Codepage 932) auch heute noch weit verbreitet. Wichtig ist hier: .NET (Core) / .NET 5 und später unterstützt standardmäßig nur eine kleine Auswahl an Kodierungen wie Unicode-Varianten und ASCII. Encoding.GetEncoding("shift_jis") löst so lange eine Ausnahme aus, bis das Paket System.Text.Encoding.CodePages hinzugefügt und der CodePagesEncodingProvider registriert wurde.

using System.Text;

// Beim Anwendungsstart einmalig registrieren (z. B. in Program.cs)
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

// Damit lässt sich Shift_JIS (Codepage 932) abrufen
Encoding sjis = Encoding.GetEncoding("shift_jis");

Das ist ein klassischer Stolperstein: Eine Anwendung, deren CSV-Verarbeitung noch aus der Zeit von .NET Framework stammt und nach .NET migriert wurde, wirft im Produktivbetrieb erstmals eine Ausnahme, sobald sie eine Shift_JIS-Datei erhält. Die zu prüfenden Aspekte bei einer Migration sind in der Checkliste vor der Migration von .NET Framework zu .NET zusammengefasst.

Solange Shift_JIS verwendet wird, lassen sich außerdem systemabhängige Zeichen (etwa ① oder ㈱), das Problem der Tilde (Wave Dash) sowie das Fehlen von Zeichen, die es nur in Unicode gibt, nicht vermeiden. Die Grundlagen zur Zeichenkodierung in diesem Bereich werden ausführlich in Zeichenkodierung und Zeichensalat unter Windows und Zeichenkodierung und Zeilenumbruchzeichen unter Windows in der Praxis erläutert.

5. Daten, die beim Öffnen in Excel beschädigt werden ── führende Nullen, Datumswandlung, Exponentialschreibweise

Selbst wenn die Zeichenkodierung korrekt ist, gibt es bei der Betrachtung in Excel eine weitere Gruppe von Problemen: Excel „interpretiert“ die Werte, wenn es eine CSV-Datei öffnet.

Wichtig dabei ist: Auch das Einschließen des Feldes in doppelte Anführungszeichen verhindert dies nicht. Die Anführungszeichen kennzeichnen lediglich die syntaktische Abgrenzung innerhalb von CSV – Excel interpretiert den Inhalt trotzdem erneut.

In der Praxis stehen die folgenden drei Optionen zur Wahl.

1. Die Datei mit dem korrekten Verfahren in Excel öffnen lassen. Statt per Doppelklick, wird die Datei über die Excel-Funktion „Daten abrufen (aus Text/CSV)“ eingelesen und dabei der Spaltentyp auf „Text“ gesetzt – dann gehen keine Daten verloren. Es lohnt sich, dies im Betriebshandbuch zu dokumentieren.
2. Ist die Betrachtung der Hauptzweck, als xlsx ausgeben. Da sich das Zellformat bereits bei der Ausgabe steuern lässt, verschwindet diese ganze Problemgruppe grundsätzlich. Wie man die Ausgabe von Excel-Dateien umsetzt, wird in Erstellung von Excel-Berichtsausgaben beschrieben. Zu beachten ist außerdem, dass die Automatisierung von Excel über COM auf Servern oder in Diensten nicht empfohlen wird, da sie – wie in Das Problem verbleibender EXCEL.EXE-Prozesse beschrieben – ein Nährboden für zurückbleibende Prozesse ist. Wählen Sie stattdessen eine bibliotheksbasierte Ausgabe.
3. Die Ausgabe im Format ="007" ist nur die letzte Notlösung. Dieser Trick sorgt zwar dafür, dass der Wert beim Öffnen in Excel als Text angezeigt wird, macht die Datei als CSV jedoch zu einer „nicht standardkonformen Datei mit eingebetteter Formel“, die andere Importziele außer Excel beschädigt. Verwenden Sie dies nicht bei Dateien, die auch für andere Systeme bestimmt sind.

6. CSV-Injection ── Benutzereingaben dürfen nicht zu Formeln werden

Bei Anwendungen, die von Benutzern eingegebene Werte (Name, Bemerkung, Adresse usw.) in CSV ausgeben und die Datei anschließend in Excel öffnen lassen, existiert ein Angriffsvektor namens CSV-Injection. Da Excel Felder, die mit =, +, - oder @ beginnen, als Formel interpretiert, besteht das Problem darin, dass böswillige Eingaben (etwa eine Formel wie =cmd|'/C calc'!A0, die auf den Start eines externen Prozesses abzielt) in der Umgebung eines anderen Benutzers, der die CSV-Datei öffnet, ausgeführt werden können.

Die grundlegende Gegenmaßnahme besteht darin, gefährliche führende Zeichen bei der Ausgabe zu entschärfen.

// Feldern, die als Formel interpretiert werden könnten, wird ein einfaches Anführungszeichen vorangestellt.
// In japanischen Umgebungen können auch die vollbreiten Zeichen ＝＋－＠ als Formelbeginn interpretiert werden, daher werden sie ebenfalls berücksichtigt
static string SanitizeForExcel(string value)
{
    if (value.Length > 0 && value[0]
        is '=' or '+' or '-' or '@' or '\t' or '\r' or '\n'
        or '＝' or '＋' or '－' or '＠')
    {
        return "'" + value;
    }
    return value;
}

Ein vorangestelltes einfaches Anführungszeichen ist für Excel das Signal, den Wert „als Text zu behandeln“. Da sich die Liste der gefährlichen führenden Zeichen je nach Implementierung und Version der Tabellenkalkulation unterscheiden kann, ist eine solche Entschärfung robuster gegenüber übersehenen Fällen, wenn man sie so gestaltet, dass „nur Werte durchgelassen werden, deren erstes Zeichen auf einer Positivliste (z. B. alphanumerische Zeichen) steht“. Zu beachten ist allerdings, dass beim Import dieser CSV-Datei durch ein anderes System das einfache Anführungszeichen als Bestandteil der Daten erhalten bleibt – es kann daher sinnvoll sein, Dateien „zum Öffnen in Excel“ und „zum Systemimport“ getrennt zu führen. Für das Sicherheitsdesign der gesamten Anwendung – einschließlich der Frage, ob dies mit einer Validierung der Eingabewerte (etwa dem grundsätzlichen Verbot eines führenden =) kombiniert werden sollte – siehe die Minimale Sicherheits-Checkliste für Windows-Anwendungen.

7. Betriebsfallen ── Fehlerquellen jenseits des Formats

Abschließend eine Zusammenfassung der Stellen, an denen in der Praxis abseits der eigentlichen CSV-Syntax Fehler entstehen.

• Zahlen- und Datumsformate nicht von der Kultureinstellung des Betriebssystems abhängig machen. value.ToString() wird von der regionalen Einstellung des Betriebssystems beeinflusst. In Regionen, in denen das Komma als Dezimaltrennzeichen verwendet wird, wird etwa 1,5 ausgegeben, was mit dem CSV-Trennzeichen kollidiert. Geben Sie bei Konvertierungen für die Dateiintegration explizit CultureInfo.InvariantCulture an, und verwenden Sie für Datumsangaben ein festes Format wie yyyy-MM-dd. Das Design von Datumsangaben wird ausführlich in Entwurf von Datum/Uhrzeit und Zeitzonen in Business-Anwendungen behandelt.
• Große Datenmengen per Streaming verarbeiten ── ob dabei „zeilenweise“ ausreicht, hängt jedoch von der Spezifikation ab. File.ReadAllLines lädt alle Zeilen als Array in den Speicher und eignet sich daher nicht für große Dateien. Ein Ersatz durch File.ReadLines (verzögerte Aufzählung) oder eine zeilenweise Lektüre über StreamReader ist jedoch nur bei Dateien zulässig, bei denen die Spezifikation ausdrücklich festlegt, dass Zeilenumbrüche innerhalb eines Feldes nicht erlaubt sind. Bei CSV-Dateien, die RFC 4180 entsprechen und Zeilenumbrüche innerhalb von Anführungszeichen zulassen, zerschneidet eine zeilenweise Aufteilung einen Datensatz mittendrin. In diesem Fall sollte entweder TextFieldParser verwendet werden, der direkt aus dem Dateipfad liest (und dabei nicht die gesamte Datei in den Speicher lädt), oder das Streaming-Einlesen einer CSV-Bibliothek.
• „Noch nicht vollständig geschriebene Dateien“ weder zum Lesen anbieten noch selbst lesen. Die Ausgabeseite schreibt zunächst unter einem temporären Dateinamen und benennt die Datei anschließend um, die Importseite prüft vor dem Lesen, ob eine exklusive Sperre vorliegt – diese Grundform der Dateiintegration wird in Grundlagen der Sperrsteuerung bei der Dateiintegration zusammengefasst; Hinweise für den Import über eine Ordnerüberwachung finden sich im Praxisleitfaden zu FileSystemWatcher.
• Auf Änderungen der Spaltenanzahl vorbereitet sein. Legen Sie in der Spezifikation ausdrücklich fest, ob „die Zuordnung über die Spaltennamen der Kopfzeile“ erfolgt oder ob „die Spaltenreihenfolge fest ist und bei einer abweichenden Spaltenanzahl abgelehnt wird“. Ein impliziter Zugriff über eine magische Zahl wie fields[7] bricht still und leise zusammen, sobald die Gegenseite auch nur unauffällig eine Spalte hinzufügt.
• Den Umgang mit abschließendem Zeilenumbruch und Leerzeilen vorab festlegen. Ob nach der letzten Zeile ein Zeilenumbruch folgt und ob Leerzeilen übersprungen oder abgelehnt werden, sind Punkte, bei denen sich das Verhalten je nach Parser-Implementierung unterscheidet. TextFieldParser überspringt Leerzeilen.

Zusammenfassung

CSV gibt sich als Format, das „nur mit Kommas trennt“, ist in Wirklichkeit aber ein Integrationsformat voller Dialekte. Die vier zentralen Praxispunkte lauten: Beim Einlesen eine Komponente verwenden, die Anführungszeichen korrekt verarbeitet (nicht selbst mit Split bauen); die Zeichenkodierung rückwärts von demjenigen ableiten, der die Datei öffnet (insbesondere Excel), und dabei auch das Vorhandensein eines BOM in der Spezifikation festhalten; wissen, dass sich Excels Werteinterpretation (verlorene Nullen, Datumswandlung) auf CSV-Seite nicht verhindern lässt; und beim Ausgeben von Benutzereingaben einen Schutz gegen Injection einbauen. Allein damit lässt sich der Großteil der Fehler bei der CSV-Integration bereits in der Entwurfsphase vermeiden.

Die Untersuchung von Zeichensalat und Datenbeschädigung bei bestehenden CSV-Integrationen, die Klärung der Integrationsspezifikation mit Legacy-Systemen sowie die Neuimplementierung von CSV-Import-/Exportfunktionen erfordern häufig eine Beurteilung anhand der tatsächlichen Dateien und der Spezifikation der Gegenseite. Zögern Sie daher nicht, uns bei Unsicherheiten zu kontaktieren.

Verwandte Artikel

• Zeichenkodierung und Zeichensalat unter Windows
• Zeichenkodierung und Zeilenumbruchzeichen unter Windows in der Praxis
• Erstellung von Excel-Berichtsausgaben
• Das Problem verbleibender EXCEL.EXE-Prozesse bei Excel-COM-Interop
• Grundlagen der Sperrsteuerung bei der Dateiintegration
• Praxisleitfaden zu FileSystemWatcher
• Entwurf von Datum/Uhrzeit und Zeitzonen in Business-Anwendungen
• Checkliste vor der Migration von .NET Framework zu .NET
• Minimale Sicherheits-Checkliste für Windows-Anwendungen

Verwandte Beratungsbereiche

Komura Soft bietet technische Beratung zur Entwicklung von Business-Anwendungen einschließlich CSV- und Dateiintegration, zur Ursachenanalyse von Zeichensalat und Datenbeschädigung bei bestehenden Integrationen sowie zur Klärung von Integrationsspezifikationen mit Legacy-Systemen.

• Windows-Anwendungsentwicklung
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Welche Zeichenkodierung sollte für CSV verwendet werden?

Der Grundsatz lautet: Wenn die Empfängerseite bereits feststeht, richtet man sich nach deren Spezifikation. Kann die Kodierung neu festgelegt werden, ist ein solider Ausgangspunkt, in der Spezifikation UTF-8 mit BOM für Dateien festzulegen, die von Menschen in Excel geöffnet werden, und UTF-8 ohne BOM für die Integration zwischen Systemen. Wird bei der Anbindung an ein Legacy-System Shift_JIS gefordert, muss der Umgang mit systemabhängigen Zeichen und Sonderzeichen vorab geklärt werden – sonst wird Zeichensalat später zur Verantwortungsfrage.

Sollte man eine CSV-Bibliothek einsetzen oder reicht eine Eigenimplementierung?

Beim Einlesen sollte man auf jeden Fall eine geeignete Komponente verwenden, da ein selbstgebautes String.Split bestimmte Fälle (Kommas, Zeilenumbrüche und Anführungszeichen innerhalb eines Feldes) spezifikationsgemäß nicht korrekt verarbeiten kann. Im Rahmen der .NET-Standardbibliothek unterstützt TextFieldParser eine Anführungszeichenverarbeitung, die RFC 4180 entspricht. Werden zusätzlich Mapping von Spalten auf Objekte, Typkonvertierung und Performance bei großen Datenmengen benötigt, sollte der Einsatz einer bewährten CSV-Bibliothek geprüft werden. Beim Schreiben ist die Spezifikation einfacher, sodass eine Eigenimplementierung durchaus praktikabel ist – dabei sollte jedoch eine gemeinsame Funktion für das Escapen von Anführungszeichen bereitgestellt werden, durch die sämtliche Ausgaben laufen.

Sollte statt Komma als Trennzeichen ein Tabulator (TSV) verwendet werden?

Wenn in den Daten häufig Kommas vorkommen (etwa in Adressen, Namen oder Geldbeträgen), verringert TSV die Häufigkeit der Anführungszeichenbehandlung und erleichtert die visuelle Kontrolle. Allerdings können auch bei TSV Tabulatoren oder Zeilenumbrüche in den Daten vorkommen – die Anführungszeichenverarbeitung wird dadurch nicht überflüssig. Der Trugschluss „Bei TSV muss man sich um das Trennzeichen keine Gedanken machen“ sollte vermieden werden. Lässt sich mit der Gegenstelle eine Einigung erzielen, wirkt sich zur Fehlervermeidung ohnehin weniger die Wahl des Trennzeichens aus als die klare Festlegung von Zeichenkodierung, Anführungszeichen, Zeilenumbruchzeichen und Vorhandensein einer Kopfzeile in der Spezifikation.

Wenn das Ziel ist, die Datei in Excel zu öffnen – sollte man dann statt CSV direkt eine Excel-Datei ausgeben?

Ist der Hauptzweck, dass Menschen die Datei in Excel betrachten oder ausdrucken, lohnt es sich, eine Ausgabe im xlsx-Format zu prüfen. CSV ist ein Format, bei dem in dem Moment, in dem Excel die Datei öffnet, führende Nullen verschwinden oder Werte als Datum interpretiert werden – und es gibt keine Möglichkeit, dies auf CSV-Seite vollständig zu verhindern. Bei xlsx lässt sich das Zellformat dagegen bereits bei der Ausgabe steuern. Ist hingegen der Import in ein anderes System der Hauptzweck und die Betrachtung in Excel nur ein Nebenaspekt, ist es praxisnäher, bei CSV zu bleiben und als Betriebsanleitung das korrekte Importverfahren (Nutzung der Datenimportfunktion) zu kommunizieren.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.