Excel will nicht rechnen, bringt als Ergebnis einer Addition nur "Wert!" - warum bloß ?

[TPfanne]

Fazit: Doppelklick auf eine CSV öffnet bei mir Numbers, wo es funktioniert.
Die meisten Finanzsachen habe ich seit Jahrzehnten auf Excel-Basis, wo entweder Umlaute und €-Zeichen zerstört werden oder man nicht mehr rechnen kann... Ich möchte diese Inputs ohne Mühe in meine Excel-Buchhaltung übertragen können. Das war vor einem Jahr problemlos möglich.
Das kann es doch nicht sein. Microsoft (if you hear me): You can do better that that!

 

[dodo4ever]

Fazit: Doppelklick auf eine CSV öffnet bei mir Numbers, wo es funktioniert.

Dann mit Sekundarklick öffnen.
Es liegt nicht an Microsoft, es liegt an der CSV
Das müsste da halt als nackte Zahl drinstehen.
Wie gesagt, du kannst es ganz leicht konvertieren.

 

[TPfanne]

Ich habe jetzt durch Probieren einen relativ einfachen Weg gefunden:
Import (wie bisher mit UTF-8: also keine Zerstörung der Umlaute) dann Ersetzen von " €" durch nichts ("") und schwupp erkennt Excel den in der Spalte eigentlich vorhandenen Zahlencharakter. Leider muss man dann die vorher vorhandenen €-Zeichen wieder einfügen.
Sub Euro_weg()
'
' Euro_weg Makro
' Entfernt Euro-Zeichen
'
' Tastenkombination: Strg+ö
'
Cells.Replace What:=" €", Replacement:="", LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, FormulaVersion:=xlReplaceFormula2
End Sub

 

[TPfanne]

Einfacher wäre natürlich ein Skript, das die € bereits aus der CSV-Datei entfernt, die ich ja nicht beeinflussen kann, weil sie von AirBnB kommt.
TextEdit kann das zwar, aber kennt keine Makros.

 

[dodo4ever]

Ich habe jetzt durch Probieren einen relativ einfachen Weg gefunden:
Import (wie bisher mit UTF-8: also keine Zerstörung der Umlaute) dann Ersetzen von " €" durch nichts ("") und schwupp erkennt Excel den in der Spalte eigentlich vorhandenen Zahlencharakter. Leider muss man dann die vorher vorhandenen €-Zeichen wieder einfügen.

Super.
Wieder einfügen musst du sie nicht.
Einfach sie Spalte mit Apfel + 1 aus Währung formatieren.

 

[fa66]

lso hinter den Werten hängt einfach eine "wilde" Zeichenkette, sieht man sofort nach dem Öffnen im Excel.

Dagegen hilft die Kenntnis über die Art und Weise der Text-, letzlich Datei-Kodierung der CSV, auf die man dann den Importassistenten in Excel abstellen kann. Text ist zwar Text, aber nur in Bezug auf die verwendete Norm (ANSI, ISO-8859-x, UTF-8,…) zu lesen.

 

[fa66]

Ich verstehe den Aufwand mit GREP eigentlich nicht (zumal das Überblicken der Ersatzsequenzen fehleranfällig sein kann).

In der in #26 gegebenen CSV muss doch nur in einem Texteditor gewisse eindeutige Zeichenketten ersetzt (siehe meine #43) – und am Ende die Datei neu als CSV im UTF-8-Format gespeichert werden, um dann dem Excel-Textimportassistenten mit der Maßgabe der Quelle UTF-8 angeboten und nach dem Importieren der die Währung enthalten sollenden Spalte neu das Format Währung zugewiesen werden.

Und ja, selbst wenn Numbers alles »richtig« macht bei der zu importierenden Quelle, so weißt du ja noch nicht, was Numbers alles bei einer anderen Datenquelle anderer Machart »falsch« macht, wo Excels Importassistent dann die auszuwählenden Importkriterien anböte.

 

[TPfanne]

Also mit einem Eurozeichen sollte ein Programm schon so umgehen können, dass es einen Zahlenwert nicht gleich zum Text macht, den man erst nach mehreren Schritten wieder zu einem Wert macht, mit dem man rechnen kann.

 

[dodo4ever]

Also mit einem Eurozeichen sollte ein Programm schon so umgehen können, dass es einen Zahlenwert nicht gleich zum Text macht, den man erst nach mehreren Schritten wieder zu einem Wert macht, mit dem man rechnen kann.

Warum?
Streng genommen ist es doch mit dem €-Symbol eher ein Text als eine (rationale) Zahl.

Wenn du z.B. bei Barclays deinen Kontensaldo als .csv lädst, bekommst du eine eigene Spalte Currency.
So ist das m.E. datentechnisch korrekt.

Naja, Problem ist ja zum Glück gelöst.
Es geht eh nur noch ums Prinzip.

 

[TPfanne]

#69: Klar, dann müsste AirBNB in seinen CSV-Dateien eine eigene Währungsspalte einrichten und so uns Exelianern das Leben leichter machen.
Aber immerhin sind $ und € die beiden Welt-Devisen, die ein Programm kennen/können sollte.

 

[fa66]

Also mit einem Eurozeichen sollte ein Programm schon so umgehen können, dass es einen Zahlenwert nicht gleich zum Text macht,

Du interpretierst als Mensch, wo in diesem Falle Excel nicht interpretiert.
In der Wissenschaftstheorie lernt man, dass Daten eine Bedeutung nur in Bezug auf einen selbst vorgegebenen Bedeutungsrahmen bekommen. ,"381,51 €", ist in einer CSV-Datei nicht mehr und nicht weniger als die Sequenz der Zeichen, die du siehst. Schon ANSI, ISO8859-1 oder UTF-8 in der Form Unicode11 sind mitzuteilende Interpretationen, an der sich eine Software dann orientieren kann.

Dein Erkenntnisapparat ordnet Dinge in der Weise, wie du sie haben zu wollen glaubst. So wie du in Löchern in einem Astwerk oder an einer Fensteranordnung an einem Gebäude Gesichter zu erkennen glaubst, so glaubst du an einem Zeichen, das dir als Zeichen für eine Währung geläufig ist, einen Währungsbetrag zu erkennen, der er erstmal nicht ist: sondern nur eine Zeichenkette, die so oder so, oder auch gar nicht interpretiert wird.

 

[TPfanne]

Dass € ein Währungszeichen ist, wie der Dollar, scheint sich bei Microsoft also noch nicht herumgesprochen zu haben?

 

[fa66]

Dass € ein Währungszeichen ist, wie der Dollar, scheint sich bei Microsoft also noch nicht herumgesprochen zu haben?

Das was du da zeigst, ist erstmal nur ein stilisiertes »E«, so wie $ ein stilisiertes »S« ist (das übrigens erstmal für SESTERTIVS steht – klassisch humanistisch also). Und was es da alles an stilisierten E’s gibt:


Und warum dann nicht auch USD oder EUR?

»Währung« ist ein Metadatum, das einfach nicht per se aus der Zeichenkette hervorgeht. Und CSV bietet selbst bauartbedingt keine Methode, Metadaten wiederzugeben. Da sind Form, Inhalt und Bedeutung getrennt. Schon SGML, von der abgeleitet HTML und XML bedeutende Markierungsformate sind, scheidet das Markup von der Form in CSS und XSL und einer DTD zum Lesen des Ganzen.

Nebenbei: nicht jeder will mit der betreffenden Zeichenkette rechnen.

 

[lisanet]

@lisanet: Habe es probiert mit dem Bah; ohne Erfolg:
Anhang anzeigen 380479

das ist nur dann möglich, wenn die Datei nicht in UTF-8 vorliegt oder du kein copy&paste verwendest und deine Terminal eine andere Kodierung hat. Prüfe das mal in den Terminaleinstellungen.

Wenn ich zuhause bin, sehe ich nach wie sie dich konvertieren lässt bzw welche Kodierung sie hat. Ich vermute event Latin-1

Du kannst auch probieren, die Datei in Bbedit zu öffnen und dort in UTF-8 wieder speichern und dann den Terminal Befehl wiederholen

 

[lisanet]

@TPfanne

Ich habe die Ursache und die Lösung gefunden, warum das Terminal-Kommando mit sed nicht funktionierte.

Das Problem ist nicht alleine das Euro-Zeichen, sondern ein sogenanntes "festes Leerzeichen", dass dazu verwendet wird, zwar ein Leerzeichen anzuzeigen, aber es nicht als Begrenzung zwischen Wörtern/Zahlen/Symbolen zu interpretieren. Und so ein festes Leerzeichen ist zwischen dem Betrag und dem Euro-Symbol.

Lösung war also, das sed Kommando ebenso mit einem festen Leerzeichen laufen zu lassen. Ich habe es mit der von dir verlinkten Datei getestet.

Das unglückliche ist nun, dass durch das copy&paste hier übers Forum, das feste Leerzeichen nicht übernommen wird. Du musst es also selbst eingeben. Das ist aber ganz einfach mit ALT+Leertaste zu machen.

Also entweder tippe das Kommando einfach ab und mach im sed-Befehle die Folge "s/ €//" eben mit ALT-Leerzeichen (festes Leerzeichen) und ALT+E (Euro-Symbol) oder mach erst copy&paste und lösche dann das Leerzeichen raus und tipp anstelle dessen eben ALT+Leerzeichen

sed -e "s/ €//" "reservations2022neu.csv" > "neu.txt"

Dann klappt das auch problemlos mit dem Import nach Excel. Beachte dabei aber bitte, dass du die Kodierung auf UTF-8 stehen hast.

 

[fa66]

Interessehalber:
Ist es in der konkreten Quelle der NO-BREAK SPACE, U+00A0, – oder der NARROW NO-BREAK SPACE, U+202F, der dort platziert ist?

Erwarten würde ich nach Norm den letzteren, der die Zeichenkette eines Währungsbetrags mit dem Währungszeichen verbindet (dasgleiche Zeichen, das nach Norm die Tausender gruppiert).
https://de.wikipedia.org/wiki/Schmales_Leerzeichen
https://de.wikipedia.org/wiki/Zifferngruppierung#Mit_dem_Tausendertrennzeichen
https://de.wikipedia.org/wiki/Schreibweise_von_Zahlen

Dieses ist in einer Festweitenschrift dann nicht von einem normalen oder dem erstgenannten Leerzeichen zu unterscheiden (das NO-BREAK sorgt dafür, dass Zifferngruppen bzw. das Währungszeichen nicht umbrochen werden).

 

[lisanet]

Ist es in der konkreten Quelle der NO-BREAK SPACE, U+00A0,

yep, das NO-BREAK SPACE.

Wäre es nicht so, würde das sed ja nicht funktionieren, da im sed-Befehl ALT + Space verwendet wird. ( BTW, der Text ist in nicht in Latin-1, sondern UTF-8 kodiert, daher wäre das in hex C2A0)