"Sicheres" Umwandeln von Zeichenkette in Zahl

[nahpets]

Nö, lieber nicht, das ist so eine meiner tückischen Formulierungen, die dabei rauskommen, wenn ich vergeblich versuche, mich präzise auszudrücken. Man merkt daran, dass ich mich über viele Jahre mit Juristerei rumschlagen musste. Da muss dann in einem Satz alles Mögliche so sicher und korrekt und widerspruchsfrei formuliert werden, dass es am Ende doch wieder nur unverständlich ist. Oder kurz: Beamtendeutsch :-(

Und bei 'ner Aufnahme würd' ich vermutlich sehr arg ins Stottottottottotteren kommen ;-)

[Uwe Raabe]

Zitat:

Zitat von stifflersmom (Beitrag 1382287)

Wo stehen eigentlich genau diese

Delphi-Quellcode:

  cLocales: array[0..5] of Integer
      = (
         1031, { German }
         1033, { English }
         1040, { Italian }
         1055, { Turkish }
         3082, { Spanish }
         LOCALE_USER_DEFAULT);

Länderkosntanten?

https://msdn.microsoft.com/en-us/lib...edded.10).aspx

[Uwe Raabe]

Der Code soll natürlich nur als Richtlinie dienen. Natürlich muss man die ganze Sucherei nach den richtigen FormatSettings nicht bei jedem Wert machen. Einmalig am Anfang der Datei genügt. Danach sollte sich das ja nicht mehr ändern. (Hat Stephan ja in einem der Code-Comments schon erwähnt)

[stifflersmom]

Klar, nach Möglichkeit einmal feststellen und dann ab dafür.
Vielleicht müssen zuerst ein paar Werte geprüft werden, man stelle sich vor es steht eine 1,000 in der ersten Zeile. Da kann jetzt wirlich nicht sicher festgemacht werden, ob ein amerikanisches Zahlenformat ohne Nachkommastelle oder eine deutsche 1 mit drei Nachkommastellen vorliegt.
Aber grundsätzlcih, sollte schon in den ersten paar Zeilen eine mehr oder weniger eindeutige Identifikation möglich sein.

[mensch72]

wir gehen das per DoubleParse und "statistisch" an:
1. Harte Regel: in einem Zahlenfeld werden alle Leerzeichen elliminiert
2. Harte Regel: sobald in einem Zahlenfeld eine "nicht Ziffer" doppel auftaucht wird dies als 1000er Trennung behandelt und nun stets "eliminiert"
3. Harte Regel: wenn in einem Zahlenfeld verschiedene "nicht Ziffern" gefunden werden, gilt das Zeichen am weitesten rechts als "Komma" und alles andere als "Tausendertrennung" wird nun stets "eliminiert"
4. Weiche Regel: wenn in den Zahlenfeldern nach einer "nicht Ziffer" stets 3 weitere Ziffern folgen, gilt dieses SeparatorZeichen als "TausenderTrennung" und wird nun stets "eliminiert"
5. Harte Regel: wenn jetzt noch mehr wie eine "nicht Ziffer" als Separator übrig ist, UND da 'Komma" + "Punkt" noch vorhanden sind, bricht die Autoformaterkennung ab, dann geht muss manuell der KommaSeperator festgelegt werden
6. Weiche Regel: nach "Rule5" gilt "Punkt" ODER "Komma" als DezimalSeparator und bleibt erhalten, alle anderen "nicht Ziffern" werden nun stets "eliminiert"

Wir arbeiten so mit dem Aufwand der ersten nur vollen Importdatenanalyse und dann folgendend erst dem eigentlichen Import seit zig Jahren mit einer voll automatisierten Erfolgsquote von 98..99%.
Unser "RuleSet" ist nur anfällig oder nicht eineindeutig, wenn es Werte mit 3stelliger Genauigkeit und "Tausendertrennung" geben kann... zum Glück haben wir im Finanzbereich nur sinnvolle Werte mit 1,2,4,6,8 Kommastellen:)

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1382296)

Einmalig am Anfang der Datei genügt. Danach sollte sich das ja nicht mehr ändern. (Hat Stephan ja in einem der Code-Comments schon erwähnt)

Ein Fehlschluß, der auf der Annahme Beruht, der Datenerfasser wüßte was er tut. Die Praxis zeigt leider das Gegenteil. Ich würde auf jeden Fall jede Zeile/Datensatz überprüfen.

Gruß
K-H

[Rollo62]

Vielleicht wäre das auch eine Option per RegEx ?

Das könnte man z.B. erweitern so das am Ende nur '.' Decimals für alle Sprachen rauskommt,
und es dann nur mit einem Default-FormatSetting in eine Zahl konvertiert.
Ist vielleicht ein bischen mit Kanonen auf Spatzen, aber diese Konvertierungsfragen sollte man womöglich ein für alle Mal lösen.

Auch wäre es nicht schlecht wenn man nach einer Konvertierung auch wüsste was es nun war,
damit man das Ergebnis evtl. wieder zurückwandln kann.

Das würde vielleicht auf eine separate "Converter" Klasse hinauslaufen, so das man die internen Funktionen nicht mehr benutzen muss/darf.

Rollo

[p80286]

Noch ein Gedanke am Rande:
Ist eigentlich sicher, daß es sich bei den Zeichenketten um Numerische Werte handelt?
Es wäre nicht das erste Mal, das Seriennummern, Aktenzeichen und ähnliches zu numerischen Werten konvertiert werden und eine Prüfziffer, die dann zu einem Dezimalbruch wird ist nicht so genial.

Gruß
K-H