[gelöst] string zu decimal; Konvertierung von einem unbekannten Sprachformat

Hallöchen,

ja, das leidige Thema Sprachen und Konvertierungen.

Bin leider an einer Stelle angekommen, an der ich als string 😜 einen Dezimalwert überliefert bekomme.

So, wollte nun wissen, wie Ihr sowas am besten gelöst habt?

Meine derzeitige eher gräßliche Lösung sieht folgends aus:

            string value = "1 536,33";
            decimal d;
            CultureInfo[] cultures = { new CultureInfo( "en-US" ), new CultureInfo( "fr-FR" ), new CultureInfo( "de-DE" ), new CultureInfo( "cs-CZ" ), CultureInfo.InvariantCulture };

            foreach (CultureInfo ci in cultures)
            {
                Console.WriteLine( String.IsNullOrWhiteSpace( ci.Name ) ? "InvariantCulture" : ci.Name );
                if (decimal.TryParse( value, NumberStyles.Currency, ci, out d )) Console.WriteLine( d );
                else Console.WriteLine( "gescheitert" );
            }

Gäbe es etwas schöneres, als dann unter Umständen in irgend einer Konfig 'mögliche' Sprachen festzulegen, nach denen diese frickelei geprüft/konvertiert wird?

Betsen Dank im Voraus,
Thomas

Hi ThomasE.,

So, wollte nun wissen, wie Ihr sowas am besten gelöst habt?

Welches Problem genau möchtest du denn gelöst haben? Welche Anforderungen hast du? Normalerweise ist es doch so, daß die Werte in der Culture der UI übergeben werden. Woher kommen bei dir die anderen Cultures? Wieso kommt bei dir in der Liste nicht die Culture der aktuellen UI vor?

@MrSparkle
Da es keine Informationen von Op gibt woher die String Dezimal Werte kommen, kann man nicht davon ausgehen, dass diese auch mit der UI Culture übereinstimmen.
Könnten auch Einträge aus einer Textdatei o.ä. sein.

@ThomasE.
Gibt es kein festes Schema von den Dezimal Werten her?
Wenn ja, dann musst du nur schauen welches Format diese haben und dann dieses verwenden.
Wenn es kein festes Schema geben sollte, was ich mir aber icht ganz so vorstellen kann, dann wäre dein aktuelles Vorgehen nach meiner Kentniss der einzige Weg.

Ich würde aktuell aber von einem fixen Schema ausgehen, entsprechend wäre bei deinem aktuellen Beispiel die Culture de-DE passend.
Das Problem ist aber, dass auch eine falsche Culture bei einem passenden Werte geparst werden kann.
Dann kann aber das Dezimal Trennzeichen als Tausender Trennzeichen interpretiert werden.

T-Virus

@T-Virus:
Da wir keine Informationen darüber haben, können wir auch nicht sagen, wie wir sowas am besten gelöst haben.

Im Codebeispiel wird der Wert "10,00" jedenfalls nicht nach 10.0 geparst.

Gäbe es etwas schöneres, als dann unter Umständen in irgend einer Konfig 'mögliche' Sprachen festzulegen, nach denen diese frickelei geprüft/konvertiert wird?

T-Virus hat das eigentliche Problem nebenbei erwähnt:

a) für eine beliebige Zeichenkette ist nicht sicher, dass es genau eine CultureInfo gibt, die sie als Zahl interpretieren kann. Im Gegenteil, sehr wahrscheinlich gibt's mehrere: an der Zeichenkette ist also nicht zu erkennen, welche CultureInfo das ist.

b) das Ergebnis des Parsings ist nicht unabhängig von der CultureInfo.

Beides zusammen bedeutet: du kannst jederzeit in die Situation kommen, dass du zu einer Zeichenkette mehr als ein geparstes Ergebnis bekommst, ohne dass du entscheiden kannst, welches das richtige ist.

Was auch genau der Grund dafür ist, die Culture vorzugeben: sie selbst herauszufinden (und damit die richtige Interpretation der Zeichenkette), ist u.U. nicht möglich.

LaTino

Hallo und danke für die schnellen Antworten!

Ok, fehlt Info:
Es geht um das halbtote Silverlight, in dem wir ein PlugIn laufen haben.
Das Fremd-System hat mehrere Sprachen aus denen man greifen kann: Format, Schema und UI.
Der Client selbst, liefert jedoch keine Info über die Schnittstelle über die aktuellen Sprachen die im System verwendet werden UND ob die Browsersprache verwendet wird oder nicht.

Die Überlieferung der Informationen zur Problemstelle geht folgenden Weg:
Client-Schnittstelle->
1:1 Datenübernahme ich ein transport-Objekt, in dem Fall ist der Wert schon von der Schnittstellenübergabe ein string, den ich einfach unverändert übernehme(n muss)->
Informationen werden an eigenes Webservice übermittelt-->
Problemstelle alle Werte als string, wie sie 1:1 übernommen wurden-->
Informationen sollten im gültigen Format weitergeleitet werden

Der Ablauf ist im aktuellen System nicht änderbar.

Aber auf Grund Eurer Informationen und meiner Eingebung nach dem Erstellen dieses Themas, könnte ich folgendes umsetzen:
.) Information/Einstellung ob Browsersprache verwendet werden soll, ist pro RIA Installation einmalig festgelegt, kann in eigene Konfig übernommen werden
.) Je nach Einstellung, wird dann mit dem transport-Objekt die festgelegte Sprache (ebenfalls konfigurierbar machbar) oder die Browsersprache übermittelt.
.) WebService-Server-Seitig kann dann danach konvertiert werden.

Interessant wie die Gedanken sprudeln, wenn man einfach nur den Text hier schreibt...
Muß vorher noch checken, welche der 3 (Sprachen) Sprachabhängigen-Datenformate überhaupt übergeben werden. Muß ich wohl die Fremdfirma damit konfrontieren...

Vielen Dank fürs Erste und auch für die nützlichen Infos, daß meine erstere Lösung eher schlecht als gut ist...

Der Client selbst, liefert jedoch keine Info über die Schnittstelle über die aktuellen Sprachen die im System verwendet werden UND ob die Browsersprache verwendet wird oder nicht.

Wenn der Client schon nicht die verwendete Sprache zurückliefert, hat er evtl. eine Funktion zum Parsen schon eingebaut?

Da ihr ein Plugin für eine Anwendung schreibt, wäre es ja ganz interessant, ob es auch andere Plugins dafür gibt, die dieses Problem bereits irgendwie gelöst haben.

Hallo,

ne, das übergebene Objekt ist nur ein Datenobjekt ohne Funktionen.

Partner wurde schon verständigt, mal schauen was dabei rauskommt.

Also, ich bekam die Meldung, daß der Client selbst die eingestellte Sprache unter System.Thread.CurrentThread.CurrentCulture setzt, was eben auch das Format der 'string' Werte für 'decimal' und 'DateTime' ist.

Was ja daraus logisch schlußfolgern läßt, daß ich genau so auch im PlugIn wieder darauf zugreifen kann.

Somit ist die Sache wieder rund und muß nicht extra dafür Konfigurationen festlegen.

Danke an Alle für die Hilfe!
Grüße