Bash csv mit Trennzeichenproblem

[seraphym]

Hallo allerseits,

folgendes Problem: Ich habe ein csv mit knapp 45.000 Datensätzen.
Die einzelnen Spalten sind eigentlich mit Kommas getrennt. Allerdings gibt es bei zwei Spalten eine Besonderheit: Die Spalte enthält den Vornamen und Nachnamen von Personen, allerdings im Format "Nachname, Vorname".

Im csv sieht das dann so aus:
spalte1,spalte2,"Nachname, Vorname",spalte4,usw

Ich möchte dieses csv mit ein paar Bash-Scripten auswerten. Allerdings machen mir die "-Trennzeichen massive Probleme.
Ein einfaches
grep liste.csv | cut -d, -f4
zum Beispiel liefert natürlich nur Müll. Auch ein
grep liste.csv | awk {$print $4}
bringt auch nur Quatsch.

Hat jemand eine Idee wie das csv sauber formatiert bekomme? Zum Beispiel alle ,-Delimiter durch Semikolons ersetzen (aber was ist mit "Nachname, Vorname")? Schwierig.
Vielleicht stehe ich auch einfach nur auf dem Schlauch.

Grüße,
Sera

 

[DubZ]

Sorry, aber "sauber" ist anders. Ich habe 13 Jahre lang in genau dem Bereich gearbeitet und zich tausende Textdateien (csv ubd alles andere) verarbeitet. Hätte ich solch eine Einstellung an den Tag gelegt, wäre ich vermutlich am 1. Tag fristlos gekündigt worden, das ist nämlich grob fahrlässig.

dann hast du 13 Jahre deinen Job falsch gemacht... zudem weiß ich gar nicht, was du an Yuuris Einstellung zu meckern hast? Er hat in diesem Thread mehrfach den wertvollsten Content geliefert und hat ausgeprägte (echte) Kompetenz in dem Bereich.

Zudem weiß ich gar nicht was du da überhaupt mit "eigenem Parser" kritisierst. Yuuri hat zu Anfang darauf hingewiesen, einen ordentlichen Parser der nach RFC Standard funktioniert zu nehmen.

Was DU hingegen machst, ist das Kundenproblem zu deinem Eigenen werden zu lassen und wenn dann etwas schiefgeht, bist du voll haftbar.

na klar. Todesstrafe... es sollte eine Projektdefinition geben (wenn es diese nicht gibt, hast du direkt noch einen Fehler gemacht). In der steht dann drin, dass man ein valides CSV Format bekommt. Wenn der Kunde keine valide CSV in 2021 liefern kann, na dann.... Ich weiß ja nicht in was für Projekten du gearbeitet hast, das muss aber Jahrzehnte her sein. Heute sollte jedes kommerzielle System auf Knopfdruck valide CSV Daten exportieren können, sofern es eine CSV Export Funktion hat. Oder besser man geht direkt auf XML oder JSON über.

 

[PHuV]

Falls du es nicht kapierst, nochmal explizit für dich:

In CSV kann man mit üblichen Tools die Trenner variabel setzen. Diese Aussage impliziert nicht, dass es geschehen muss oder soll. Wenn ich hier also höre, dass der Trenner durch ein Semikolon ersetzt werden soll, weil jener Trenner auch im Feld vorkommt, rollen sich mir die Fußnägel hoch, weil das

1. vollkommen valides CSV ist
2. eine zwangsweise Manipulation der Daten mit allen möglichen Nebeneffekten bedeutet

Mögen sich Deine Fußnägel ja dabei rollen, daß es ein vaildes CSV ist, besteitet keiner. Es ist aber kein gutes Datenformat, weil dort Zeichen EINDEUTIG sein sollen. Komma ohne Escape als Feld und Spaltentrenner ist Käse. So eine Schweinerei findest Du in keinem seriösen Datenformat. Und in allen anderen Formaten findest Du sehr wohl Escaping und Co. Und wie ich oben bereits zeigte, selbst Excel excapt seine " beim Exportieren.

Deshalb kam ich mit dem Beispiel des Leerzeichens als Trenner um die Absurdität dessen aufzuzeigen. Statt also irgendwas zu ersetzen oder zu escapen oder sonstige Scherzveranstaltungen durchzuführen, habe ich lediglich dafür gestimmt einen ordentlichen CSV-Parser einzusetzen.

Was an der Stelle durchaus legitim ist, aber trotzdem kann man das besser machen.

Nicht mehr, nicht weniger. Auch ein Semikolon ist nicht standardkonform (auch wenn es viele machen), sowie werden Feldbegrenzer nicht durch einen Backslash escaped.

Was bei CSV ein Fehler ist. Und Semicolon ist bei Excel bzw. Windows als Standard gesetzt, beschwere Dich also bitte nicht bei uns dafür.

Mag sein, dass es Implementierungen gibt, der offizielle Standard besagt aber eine andere Verfahrensweise durch die Dopplung des Begrenzers. Ein konformer CSV-Parser kommt aber auch mit Leerzeichen klar und die Erkennung kann auch automatisch erfolgen.

Du beschränkst Dich eben alleine auf CSV. Und CSV ist kein (leider) valides und anerkanntes Standardformat mit einer entsprechenden Norm und Abnahmen dahinter, vergleichbar mit zig anderen Formaten.

Hast du einen Punkt gegen den Einsatz eines CSV-Parsers? Hast du einen Punkt für den Einsatz der Shell mit cut, awk und Co? Regex? Nein?

Ich schon. Für csvtool braucht es Python3. Und in manchen Kundensituationen und -systemen darf man nicht so einfach eine Software installieren, geschweige denn haben die Unix-/Linux-Server einen Internet- oder Repository-Zugang. Zudem ist cut, awk und Co. (was man für bash heute aber wirklich nicht mehr braucht, die bash ist mit den Inline-Funktionen deutlich schneller) sofort auf jedem Unix bzw. Linux-System ohne weitere Anpassungen oder Installationen portabel.

Und dass der TE sowieso keine Kontrolle über den Export hat, hab ich auch erwähnt.

Na ja, wenn man was verbessern kann, sollte man es tun. Fragen kostet ja nichts.

Wichtig ist, das Format zu parsen und nicht die Daten zu interpretieren oder manipulieren.

Ja, aber trotzdem kommt das vielfach vor, daß Dateien vor- oder nachverarbeitet werden müssen. Und wenn hier kein csvtool verwendet werden kann, muß man das an der Stelle so machen.

Wenn der Text den Trenner oder ein Newline enthält. Ganz nach RFC also.

Verstehe ich nicht, sorry, bitte nochmal langsam. Ich starte Excel, neues Blatt, gebe die Felde wie in meine Screenshot so ein, formatiere die Felder als Text. Wie bringe ich nun Excel dazu, " mit , zu schreiben, ich bekomme es nicht hin. Entschuldige bitte, wenn ich hier Excel für mich als CSV Referenz-Generator sehe. Wie Du in meinem Beispiel sehen kannst, führt selbst Excel bei " korrekt ein Excaping mit """ ein.

CSV UTF-8 mit BOM Marker. Und es wird auch wieder ordentlich importiert (wenn man es ordentlich über den Wizard macht). Die Erkennung hat auch problemlos funktioniert, einzig mit der Raute als Trenner gibts wohl irgendein Problem.

Anhang anzeigen 1123654

Du hast doch bereits festgestellt, dass es locale dependent ist...?

Ja. Aber von den normalen Bearbeitern ändert da keiner was. Fast alle verwenden bei CSV über Excel eben den Standard mit ;.

Excel hat ergo überhaupt keinen Standard, sondern richtet sich ausschließlich nach den Systemeinstellungen.

Nope, anscheinend doch, sonst würde es die " nicht escapen.

Aber egal... Das Thema ist durch, der TE hat nun genug Hinweise bekommen. Er nutzt nun erstmal csvtool.

Richtig. Trotzdem hätte ich gerne gewußt, wie man so ein Dateiformat mit Excel hinbekommt.

Siehe Beispiel in Wikipedia https://de.wikipedia.org/wiki/CSV_(Dateiformat)

Stunde,Montag,Dienstag,Mittwoch,Donnerstag,Freitag
1,Mathematik,Deutsch,Englisch,Erdkunde,Politik
2,Sport,Deutsch,Englisch,Sport,Geschichte
3,Sport,"Religion (ev., kath.)",Kunst,,Kunst

Ich bekomme das ohne weiteres korrekt importiert. Sobald aber Excel hier wieder eine CSV-Datei rausschreiben soll, sind die " weg, und ich bekomme sie nicht erzeugt.

Also nochmal die Frage, wie exportierte ich genau das gleiche Format, was ich importierte?

Update: Habs gerafft, man muß Spalten und Feldtrenner gleich haben, dann kommt ein " darum.

 

[DJMadMax]

dann hast du 13 Jahre deinen Job falsch gemacht.

Nü klor, ich hab 13 Jahre lang nur rumgesessen und Däumchen gedreht

zudem weiß ich gar nicht, was du an Yuuris Einstellung zu meckern hast? Er hat in diesem Thread mehrfach den wertvollsten Content geliefert und hat ausgeprägte (echte) Kompetenz in dem Bereich.

Ich habe ihm keinerlei Wissen abgestritten, wohl jedoch deutlich darauf hingewiesen, dass all seine Ansätze eben nicht sauber funktionieren, wenn der Kunde schlechte Daten anliefert.

es sollte eine Projektdefinition geben (wenn es diese nicht gibt, hast du direkt noch einen Fehler gemacht). In der steht dann drin, dass man ein valides CSV Format bekommt. Wenn der Kunde keine valide CSV in 2021 liefern kann, na dann.... Ich weiß ja nicht in was für Projekten du gearbeitet hast, das muss aber Jahrzehnte her sein. Heute sollte jedes kommerzielle System auf Knopfdruck valide CSV Daten exportieren können, sofern es eine CSV Export Funktion hat. Oder besser man geht direkt auf XML oder JSON über.

Du arbeitest generell mit den Daten, die der Kunde dir liefert. Wenn du glaubst, dass Weltkonzerne, selbst mit Namen großer Banken oder gar der BUND selbst in der Lage sei, saubere CSV-Daten zu liefern, hast du dich geschnitten. Aber wie du schon sagtest: scheinbar hab ich die letzten 13 Jahre geschlafen und in deiner Welt mit rosaroter Brille ist alles perfekt und jeder selbst gar nicht vorhandene Delimiter valide

 

[jb_alvarado]

Wie wäre es denn Python statt Bash zu nehmen? Lässt sich doch leichter pflegen, hat gute Parser, läuft überall und hat regex wenn nötig.

 

[sikarr]

Wir verarbeiten oft Personenbezogene Daten wie Personal-,Bau-,Kranken-, usw Akten. Wenn wir die Daten nicht gerade selbst ermitteln bekommen wir vom Kunden eigentlich fast immer eine Stammdatenbank und die ist meist Excel, weil die netten Bürodamen oft nur Excel kennen. Als Übergabe zum Kunden wird eigentlich fast immer CSV oder XML gefordert, und da ist CSV nicht gleich CSV. Jeder Kunde will seine CSV anders haben, richtig absurd wirds erst wenn spezielle Datenformate für das uralte DMS des Kunden gefordert werden.

Ich mache alles was CSV betrifft eigentlich nur mit der Powershell und Escape in CSVs immer und alles. Als gewünschter Trenner kommt fast nur ";" oder "," in seltenen fällen auch mal "|" oder "\t" vor.

Um Excel mach ich bei sowas immer einen Bogen, zu schnell hat man sich da durch die Formatierung ein Datum oder Betrag zerschossen, auch war das Problem das Excel beim csv Export immer in ANSI kodiert hat.

CSV mag kein ideales Format sein aber es wird oft und gerne genutzt.

 

[PHuV]

Wie wäre es denn Python statt Bash zu nehmen? Lässt sich doch leichter pflegen, hat gute Parser, läuft überall und hat regex wenn nötig.

Perl ist da IMHO die bessere Wahl. Damit habe ich die ganzen kruden blöden Datenformate bei einem Kunden korrigiert, die per Oracle SQL Loader SAP-Dateien als CSV und sonstwas aus aller Welt lieferten, auch aus Asien. 😨 UTF-8 mit UFT-16 gemischt, keine BOMs, Zeilentrenner \d \a gemischt in Textfeldern und Co...😱 Ohne Vorverarbeitung ging da nix. Erlaubnis für weitere Tools gabs nicht, aber Perl war intern bereits abgenommen und dürfte dann auf einen Windows-Rechner installiert werden. Das hat die Sache gerettet.

Ergänzung (17. September 2021)

Du arbeitest generell mit den Daten, die der Kunde dir liefert. Wenn du glaubst, dass Weltkonzerne, selbst mit Namen großer Banken oder gar der BUND selbst in der Lage sei, saubere CSV-Daten zu liefern, hast du dich geschnitten.

Ja, und das traurige ist doch, wir haben doch schon seit über 30-40 Jahren zig valide und bessere Datenformate, ich sag nur mal EDI, XML, Fixformate, JSon, YAML, Rest und Co., die normiert sind, standardisiert und eindeutig. Gut, XML ist bei großen Datenmengen bis heute eine .... Herausforderung. Aber selbst CSV wäre ok, wenn sie die Leute vorher Gedanken über diverse Dinge machen und es dann einheitlich machen.

Ergänzung (17. September 2021)

CSV mag kein ideales Format sein aber es wird oft und gerne genutzt.

Dagegen sagt ja keiner was, wenn man sich hier nur an ein paar einfache Grundregeln halten würde.

Aber das ist wie bei allen Standards, Unklarheiten sorgen für Chaos. Was glaubt Ihr, was wir alles als XML-Dateien vorgelegt bekommen hatten, als das W3C die erste Version freigab. Chaos. Und das ist das blöde bei CSV, daß jeder es doch so interpretieren kann, wie er möchte.

 

[DubZ]

ich sag nur mal EDI

bzw. edifact ganz sicher nicht. Nur weil der Standard seit Jahrzehnten existiert..., ich bin ich echt froh, dass neue Standards über XML/JSON kommen wie bspw. zugferd, XRechnung, ... Aber ja, CSV ist und bleibt 2 dimensionaler Mist.

Du arbeitest generell mit den Daten, die der Kunde dir liefert. Wenn du glaubst, dass Weltkonzerne, selbst mit Namen großer Banken oder gar der BUND selbst in der Lage sei, saubere CSV-Daten zu liefern, hast du dich geschnitten. Aber wie du schon sagtest: scheinbar hab ich die letzten 13 Jahre geschlafen und in deiner Welt mit rosaroter Brille ist alles perfekt und jeder selbst gar nicht vorhandene Delimiter valide

ja keine Ahnung. Scheinbar nehmen wir die Dinge unterschiedlich war. Deine Kundenbranche sind auch meine. Aktuell bin ich bei 2 Versicherungen Lösungen am Umsetzen. XML, JSON und CSV kommen zum Einsatz. Bis auf typische anfängliche Abstimmungsprobleme von bspw. Typen im JSON oder generell 5 mal Strukturüberarbeitung mitten im Projekt weil doch etwas vergessen wurde, sind das alles valide Formate die wir geliefert bekommen oder selber erstellen...

 

[PHuV]

bzw. edifact ganz sicher nicht.

Was hast Du gegen Edifact? Funktioniert in einigen Branchen seit Jahrzehnten prima. Gut, man muß sich hier auskennen. Aber mir gings darum, daß man sehr wohl valide und standardisierte Formate erzeugen kann. Edifact hat beispielsweise im Header alle verwendeten Trennzeichen enthalten. Somit kann jeder, auch wenn er diese Trennzeichen nicht kennt, sofort verarbeiten. Gut, er muß dann die Struktur verstehen. 😁
Aber genau das wäre doch eine sinnvolle Erweiterung für CSV, ein Header mit eindeutigen Trennzeichen und Escaping.

Nur weil der Standard seit Jahrzehnten existiert...,

Und eben so seit Jahrzehnten zuverlässig funktioniert.

ich bin ich echt froh, dass neue Standards über XML/JSON kommen wie bspw. zugferd, XRechnung, ...

Reines XML als Datenübertragungformat und Format für Dokumente hat sich leider auch nicht so bewährt, weil es ab gewissen Datenmengen zuviel Overhead generiert, Json ist da schon ein großer Fortschritt.

ja keine Ahnung. Scheinbar nehmen wir die Dinge unterschiedlich war. Deine Kundenbranche sind auch meine. Aktuell bin ich bei 2 Versicherungen Lösungen am Umsetzen. XML, JSON und CSV kommen zum Einsatz. Bis auf typische anfängliche Abstimmungsprobleme von bspw. Typen im JSON oder generell 5 mal Strukturüberarbeitung mitten im Projekt weil doch etwas vergessen wurde, sind das alles valide Formate die wir geliefert bekommen oder selber erstellen...

Sag ich doch, spricht man sich vernünftig hab, ist doch alles ok, und darauf kommt es doch bei jeder Kommunikation, menschlich wie elektronisch an. Und das vermisse ich eben in vielen Projekten. Da wird hirnlos und sinnlos einfach irgend ein Datenbestand rausgedumpt, und die anderen sollen dann irgendwie mit zurecht kommen. Gerade größere marktführende Unternehmen tun sich da seltsamerweise immer wieder schwer und rotzen da förmlich Katalogdaten ohne Sinn und Verstand einfach was raus, was meistens ohne umfangreiche Vor- und nachverarbeitung gar nicht verarbeitet werde kann.

BTW: SQL DDLs gibts ja auch noch, die von vielen Datenbanken entsprechend eingelesen werden können. Und das schöne ist hier, Typbeschreibungen wie Schlüssel der Felder werden gleich mitgeliefert.