"Sicheres" Umwandeln von Zeichenkette in Zahl

[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