CSV-Dateien

de-users
#1

Entschuldigung, das war ein Duckfehler, sollte natürlich Cvv-Dateien heißen und nicht vsv-dateie, sons läge die Verwechesung mit WSV (Winterschlußverkauf zu nah.
Viele Grüße Udo

#2

Hallo Udo,

Entschuldigung, das war ein Duckfehler, sollte natürlich Cvv-Dateien
heißen und nicht vsv-dateie, sons läge die Verwechesung mit WSV
(Winterschlußverkauf zu nah.

Und damit das nicht schon wieder falsch wird:

comma-separated values wird zu csv.

Das ist ein Tabellenformat, das Du auch mit einem einfachen Textprogramm
erstellen und öffnen kannst. Müsste bei Windows also auch mit dem Editor
(oder wie das Ding heißt) gehen. Die Werte einer Spalte sind, wie der
Name sagt, in der Regel durch Kommata getrennt. Textinhalte sind dabei
in doppelte Anführungszeichen gesetzt. Eine Tabelle sieht dann ungefähr
so aus:

#3

Hallo Robert,

und außerdem fehlt natürlich der "€".

Vielleicht unter Windows. Unter Linux habe ich dieses Zeichen sehr
wohl in der CSV-Datei abspeichern können. Und deshalb kann ich mir
nur schwerlich vorstellen das es unter Windows nicht gehen soll.

Anderseit ist auf meiner Linux-Büchse "Utf-8" als Standard
eingestellt und vielleicht liegt es ja daran.

Gruß Achim

#4

Hallo Achim,

und außerdem fehlt natürlich der "€".

Vielleicht unter Windows. Unter Linux habe ich dieses Zeichen sehr
wohl in der CSV-Datei abspeichern können. Und deshalb kann ich mir
nur schwerlich vorstellen das es unter Windows nicht gehen soll.

Anderseit ist auf meiner Linux-Büchse "Utf-8" als Standard
eingestellt und vielleicht liegt es ja daran.

Ich meine schon Linux (Windows habe ich nicht ...). Mit dem €-Zeichen
kombiniert kannst Du nur Text abspeichern. Wenn Du z.B. in einer
Datenbank anschließend damit rechnen möchtest klappt das nicht.
Um das an dem Beipiel deutlich zu machen:
--- ohne € ---
"Bleistift",1,0.25
--- mit € ---
"Bleistift",1,"0,25 €"

Der Import zurück nach Calc scheint davon nicht berührt zu sein, wenn
die erweiterte Zahlenerkennung eingeschaltet ist. Ansonsten wird aus
0,25 € ein Text.
Der Export nach *.csv scheint übrigens nicht gerade fehlerfrei zu
gelingen. Mache ich das mehrere Male hintereinander mit der gleichen
Datei (Exportieren - Einlesen - Exportieren), dann trennt LO-Calc
Dezimalzahlen nach dem Komma in 2 Spalten und und macht außerdem aus
0,25 € noch 0 in der einen Spalte und 25 € in der nächsten Spalte. Habe
das gerade einmal mit der LO 4.1.1.2 von OpenSUSE getestet. Das werde
ich mir jetzt noch einmal genauer anschauen.

Gruß

Robert

#5

Hallo Robert,

Der Export nach *.csv scheint übrigens nicht gerade fehlerfrei zu
gelingen. Mache ich das mehrere Male hintereinander mit der
gleichen Datei (Exportieren - Einlesen - Exportieren) ...

Ist "csv" nicht als Export vorgesehen? Ständiges ein- und Auslesen
sollte natürlich mit / über die LO-Standard-Datei "ods" geschehen,
nicht jedoch in Fremdformate.

Wenn Du z.B. in einer Datenbank anschließend damit rechnen
möchtest klappt das nicht.

BEVOR ich exportiere muss ich mir Gedanken machen wie der
Import in der anderen Applikation am besten einfachsten ist: Mit
oder ohne irgendwelchen "Format-Schnick-Schnack" wie z.B. dem "€"-
Zeichen.

Für meine Zwecke (z.B.) habe ich mir ein Makro erstellt und hinter
einem Button gelegt, dass zuerst in CSV exportiert, dann direkt
erneut in ODS gespeichert.
Die (neue) CVS Datei wird von mir in Perl eingelesen, die Daten
ausgewertet, verarbeitet (z.B. rechenen...) und v.m.
Verläuft alles problemlos !

Wo siehst Du das Problem?

Gruß Achim

#6

Hallo Achim,

Der Export nach *.csv scheint übrigens nicht gerade fehlerfrei zu
gelingen. Mache ich das mehrere Male hintereinander mit der
gleichen Datei (Exportieren - Einlesen - Exportieren) ...

Ist "csv" nicht als Export vorgesehen? Ständiges ein- und Auslesen
sollte natürlich mit / über die LO-Standard-Datei "ods" geschehen,
nicht jedoch in Fremdformate.

Wenn ich *.csv-Dateien nutze, dann nutze ich die zum Datenaustausch. Für
*.csv-Dateien gibt es da lediglich ein paar Grundregeln.
Ich habe die Erwartungshaltung, dass vielleicht Daten später fehlen -
vor allem natürlich Formate. Ich habe aber nicht die Erwartung, dass
Daten nach einem Export und einem erneuten Import nur noch mit
entsprechenden Filtereingriffen nutzbar werden.

Wenn Du z.B. in einer Datenbank anschließend damit rechnen
möchtest klappt das nicht.

BEVOR ich exportiere muss ich mir Gedanken machen wie der
Import in der anderen Applikation am besten einfachsten ist: Mit
oder ohne irgendwelchen "Format-Schnick-Schnack" wie z.B. dem "€"-
Zeichen.

Klar. Deshalb sollte aber auch ein Dezimalkomma beim Speichern in einen
Punkt umgewandelt werden. Das geschieht bei LO offensichtlich auch
nicht. Es behandelt Dezimalzahlen als Text.

Für meine Zwecke (z.B.) habe ich mir ein Makro erstellt und hinter
einem Button gelegt, dass zuerst in CSV exportiert, dann direkt
erneut in ODS gespeichert.

Die (neue) CVS Datei wird von mir in Perl eingelesen, die Daten
ausgewertet, verarbeitet (z.B. rechenen...) und v.m.
Verläuft alles problemlos !

Natürlich kann ich mir ein Makro schreiben, dass eine einmal exportierte
Datei entsprechend in ein anderes Programm importiert (habe das für Base
gemacht, auch über PHP in eine MySQL-Datenbank realisiert) - aber das
ist für mich nicht der Punkt.
Der ursprüngliche Thread geht über "CSV-erstellen-speichern-laden" und
das mit einfachen Mitteln direkt aus Calc heraus. Und da baut Calc im
Moment einen Bock rein, sobald eine Dezimalzahl auftaucht.

Die erste Abspeicherung macht aus Dezimalzahlen und Währungen jeweils
Text, da das Ganze ja Kommas enthält. Die erste Abspeicherung verwendet
auch das Komma als Trennung.
Rufe ich die Datei wieder auf, dann gelingt das. Speichere ich sie
erneut (unter anderem Namen) ab, dann wählt Calc den Tabulator als
Trennung. Jetzt muss ich beim erneuten Import das Komma abwählen, da
sonst die Dezimalzahlen in verschiedene Felder gesplittet werden - es
existieren nämlich auch keine doppelten Anführungsstriche mehr, weil
Calc die grundsätzlich um Text herum weg lässt ...

Die Vorgehensweise von Calc mit dem Speichern und Einlesen von
*.csv-Dateien ist für mich so nur noch verwirrend.

Gruß

Robert

#7

Hallo Robert, Achim, *

>
>> Der Export nach *.csv scheint übrigens nicht gerade fehlerfrei zu
>> gelingen. Mache ich das mehrere Male hintereinander mit der
>> gleichen Datei (Exportieren - Einlesen - Exportieren) ...
>
> Ist "csv" nicht als Export vorgesehen? Ständiges ein- und Auslesen
> sollte natürlich mit / über die LO-Standard-Datei "ods" geschehen,
> nicht jedoch in Fremdformate.

Wenn ich *.csv-Dateien nutze, dann nutze ich die zum Datenaustausch.
Für *.csv-Dateien gibt es da lediglich ein paar Grundregeln.
Ich habe die Erwartungshaltung, dass vielleicht Daten später fehlen -
vor allem natürlich Formate. Ich habe aber nicht die Erwartung, dass
Daten nach einem Export und einem erneuten Import nur noch mit
entsprechenden Filtereingriffen nutzbar werden.

CSV-Dateien sind zwar sehr nützlich, aber ohne genaue "Absprache" nur
eine "Krücke.

Das fängt damit an, dass es eigentlich 3 Formate gab: CSV, SSV, TSV.
Sollen heißen: Comma/Semicolon/Tab-Separated-Value, also Werte mit
Komma-, Semikolon- oder Tabulator-Trennung.

Gerade da das Komma oft auch als Trennzeichen in z.B. Zahlen auftaucht,
verwendet man oft das Semikolon als Trennzeichen. Um auch das Semikolon
innerhalb eines Datenfeldes nutzbar zu machen, nimmt man auch gerne
das Tabulator-"zeichen".

Dann gibt immer noch Variationen: Datums/zeit-Angaben können in jedem
beliebigen lokalen Format vorliegen. Das gilt auch für Zahlenformate.

Und zuletzt kann es sein, dass einzelne Werte mit einer "Klammer"
versehen sind. Entweder um das Trennzeichen zu schützen

  "Schmidt, Herr","Frankfurt"

oder um bestimmte Werte explizit als Text zu kennzeichnen:
z.B. die Vorwahl "04321" im Gegensatz zur zahl 4321.

Wenn man sich den Import-Dialog für Textdateien anschaut, dann bekommt
man einen Eindruck von den ganzen Möglichkeiten.

Beim "speichern unter" kann man einige dieser Möglichkeiten gezielt
wählen, wenn man "Filtereinstellungen bearbeiten" anhakt.

Wenn man häufiger mit CSV-Dateien zu tun hat, sollte man ggf. einen
gemeinsamen Standard verabreden, sonst ist die Handarbeit im
Import-Dialog unvermeidbar.

Gruß,
Michael

#8

Hallo Michael,

Wenn man sich den Import-Dialog für Textdateien anschaut, dann bekommt
man einen Eindruck von den ganzen Möglichkeiten.

Beim "speichern unter" kann man einige dieser Möglichkeiten gezielt
wählen, wenn man "Filtereinstellungen bearbeiten" anhakt.

Hast Du eine Ahnung, ob man die dort gewählten Einstellungen irgendwie
irgendwo so "festnageln", abspeichern kann, dass sie beim nächsten
CSV-Speichern wieder genau so als Voreinstellung kommen und man nicht
jedesmal die gleiche Umstellung vornehmen muss?

Michael

.... und tschüss

            Franklin

#9

Hallo Michael, *

das für mich, der es selten nutzt, Lustige ist ja, dass LO beim ersten
einfachen Export um Dezimalzahlen doppelte Anführungsstriche macht und
mit einem Komma als Trenner abspeichert.
Lese ich anschließend die eben erstellte *.csv-Datei wieder ein und
exportiere die erneut, so wird mit dem Tabulator als Trenner gearbeitet.
Doppelte Anführungszeichen tauchen nicht mehr auf. Erst dann muss ich
einschreiten, wenn ich erneut importieren will.
Die Exportfilter lasse ich dabei unberührt - die haben darauf auch keine
Auswirkungen, denn sie stehen jedes Mal in der gleichen Einstellung. Sie
haben damit auch nichts zu tun, da es nur die folgenden Optionen gibt:

Zellinhalt wie angezeigt
Formeln anstatt berechneter Werte speichern
Text zwischen Hochkommas ausgeben
Feste Spaltenbreite

Ich habe das als Bug gemeldet:
https://bugs.freedesktop.org/show_bug.cgi?id=70121

Gruß

Robert

#10

Hallo Franklin,

Hallo Michael,

> Beim "speichern unter" kann man einige dieser Möglichkeiten gezielt
> wählen, wenn man "Filtereinstellungen bearbeiten" anhakt.

Hast Du eine Ahnung, ob man die dort gewählten Einstellungen irgendwie
irgendwo so "festnageln", abspeichern kann, dass sie beim nächsten
CSV-Speichern wieder genau so als Voreinstellung kommen und man nicht
jedesmal die gleiche Umstellung vornehmen muss?

Leider nein. Das gehört zu den Dingen, die ich manchmal nicht verstehe:
Es werden immer mal wieder neue Features eingebaut bei denen ich mich
frage: Braucht man das wirklich? Dafür sind einige Features etwas
"unterentwickelt". Hier z.B. die fehlende Möglichkeit, die Optionen für
den CSV-Export zu speichern. Immerhin ist es das einzige
Tabellenformat, das praktisch universell verwendbar ist. Ich verwende
solche Dateien schon seit 30 (also gefühlt 1000) Jahren.

Ich habe noch ein altes selbst gestricktes Kommandozeilen-Programm mit
dem ich einige Umformungen vornehmen kann. Ansonsten bleiben nur
Texteditoren mit den entsprechend guten Search/Replace-Fähigkeiten.

Gruß,
Michael...

...der sich vielleicht mal wieder mit "sed" beschäftigen sollte.

#11

Hallo Christian,

comma-separated values wird zu csv.

Ich bezeichne die eher als character separates values. Das Komma ist einer
der am meisten verwendeten Delimiter, aber bei weitem nicht der einzig
mögliche. Oft wird der Strichpunkt, oft ein Tabulator, oft auch gar keiner
(feste Breite) verwendet.

Ebenso wie für die Feldtrenner gibt es auch für die einzelnen Werte keine
einheitliche Regelung. Text in einfachen oder doppelten Anführungszeichen
oder ohne. Zahlen im lokalen Format oder im englischen - mit oder ohne
Formatierung (Tausenderpunkt, Einheit, führende Nullen, Genauigkeit....)

Sprich: ohne, dass man die entsprechenden Einstellungen beim Ex- und Import
vornimmt kann man keinen reibungslosen Austausch erwarten.

Ich sollte doch aber von LO erwarten können, dass es sich ohne einen
Eingriff in die Einstellungen bei jedem Abspeichern in dieses Format
gleich verhält. Und genau das ist nicht der Fall. Speichere ich das
erste Mal, so sind die Trenner Kommata, rufe ich die Datei wieder auf
und speichere sie erneut neu ab, so sind die Trenner Tabulatoren (und
die Textbegrenzungen für Felder, die ein Komma enthielten sind weg). Ich
habe das nicht weiter mit einem dritten Speichern durchgeführt, weil
mich die Sache nicht sonderlich interessiert - es wundert mich bloß.

Gruß

Robert

#12

Hi Robert, *,

comma-separated values wird zu csv.

Ich bezeichne die eher als character separates values. Das Komma ist einer
der am meisten verwendeten Delimiter, aber bei weitem nicht der einzig
mögliche. Oft wird der Strichpunkt, oft ein Tabulator, oft auch gar keiner
(feste Breite) verwendet.

Ebenso wie für die Feldtrenner gibt es auch für die einzelnen Werte keine
einheitliche Regelung. Text in einfachen oder doppelten Anführungszeichen
oder ohne. Zahlen im lokalen Format oder im englischen - mit oder ohne
Formatierung (Tausenderpunkt, Einheit, führende Nullen, Genauigkeit....)

Sprich: ohne, dass man die entsprechenden Einstellungen beim Ex- und Import
vornimmt kann man keinen reibungslosen Austausch erwarten.

Ciao
Christian