CSV-Formatfehler: Ungeschützte doppelte Anführungszeichen in Haltestellen-Name

[hbruch]

Die zHV-csv-Datei verwendet als Feldbegrenzer doppelte Anführungszeichen ("). Einzelne Namen beinhalten doppelte Anführungszeichen als Teil des Namens. Diese werden nicht geschützt und führen zu einer invaliden CSV-Struktur, welche je nach Werkzeug zu Verarbeitungsfehlern führt.

Beispiel:

"19727";"A";"de:08119:7601:94";"de:08119:7601";"Zug. "Zum Bf."";"48,92598";"9,419896";"00000000";"-";"-";"-";"Unserved";"InOrder";"";"NVBW";"-";"-";"-"

Üblicherweise werden doppelte Anführungszeichen innerhalb von Textfelder durch ein jeweils vorangestelltes doppeltes Anführungszeichen geschützt:

Beispiel:

"19727";"A";"de:08119:7601:94";"de:08119:7601";"Zug. ""Zum Bf.""";"48,92598";"9,419896";"00000000";"-";"-";"-";"Unserved";"InOrder";"";"NVBW";"-";"-";"-"

[CM-RMS]

Ich hatte diese Anfrage schon einmal an die zuständigen Ansprechpartner bei der WVI angesprochen und diese Antwort bekommen: "Wir verwenden beim Export das Anführungszeichen zwar anders, als von dem Anfragenden erwartet, verstoßen damit jedoch nicht gegen irgendwelche Standards und auch beispielsweise das Semikolon als Feld-Trennzeichen und nicht das Komma. Es wäre natürlich dennoch möglich, künftig das Exportformat auf die vom Anfragenden gewünschte Variante umzustellen. Dies würde andererseits aber Anpassungsaufwand bei all denjenigen verursachen, die sich schon Routinen zur automatischen Verarbeitung von ZHV-Exporten gebaut haben. Insofern empfehlen wir, bei dem aktuellen Format zu bleiben."

[hbruch]

Der Aussage "wir verstoßen nicht gegen irgendwelche Standards" kann ich nicht zustimmen. Es existieren durchaus etablierte Konventionen, um eine fehlerfreie Verarbeitung von CSV-Daten zu ermöglichen.

Bezüglich Maskierung von doppelten Anführungszeichen siehe hierzu z.B.:

RFC 4180 Common Format and MIME Type for CSV Files:

...

7. If double-quotes are used to enclose fields, then a double-quote appearing inside a field must be escaped by preceding it with another double quote. For example:

   "aaa","b""bb","ccc"

oder auf Deutsch z.B. wikipedia:

Um Sonderzeichen innerhalb der Daten nutzen zu können (z. B. Komma in Dezimalzahlwerten), wird ein Feldbegrenzerzeichen (auch: Textbegrenzungszeichen) benutzt. Normalerweise ist dieser Feldbegrenzer das Anführungszeichen ". Wenn der Feldbegrenzer selbst in den Daten enthalten ist, wird dieser im Datenfeld verdoppelt (siehe Maskierungszeichen).

Dieses Maskierungszeichen wird von üblicherweise genutzten CSV-Import-Routinen erkannt und erzeugt keinen Anpassungsaufwand. Datenabnehmer hingegen würden sich die derzeit erforderliche Präprozessierung zur Fehlerkorrektur des Formats sparen. Die derzeit fehlende Maskierung erfordert eine Spezialimplementierung des Parsings welche zudem fehleranfällig ist.

Sollte WVI Standard-Bibliotheken zum CSV-Export nutzen, dürften diese i.d.R. automatisch die korrekte Maskierung vornehmen.

Das Semikolon als Feldtrennzeichen haben wir nicht in Frage gestellt.

[dancesWithCycles]

Hallo liebe Leute, Der aktuelle Export ```zHV_aktuell_csv.2023-05-08.csv enthaelt wieder unmaskierte doppelte Anfuehrungszeichen.

"673665";"Q";"de:05974:35188:0:1";"de:05974:35188";"1";"51,634632";"8,521203";"00000000";"-";"-";"-";"Unknown";"Unknown";"Geseke, H"lter Weg";"VRR";"-";"-";"-"
"673666";"Q";"de:05974:35188:0:2";"de:05974:35188";"2";"51,634504";"8,521455";"00000000";"-";"-";"-";"Unknown";"Unknown";"Geseke, H"lter Weg";"VRR";"-";"-";"-"

In diesem Fall

"Geseke, H"lter Weg"

handelt es sich um ein einzelnes Zeichen und kein Zeichen-Paar. Ein einzelnes unmaskiertes Zeichen resultiert, bei der automatischen Verarbeitung von CSV-Dateinen, wegen fehlender Kompatibilitaet ebenfalls zu Fehlern.

ERROR:  unterminated CSV quoted field
CONTEXT:  COPY stops, line 849353: ""673666";"Q";"de:05974:35188:0:2";"de:05974:35188";"2";"51,634504";"8,521455";"00000000";"-";"-";"-"..."

Besitzt jemand einen alten Export, welcher mit dem aktuellen vom 8. Mai 2023 verglichen werden kann? Dann wissen wir, ob es sich um einen neuen Fehler handelt. Ausserdem, haette ich gerne einen funktionierenden, weil kompatiblen, Export.

[CM-RMS]

Hallo, das ist schon so im ZHV hinterlegt: Geseke, H"lter Weg Wir werden das zuständige VU informieren und um Korrektur bitten.

[hbruch]

Ich wiedehole nochmal die Bitte, ein sauberes Escaping auf Seite des zHV vorzusehen, damit Fehler des VUs nicht die Datei unverarbeitbar machen. Es sind genau solche Fehler, die vermeidbar wären.

[dancesWithCycles]

Hallo liebe Leute, Der aktuelle Export ```zHV_aktuell_csv.2023-05-08.csv enthaelt ein weiteres unmaskiertes doppeltes Anfuehrungszeichen.

"599278";"Q";"de:05566:35125:0:1";"de:05566:35125";"1";"52,126149";"7,328357";"00000000";"-";"-";"-";"Unknown";"Unknown";"Burgsteinfurt, Hof K"ninck";"VRR";"-";"-";"-"

Haltestelle "Burgsteinfurt, Hof K"ninck" soll vermutlich Könick heissen.

@CM-RMS Ist fuer diesen Halt das selbe Verkehrsunternehmen verantwortlich wie fuer Geseke, H"lter Weg?

[dancesWithCycles]

Neuer Datensatz, neues Glueck?

Der aktuelle Export zHV_aktuell_csv.2023-05-15.csv enthaelt die folgenden unmaskierten doppelten Anfuehrungszeichen.

"673712";"Q";"de:05974:35188:0:2";"de:05974:35188";"2";"51,634504";"8,521455";"00000000";"-";"-";"-";"Unknown";"Unknown";"Geseke, H"lter Weg";"VRR";"-";"-";"-"

Haltestelle "Geseke, H"lter Weg" soll vermutlich Geseke, Hölter Weg heissen.

[CM-RMS]

Das Problem wurde dem VRR mitgeteilt und es wird korrigiert. Wir haben aber keinen Einfluss darauf wann der VRR neue und korrigierte Daten als ZHV liefert.

[CM-RMS]

"ans"

[derhuerst]

Ist bereits geplant, auf ein RFC-4180-kompatibles CSV-Encoding umzusteigen, also Anführungszeichen in Zellen zu schützen? Dies würde in Zukunft weitere Fälle verhindern, bei denen ungewöhnlich oder falsch benannte Stationen den zHV-Datensatz (maschinell) unverarbeitbar machen.

[leonardehrenfried]

Ich habe heute das zHV CSV verarbeiten wollen und bin in das selbe Problem gelaufen. Das Escaping von Anführungszeichen ist immer noch falsch.

[CM-RMS]

Wenn Sie uns eine Lister der betroffenen Haltestellen zukommen lassen geben wir das gerne an die zuständigen VU's zur Prüfung weiter.

[leonardehrenfried]

Das Problem tritt zwar nur bei einer kleinen Anzahlt von Haltestellen auf, nämlich denen, die ein Anfführungszeichen im Namen haben, die Lösung sollte allerdings nicht sein, dass die Datenlieferanten die Anführungszeichen entfernen.

Es sollte die Aufgabe von WVI sein, die Anführungszeichen, die die Verbünde zuliefern, zu maskieren, also aus einem " ein \" zu machen. Dafür gibt es sehr viele Bibliotheken für alle mir bekannten Programmiersprachen, die dies automatisch tun, ohne dass die Entwicklerin darüber nachdenken muss.

[CM-RMS]

Ich habe es an die WVI weitergegeben.

[CM-RMS]

Durch eine Programmierung der WVI sollte das Problem nicht mehr vorhanden sein

[leonardehrenfried]

Das sind super Neuigkeiten!

[derhuerst]

Leider erfüllt der neueste Datensatz immer noch nicht RFC 4180, weil \" als Escaping-Mechanismus genutzt wird:

7. If double-quotes are used to enclose fields, then a double-quote appearing inside a field must be escaped by preceding it with another double quote. For example:

   "aaa","b""bb","ccc"

Das lässt sich in vielen CSV-Bibliotheken zwar konfigurieren, aber deutlich besser wäre das Escaping mit doppelten (bzw. mehrfachen) Anführungszeichen! Könnt ihr das noch ändern @CM-RMS? Danke!

---

rg -i 'zum bf' zHV_aktuell_csv.2023-08-14.csv
# 19887:"19885";"A";"de:08119:7601:94";"de:08119:7601";"Zug. \"Zum Bf.\"";"48,92598";"9,419896";"00000000";"-";"-";"-";"";"NVBW";"-";"-";"-";"1999-12-31T00:00:00"
# …

[CM-RMS]

Die WVI wird momentan keine neuen Änderungen vornehmen. Sollten allgm. Änderungen an der Schnittstelle bzw. zur Bereitstellung von csv-Dateien erfolgen, wird WVI diesen Sachverhalt noch einmal prüfen und ggf. anpassen. Aktuell sind nur etwa 30 Haltestellenobjekte im ZHV davon betroffen.