p.s.
Dein Problem ist wahrscheinlich nicht die Exponentialdarstellung, sondern der Dezimalpunkt. Auf welches Dezimaltrennzeichen ist dein Rechner eingestellt?
dann werden die Messwerte in Exponentialdarstellung ausgegeben.
Werden diese wirklich in der csv-datei schon so ausgegeben oder erst in LO so angezeigt?
Öffne die CSV-Datei mal mit einem Texteditor wie es darin wirklich aussieht und poste ein Beispiel daraus. Daraus ergibt sich auch gleich die Frage nach dem Dezimaltrennzeichen.
Bitte verzeiht mir, dass ich die Datei nicht mitgeliefert habe.
Die Lösung (mit LibreOffice):
Alle Punkte durch Komma ersetzen
Zellen als Dezimalzahl formatieren
Den ganzen Zirkus mit der "Punkt-durch-Komma"-Ersetzung kannst du dir sparen, wenn du im Importdialog als Gebietsschema gleich passend zum Zahlenformat "Englisch (Großbritanien)" wählst.
Wobei die Frage offen bleibt,welches denn nun der richtige Standard ist.
International (Dezimalpunkt) wie das Original oder Deutsch (Dezimalkomma).
Insofern ist diese Aussage etwas -äh- merkwürdig.
In 90% aller Länder würde der Benutzer, wenn er das auf den 'Standard' konvertierte File öffnet, denken: "Was fürn Scheiss..."
Daraus ergibt sich auch gleich die Frage nach dem Dezimaltrennzeichen.
Das kann eines der möglichen Probleme sein, wenn der Softwerker der
Protokollsoftware zu blöd war, .csv zu verstehen.
Kuckst du in RFC4180 rein, wird das Problem sofort klar.
Die einfachste Definition des CSV-Formats (CSV = Comma Seperated Values) lautet:
. 1. Each record is located on a separate line, delimited by a line
. break (CRLF). For example:
.
. aaa,bbb,ccc CRLF
. zzz,yyy,xxx CRLF
Das ist Schwachsinn - spätestens dann, wenn nun noch ein Vollpfosten in aaa, bbb, usw. 'decimals' reincodiert, ohne den Rest von RFC4180 zu beachteten.
Bei
1.23,4.56,7.89 CRLF
funktioniert das ja noch, aber spätestens bei deutschen Kommazahlen
1,23,4,56,7,89 CRLF
ist dann halt Schluss mit der Eindeutigkeit.
Das CRLF (statt einem einfachen LF) kann man ja noch durchgehen lassen, lässt aber erahnen, auf wessen Misthaufen dieses CSV gewachsen ist - vermutlich auf demselben, der in Pfadangaben auch unbedingt 'slash' durch 'backslash' ersetzen musste...
Das ist Schwachsinn - spätestens dann, wenn nun noch ein Vollpfosten in
aaa, bbb, usw. 'decimals' reincodiert, ohne den Rest von RFC4180 zu
beachteten.
Worauf beziehst du dich genau?
Nur ein kleiner Teil der Welt verwendet das selbe Zeichen als Dezimal- und Listentrennzeichen.
Solange die Einträge in der CSV-Datei nicht in Anführungszeichen eingeschlossen sind, würde es für Dezimalzahlen sowieso nicht funktionieren. Der internationale Datenaustausch würde mit Dezimalkomma nicht einfacher. Auch in JSON oder XML will man keine Alleingänge bzgl. Dezimaltrennzeichen.
Es erleichtert das Leben ganz gewaltig, wenn man bei Zahlen, die für
Berechnungen in Software vorgesehen sind, als Dezimaltrennzeichen
generell den Punkt verwendet und jede Software (einschließlich des OS)
entsprechend einstellt. Unter Linux kommt man mit der globalen
Environmentvariable
1
LC_NUMERIC=POSIX
meist schon sehr weit. Unter Windows gibt es m.W. eine entsprechende
Einstellung in der Systemsteuerung. Nur für ein paar wenige kaputte
Programme, die sich frech darüber hinwegsetzen, muss man die Einstellung
ggf. noch einmal getrennt vornehmen.
In deutschen Texten kann man auch das Komma verwenden (und sollte dies
IMHO auch), da hier landesspezifische Regeln Vorrang haben und Zahlen
nicht numerisch, sondern als generische Zeichenfolge interpretiert
werden.
Beim Import von CSV-Dateien kann man das auch meistens einstellen.
Genau das war die Lösung für das Problem von Andreas:
Einfach das Gebietsschema passend zu den in der Datei verwendeten Geflogenheiten des Erstellers wählen.
Die einfachste Definition des CSV-Formats (CSV = Comma Seperated Values)
Eine andere lautet Character Seperated Values.
"Kuckst du in RFC4180 rein" - aber ich wiederhole mich ...
<code>
RFC 4180 Common Format and MIME Type for CSV Files October 2005
1. Introduction
The comma separated values format (CSV) has been used for exchanging
[...]
</code>
Gibt es für das Oszilloskop "Siglent SDS1104X-E" keine deutschsprachige Menüführung? Dann würde der CSV Export mit ',' anstatt mit '.' durchgeführt werden. (falls richtig implementiert)
In deutschen Texten kann man auch das Komma verwenden (und sollte dies
IMHO auch), da hier landesspezifische Regeln Vorrang haben und Zahlen
nicht numerisch, sondern als generische Zeichenfolge interpretiert
werden.
RFC 4180 ist kaputt - weil es, aus bekannten Gründen, nach allen Fliegen schlagen will.
Man hätte in CVS als AUSTAUSCHFORMAT durchaus den Dezimalpunkt festschreiben können. Hat man aber nicht. Die Auswirkungen sieht man ja ...
Wie 'decimals' landesspezifisch richtig dargestellt werden, steht auf einem ganz anderen Blatt: Hier haben natürlich die jeweiligen Regeln vorrang.
Gibt es für das Oszilloskop "Siglent SDS1104X-E" keine
deutschsprachige
Menüführung? Dann würde der CSV Export mit ',' anstatt mit '.'
durchgeführt werden. (falls richtig implementiert)
Das Menü ist auf Deutsch, trotzdem kommt die csv-Datei mit Punkt als Dezimaltrennzeichen heraus.
(Wenn die Entwickler das Komma als Dezimaltrennzeichen implementieren würden, dann kollidiert dies mit dem Komma als Feldtrenner-Zeichen. Also muss dann auch ein anderes Feldtrenner-Zeichen her.)
Den ganzen Zirkus mit der "Punkt-durch-Komma"-Ersetzung kannst du dir
sparen, wenn du im Importdialog als Gebietsschema gleich passend zum
Zahlenformat "Englisch (Großbritanien)" wählst
csv-Ausgabe.png
(7,2 KB)
