Zusammenfassung

Das Comma Separated Values (CSV)-Dateiformat ist das gebräuchlichste Import- und Exportformat für Tabellenkalkulationen und Datenbanken. Obwohl viele CSV-Dateien einfach zu parsen sind, ist das Format nicht formal durch eine stabile Spezifikation definiert und ist subtil genug, dass das Parsen von Zeilen einer CSV-Datei mit etwas wie line.split(",") letztendlich fehlschlagen wird. Dieses PEP definiert eine API für das Lesen und Schreiben von CSV-Dateien. Es wird von einem entsprechenden Modul begleitet, das die API implementiert.

To Do (Hinweise für Interessierte und Ehrgeizige)

• Bessere Motivation für die Wahl, ein Dateiobjekt an die Konstruktoren zu übergeben. Siehe https://mail.python.org/pipermail/csv/2003-January/000179.html
• Unicode. Igitt.

Anwendungsbereich

Dieses PEP befasst sich mit einer Sache, die es gut machen soll: dem Parsen tabellarischer Daten, die verschiedene Feldtrenner, Anführungszeichen, Escape-Mechanismen für Anführungszeichen und Zeilenenden verwenden können. Die Autoren beabsichtigen, dass das vorgeschlagene Modul dieses eine Parsing-Problem effizient löst. Die Autoren beabsichtigen nicht, einige dieser verwandten Themen anzugehen

• Dateninterpretation (soll ein Feld, das den String „10“ enthält, ein String, ein Float oder ein Integer sein? Ist es eine Zahl in Basis 10, Basis 16 oder Basis 2? Sind Zahlen in Anführungszeichen Zahlen oder Strings?)
• lokale Datendarstellung (soll die Zahl 1.23 als „1.23“ oder „1,23“ oder „1 23“ geschrieben werden?) – dies könnte eventuell angegangen werden.
• feste breite tabellarische Daten – können bereits zuverlässig geparst werden.

Begründung

Oft sind CSV-Dateien so einfach formatiert, dass Sie sie zeilenweise lesen und auf den Kommas aufteilen können, die die Felder trennen. Dies gilt insbesondere, wenn alle gelesenen Daten numerisch sind. Dieser Ansatz funktioniert vielleicht eine Weile, schlägt dann aber fehl, wenn jemand etwas Unerwartetes in die Daten einfügt, wie z. B. ein Komma. Wenn Sie sich mit dem Problem befassen, kommen Sie möglicherweise zu dem Schluss, dass Sie das Problem mit regulären Ausdrücken lösen können. Dies funktioniert eine Weile und bricht dann eines Tages auf mysteriöse Weise. Das Problem wächst, also graben Sie tiefer und erkennen schließlich, dass Sie einen speziell angefertigten Parser für das Format benötigen.

CSV-Formate sind nicht gut definiert und verschiedene Implementierungen haben eine Reihe subtiler Sonderfälle. Es wurde vorgeschlagen, dass das „V“ in dem Akronym für „Vague“ (vage) statt für „Values“ (Werte) steht. Unterschiedliche Trennzeichen und Anführungszeichen sind nur der Anfang. Einige Programme generieren nach jedem Trennzeichen Leerzeichen, die nicht Teil des folgenden Feldes sind. Andere setzen Anführungszeichen um eingebettete Anführungszeichen, indem sie sie verdoppeln, andere, indem sie ihnen ein Escape-Zeichen voranstellen. Die Liste der seltsamen Vorgehensweisen kann endlos erscheinen.

All diese Variabilität bedeutet, dass es für Programmierer schwierig ist, CSV-Dateien aus vielen Quellen zuverlässig zu parsen oder CSV-Dateien zu generieren, die für die Eingabe in bestimmte externe Programme bestimmt sind, ohne ein gründliches Verständnis dieser Quellen und Programme. Dieses PEP und die begleitende Software versuchen, den Prozess weniger fehleranfällig zu machen.

Bestehende Module

Dieses Problem wurde bereits angegangen. Mindestens drei Module, die derzeit in der Python-Community verfügbar sind, ermöglichen Programmierern das Lesen und Schreiben von CSV-Dateien

• Object Crafts CSV-Modul [2]
• Cliff Wells Python-DSV-Modul [3]
• Laurence Tratts ASV-Modul [4]

Jedes hat eine andere API, was es für Programmierer etwas schwierig macht, zwischen ihnen zu wechseln. Ein größeres Problem mag sein, dass sie einige der CSV-Sonderfälle unterschiedlich interpretieren, so dass der Programmierer, selbst nachdem er die Unterschiede zwischen den verschiedenen Modul-APIs überwunden hat, auch mit semantischen Unterschieden zwischen den Paketen umgehen muss.

Modulschnittstelle

Dieses PEP unterstützt drei grundlegende APIs: eine zum Lesen und Parsen von CSV-Dateien, eine zum Schreiben und eine zum Identifizieren verschiedener CSV-Dialekte für die Reader und Writer.

obj = reader(iterable [, dialect='excel']
             [optional keyword args])

csvreader = csv.reader(file("some.csv"))
for row in csvreader:
    process(row)

obj = writer(fileobj [, dialect='excel'],
             [optional keyword args])

csvwriter = csv.writer(file("some.csv", "w"))
for row in someiterable:
    csvwriter.writerow(row)

csvwriter = csv.writer(file("some.csv", "w"), fieldnames=names)
csvwriter.write(names)
for row in someiterable:
    csvwriter.write(row)

class Dialect:
    # placeholders
    delimiter = None
    quotechar = None
    escapechar = None
    doublequote = None
    skipinitialspace = None
    lineterminator = None
    quoting = None

class excel(Dialect):
    delimiter = ','
    quotechar = '"'
    doublequote = True
    skipinitialspace = False
    lineterminator = '\r\n'
    quoting = QUOTE_MINIMAL

class exceltsv(excel):
    delimiter = '\t'

dialect = get_dialect(name)
names = list_dialects()
register_dialect(name, dialect)
unregister_dialect(name)

csvreader = csv.reader(file("some.csv"), dialect="excel",
                       quotechar="'", delimiter=':')

Implementierung

Es gibt eine Beispielimplementierung. [1] Ziel ist es, die im PEP beschriebene API effizient zu implementieren. Sie basiert stark auf dem Object Craft csv-Modul. [2]

Testen

Die Beispielimplementierung [1] enthält einen Satz von Testfällen.

Probleme

1. Soll ein Parameter steuern, wie aufeinanderfolgende Trennzeichen interpretiert werden? Unser Gedanke ist „nein“. Aufeinanderfolgende Trennzeichen sollten immer ein leeres Feld bedeuten.
2. Was ist mit Unicode? Reicht es aus, ein Dateiobjekt zu übergeben, das von codecs.open() erhalten wurde? Zum Beispiel

   csvreader = csv.reader(codecs.open("some.csv", "r", "cp1252"))
   
   csvwriter = csv.writer(codecs.open("some.csv", "w", "utf-8"))
   

   Im ersten Beispiel wird angenommen, dass Text als cp1252 kodiert ist. Soll das System aggressiv in die Umwandlung in Unicode konvertieren oder sollen Unicode-Strings nur zurückgegeben werden, wenn nötig?

   Im zweiten Beispiel kümmert sich die Datei automatisch um die Kodierung von Unicode-Strings als utf-8, bevor sie auf die Festplatte geschrieben werden.

   Hinweis: Zum Zeitpunkt der Erstellung dieses Dokuments verarbeitet das csv-Modul keine Unicode-Daten.

3. Was ist mit alternativen Escape-Konventionen? Wenn der verwendete Dialekt einen escapechar-Parameter enthält, der nicht None ist, und der quoting-Parameter auf QUOTE_NONE gesetzt ist, werden Trennzeichen, die innerhalb von Feldern vorkommen, beim Schreiben mit dem Escape-Zeichen vorangestellt und sollen beim Lesen mit dem Escape-Zeichen vorangestellt werden.
4. Soll es einen Modus zum „vollständigen Anführungszeichen setzen“ für das Schreiben geben? Was ist mit „vollständiges Anführungszeichen setzen, außer für numerische Werte“? Beide sind implementiert (QUOTE_ALL bzw. QUOTE_NONNUMERIC).
5. Was ist mit Zeilenende? Wenn ich eine CSV-Datei unter einem Unix-System generiere, erkennt Excel dann die nur LF enthaltenden Zeilenabschlüsse korrekt? Dateien müssen zum Lesen oder Schreiben entsprechend im Binärmodus geöffnet werden. Geben Sie die lineterminator-Sequenz als '\r\n' an. Die resultierende Datei wird korrekt geschrieben.
6. Gibt es eine Option, um Dictionaries aus dem Reader zu generieren und Dictionaries vom Writer zu akzeptieren? Siehe die Klassen DictReader und DictWriter in csv.py.
7. Sind Anführungszeichen und Trennzeichen auf einzelne Zeichen beschränkt? Vorerst ja.
8. Wie sollen Zeilen unterschiedlicher Länge behandelt werden? Die Interpretation der Daten ist Aufgabe der Anwendung. Auf dieser Ebene gibt es keine „kurze Zeile“ oder „lange Zeile“.

Referenzen

Es gibt viele Verweise auf andere CSV-bezogene Projekte im Web. Einige sind hier aufgeführt.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.