Double.TryParse Tausendertrenner gibt ein unerwartetes Ergebnis zurück

8

Ich habe gerade etwas sehr Seltsames erlebt und mich gefragt, ob ich etwas verpasst habe.

Ich habe versucht, eine Zeichenkette (mit tausend Trennzeichen) zu einem Doppelklick zu analysieren und das folgende Problem gefunden.

%Vor%

Nun, der Grund, warum ich Convert.ToDouble nicht benutzen wollte, liegt an der wissenschaftlichen Notation, die mir schon einige Probleme bereitet hat.

Weiß jemand, warum das so sein könnte?

BEARBEITEN:

Ich habe meine aktuellen Kulturinformationen aktualisiert.

    
Adriaan Stander 06.09.2012, 12:31
quelle

3 Antworten

4

Es funktioniert wie erwartet an meiner Maschine, also glaube ich, dass es mit der aktuellen Kultur zu tun hat. Verwenden Sie CultureInfo.InvariantCulture anstelle von null in Ihrem TryParse

%Vor%

Es ist fehlgeschlagen für Ihre aktuelle angegebene Kultur en-ZA , ich habe versucht den folgenden Code und try2 hält 0.0

%Vor%     
Habib 06.09.2012, 12:42
quelle
4

Aktualisierte (korrekte) Antwort, nach vielem Graben

Sie sagen, dass Ihre aktuelle Kultur en-ZA ist, überprüfen Sie jedoch

%Vor%

Wir sehen, dass der Wert die leere Zeichenfolge und nicht "," ist, wie die Frage angibt. Wenn wir also CultureInfo.CurrentCulture auf new CultureInfo("en-ZA") setzen, schlägt das Parsen selbst für try1 fehl.

Nach der manuellen Einstellung auf "," mit

%Vor%

Es zeigt sich, dass das Parsen in try1 erfolgreich ist. Das Parsen in try2 schlägt immer noch fehl.

Für die in TryParse verwendete try2 Überladung ist die Dokumentation ziemlich klar, dass die aktuelle Threadkultur verwendet wird, wenn der Formatanbieter null ist, also muss etwas anderes losgehen ...

Nachdem ich InvariantCulture.NumberFormat sorgfältig mit dem der en-ZA-Kultur verglichen habe, ist mir aufgefallen, dass sich die Kulturen auch in ihren Währungsformaten unterscheiden. Versuchen

%Vor%

Den Jackpot knacken: Parsing gelingt! Also, was wirklich los ist, ist das wenn% ce_de% verwendet wird, behandelt das Parse die Zahl als Währung .

Die Hypothese kann verifiziert werden, wenn Sie

versuchen %Vor%

was gelingt, ohne sich mit den Währungsseparatoren herumschlagen zu müssen (natürlich muss die NumberStyles.All passen)!

    
Jon 06.09.2012 13:03
quelle
1

Die Dokumentation sagt, dass 0.0 zurückgegeben wird, wenn die Konversation schlägt fehl.

Am wahrscheinlichsten TryParse gibt false zurück, und Sie sollten versuchen, Parse aufzurufen, um eine Ausnahmebedingungsnachricht zu erhalten, die Ihnen sagen könnte, was falsch ist.

    
Wutz 06.09.2012 12:38
quelle

Tags und Links