Array in csv schreiben

[Sir Rufo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1283507)

Zitat:

Zitat von Sir Rufo (Beitrag 1283498)

Sicher nicht, denn hier wird das

Delphi-Quellcode:

;

als Trennzeichen benötigt

RFC 4180 beschreibt doch COMMA (%x2C) als Trennzeichen zwischen den Feldern, oder?

Das wichtigste an der RFC4180 wird fast immer übersehen

• Quoten beim Delimiter, QuoteChar oder Zeilenende-Zeichen im Feld

Das Trennzeichen ist da eher nebensächlich, es muss nur eindeutig und durchgängig sein (so wie QuoteChar).
Auch wenn eine CSV irgendwie als CommaSeparatedValues zu verstehen ist, erzeugt der TE Dateien mit einem Semikolon. Ist dass dann SSV?

Da CSV eh nur ein Quasi-Standard ohne gültige Definition (RFC 4180 ist quasi ein Vorchlag) kann ich auch behaupten es bedeutet customCharacterSeparatedValues :mrgreen:

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1283510)

Da CSV eh nur ein Quasi-Standard ohne gültige Definition (RFC 4180 ist quasi ein Vorchlag) kann ich auch behaupten es bedeutet customCharacterSeparatedValues :mrgreen:

Auch wenn es eigentlich eindeutig ist (custom), noch mal der Hinweis, je nach Spracheinstellung wählt z.B. Excel mal das Komma, mal das Semikolon als Feldtrenner. Darum vor dem Einlesen, sich immer vergewissern, welche Zeichen genutzt werden. Und falls man eine CSV-Datei versenden will, sich vielleicht vergewissern, daß der Empfänger damit auch umgehen kann.

Gruß
K-H

[Sir Rufo]

Die Wikipedia spricht auch von Character-Separated-Values und eben dass es nicht zwingend ein Komma sein muss.

Ja, es macht sich immer gut, vor einer Kommunikation sich auf einen Sprach-Kontext zu einigen, wie immer der auch aussieht.

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1283579)

je nach Spracheinstellung wählt z.B. Excel mal das Komma, mal das Semikolon als Feldtrenner.

Genauergesagt: Den ListSeparator. Der steht dort zwar drin, ist aber frei wählbar.

Deshalb ist CSV als Datenaustauschformat auch denkbar ungeeignet.

[Blup]

Zitat:

Zitat von Dejan Vu (Beitrag 1283616)

Deshalb ist CSV als Datenaustauschformat auch denkbar ungeeignet.

Ist die Struktur als auch der Inhalt einer CSV-Datei vorher sorgfälltig dokumentiert und danach umgesetzt worden, gibt es in der Praxis eigentlich kaum Probleme.

Mit Exceldateien ist Ärger eher die Regel als die Ausnahme.
- unterschiedlichen Dateiformaten
- OLE-Funktionen die von der Excelversionen abhängig, entgegen der Dokumentation unterschiedlich falsch funktionieren
- Komponenten in Fremdprogrammen die Exceldateien nur lesen können, wenn ein ganz bestimmtes Zellformat verwendet wurde (bei dem einen alles als Text formatiert, der nächste nur ohne Format)

[Dejan Vu]

Zitat:

Zitat von Blup (Beitrag 1283632)

Zitat:

Zitat von Dejan Vu (Beitrag 1283616)

Deshalb ist CSV als Datenaustauschformat auch denkbar ungeeignet.

Ist die Struktur als auch der Inhalt einer CSV-Datei vorher sorgfälltig dokumentiert und danach umgesetzt worden, gibt es in der Praxis eigentlich kaum Probleme.

Ich hätte dazuschreiben müssen: 'International'... "CSV kannste knicken und in die Tonne treten", um es salopp auszudrücken. Zum Austausch von Formaten nimmt man XML und XSD, dann gibt es da gar keine Mißverständnisse mehr.

"Probleme" gibt es auch nicht, wenn ich selbst lese, was ich irgendwo hin schreibe, oder Binärformate nehme (natürlich gut dokumentiert). Aber wozu gibt es wohl Standards? Wenn ich von 'extern' irgendwelche Daten bekommen soll, bestehe ich persönlich auf XML + Schema. Dann validiere ich einkommende Daten gegen das Schema und wenn das passt, passt es. Anders herum validiere ich alles, was rausgeht und wenn das passt, bin ich aus dem Schneider.

PS: CSV ist solcher Müll, das selbst mein SSMS (SQL Management Studio), welches *CSV* exportieren kann, nicht mit EXCEL klar kommt. Beides auf der selben Maschine installiert. Beides von Microsoft. Gleicher Laden, andere Abteilung. Von wegen 'keine Probleme' :-)

[Sir Rufo]

Zitat:

Zitat von Dejan Vu (Beitrag 1283642)

CSV ist solcher Müll, das selbst mein SSMS (SQL Management Studio), welches *CSV* exportieren kann, nicht mit EXCEL klar kommt. Beides auf der selben Maschine installiert. Beides von Microsoft. Gleicher Laden, andere Abteilung. Von wegen 'keine Probleme' :-)

Dabei könnte es so einfach sein einen Dialog davorzuschalten, wo man zumindestens Delimiter und QuoteChar einstellen könnte. Von Zeilenende und Start bei Zeile x würden wir im ersten Step absehen, wir wollen niemanden überfordern, der schon Probleme mit dem Auseinanderhalten von Tablet und Desktop hat :mrgreen:

[Dejan Vu]

Eine Firma bekommt Daten von über 40 Zulieferern natürlich per CSV. Die Firma ist eine Quasibehörde und daher ist diese Vereinbarung taufrisch, aus dem Jahre 1976. Seit 10 Jahren wird erst an der Nachfolgespezifikation gearbeitet, also muss die derzeit gültige taufrische Spezifikation noch einige Jahre halten. Also CSV..

40 Zulieferer. Für jeden Zulieferer einen eigenen Dialog. Speichern der Einstellungen bringt etwas, aber nicht viel, weil die Daten manchmal auch per Dienstleister im Ausland (manuell) erfasst werden. Ja. Elektronisch erfasste Daten werden ausgedruckt, ins A.A.Ausland geschickt, dort eingetippt und dann per CSV an die Quasibehörde geschickt. Per FTP. Mal mit Komma, mal mit Semikolon. Oder als WORD-Datei. Willkürlich formatiert. Oder EXCEL. Mal so, mal so.

Aber manchmal wird -höhöhö- der Ausdruck der vormals elektronisch erfassten Daten auch direkt an die Quasibehörde geschickt. Also ca. 500kg Papier. Die werden dann von eigens eingestellten professionellen Abtippern eingegeben. Zweimal. Weil diese Quasibehörde gibt es zwei Mal. Mmf. Grmpfl.

Ich schweife ab. Ich bin nicht mehr bei dem Verein.

Gott.
Sei.
Dank.

Wo war ich? Ach ja. In der Klapsmühle.

Nee, also in einen Importfilter mal einen Eingabe/Konfigurationsdialog einzubauen. Das hat was. Merke ich mir. :cyclops:

[smallie]

Ich versuche mich kurz zu fassen, weil wir OT sind.

Zitat:

Zitat von Dejan Vu (Beitrag 1283668)

Eine Firma bekommt Daten von über 40 Zulieferern natürlich per CSV.

Das trifft auf uns auch zu. Manche Zulieferer liefern jeweils für vier oder fünf Kunden, so daß am Ende täglich locker hundert Pakete eintreffen, die aus mehreren Dateien bestehen.

Die größeren Datenlieferungen bringen es täglich leicht auf 100 MB. Da purzeln die Gigabytes.

So - jetzt stell dir vor, das seien alles XMLs. Wieviel overhead würde das bedeuten? Mir fehlt die Erfahrung das einzuschätzen - ich tippe auf das fünffache oder zehnfache Volumen. Bitte korrigieren, falls ich daneben liege. In jedem Falle ist das als Kostenfaktor wegen Speicherung und Sicherung nicht zu unterschätzen, zumindest in der Liga, in der wir spielen.

Es gibt noch einen zweiten Aspekt: csv-Dateien harmonieren gut mit relationalen Datenbanktabellen. Mit direct load sind die Daten im Nu in der Datenbank, wenn normalisierte Stammdaten in eigenen Tabellen vorgehalten werden müssen. Erst ein XML zu parsen, nur um es letztlich doch in relationale Tabellen zu stecken, wäre ein unsinniger Aufwand, oder?

Zitat:

Zitat von Dejan Vu (Beitrag 1283668)

40 Zulieferer. Für jeden Zulieferer einen eigenen Dialog. Speichern der Einstellungen bringt etwas, aber nicht viel, weil die Daten manchmal auch per Dienstleister im Ausland (manuell) erfasst werden. Ja. Elektronisch erfasste Daten werden ausgedruckt, ins A.A.Ausland geschickt, dort eingetippt und dann per CSV an die Quasibehörde geschickt. Per FTP. Mal mit Komma, mal mit Semikolon. Oder als WORD-Datei. Willkürlich formatiert. Oder EXCEL. Mal so, mal so.

Naja. Das ist kein Problem, das der csv-Datei angelastet werden kann. Hier hapert es an der Organisation. Andersherum gesagt: traust die Leuten, die kein wohlgeformtes csv zu Wege bringen zu, daß sie gültige XMLs liefern?

Zitat:

Zitat von Dejan Vu (Beitrag 1283668)

Aber manchmal wird -höhöhö- der Ausdruck der vormals elektronisch erfassten Daten auch direkt an die Quasibehörde geschickt. Also ca. 500kg Papier. Die werden dann von eigens eingestellten professionellen Abtippern eingegeben. Zweimal. Weil diese Quasibehörde gibt es zwei Mal. Mmf. Grmpfl.

Ich hab' mich schon mehrmals gefragt, warum es hier im Forum keinen daily-WTF-Thread gibt. :stupid: Das wäre ein schöner Startbeitrag.

Zitat:

Zitat von Dejan Vu (Beitrag 1283668)

Nee, also in einen Importfilter mal einen Eingabe/Konfigurationsdialog einzubauen. Das hat was. Merke ich mir. :cyclops:

So etwas baue ich gerade. Ich sollte das mal vorstellen. Zu einem bestimmten Ansatz käme mir Manöverkritik ganz gelegen, bevor ich das festzurre.

[Dejan Vu]

Overhead? Das ist doch vollkommen egal. (Validiertes) XML ist weltweit identisch. Du kannst kein wohlgeformtes und validiertes XML bekommen, was Dir plötzlich Probleme macht. Wohl aber eine vollkommen zerschurbelte CSV-Datei.
Speicherplatz? Zip das Zeugs.

Zitat:

Zitat von smallie (Beitrag 1283677)

Es gibt noch einen zweiten Aspekt: csv-Dateien harmonieren gut mit relationalen Datenbanktabellen. Mit direct load sind die Daten im Nu in der Datenbank

Genau, weil es ja nur ein Format gibt und einen Trenner...

Zitat:

Andersherum gesagt: traust die Leuten, die kein wohlgeformtes csv zu Wege bringen zu, daß sie gültige XMLs liefern?

Es gibt kein 'wohlgeformtes CSV'. Es gibt wohlgeformtes XML (was mir auch egal wäre) und es gibt validiertes XML (gegen ein Schema).

Wenn deine Zulieferer alle mitspielen und wissen, was sie tun, können sie auch proprietäres Binärformat schicken. Jetzt schicken sie ein proprietäres Text-Format, aber wenigstens spielen sie mit.

PS: XML in einen Server geht genauso schnell und das Aufdröseln in Tabellen auch. Sind halt ein paar Zeilen mehr. Einmalig.

Aber jedem das Seine. CSV hat jedenfalls imho in der professionellen Softwareentwicklung und im Datenaustausch, der etwas auf sich hält, nichts verloren. Das ist nicht abwertend, sondern in meinem Umfeld so.