Wie behebt man eine Anwendung, die ein Problem mit dem Dezimaltrennzeichen hat

Setzen Sie Thread.CurrentThread.CurrentCulture richtig und Sie haben solche Probleme nicht. Lesen Sie hier , wie Sie kulturunabhängigen Code schreiben können.

BEARBEITEN: Wenn Sie keinen Zugriff auf den Code haben, können Sie die Anwendung unter einem Benutzerkonto ausführen, das den erwarteten Kultursatz aufweist. Für den schnellen Zugriff können Sie einen englischen Benutzer, einen deutschen Benutzer, einen französischen Benutzer erstellen.

Meiner Meinung nach sollte der Ansatz folgen:

1. im internen Speicher sind die Zahlen nur Zahlen. also kein Problem auftritt.
2. Wenn Sie Eingabetextquellen analysieren, sollten Sie sie entsprechend der Ländereinstellung analysieren, in der die Quelle erstellt wird - höchstwahrscheinlich invariante Kultur
3. Wenn Sie die Werte an den Benutzer ausgeben, formatieren Sie sie nach dem vom Benutzer bevorzugten Gebietsschema. in C # bedeutet dies, dass CurrentCulture (nicht CurrentUICulture , siehe hier warum) beibehalten wird.

Dies sollte relativ einfach sein und alle Fälle abdecken.

Dies alles gilt für den Fall, dass Sie der Autor der Anwendung sind. Für andere Anwendungen müssen die jeweiligen Entwickler ihre Fehler selbst beheben.

Ich fühle Ihre Schmerzen, der Port von RunKeeper an Windows Phone 7 hat das falsch verstanden und berichtet, dass ich die Lichtgeschwindigkeit um einen Faktor von 100 000 im letzten Monat gebrochen habe.

Wenn Sie schlampig sind, werden Sie auf diese Probleme stoßen, aber in den meisten Fällen können sie vermieden werden. Streng genommen sollten Sie Informationen immer in ihrem lokalisierten Format präsentieren und sie dann in einen kulturunabhängigen oder Basiswert konvertieren, wenn Sie sie speichern. Auf diese Weise können Sie immer gezielt auf bestimmte Kulturen abzielen.

Das Problem, auf das viele .NET-Entwickler stoßen, ist, dass sie nicht verstehen, dass alle Standardmethoden für Parsing-Methoden auf Thread.CurrentThread.CurrentCulture zurückgreifen und ein bestimmtes Zahlenformat für diese Kultur verwenden. Dasselbe gilt für Datums- und Zeitzonen .

Etwas, das ich in Betracht ziehen könnte, ist eine Kette von Verantwortlichkeiten aufzubauen, in der ich zuerst die kulturspezifischen Varianten und ein kulturinvariantes Fallback abgefragt habe. Ich würde diese niemals mischen, aber ich würde einen kulturunabhängigen Standard unterstützen, der funktionieren sollte, wenn Sie sich an eine typische Konvention halten (z. B. englische Zahlenformate). Aber das ist nicht immer die richtige Wahl, erziehen Sie Benutzer, wenn sie denken, dass die Analyse einer CSV-Datei mit gemischtem Zahlenformat eine gute Sache ist.

Hier ist keine Silberkugel.

Einige Vorschläge:

Die invariante Kultur kann verwendet werden, wenn interne Daten behandelt werden, die in einer Konfigurationsdatei gespeichert sind. Auf diese Weise können Sie unabhängig von der Kultur der Maschine Ihre eigenen internen Daten konsistent lesen und schreiben.

Siehe hier:

Ссылка

Andere Probleme behandeln etwas Einfaches wie string.ToLower ().

Scheint unschuldig genug, bis Sie versuchen, einen englischen Buchstaben in Kleinbuchstaben zu schreiben, als in der aktuellen Kultur nicht vorhanden ist. (E.G. Türkisch)

In diesen Fällen sollte der Aufruf von string.ToLower () durch die Kulturüberladung ersetzt werden und die aktuelle Kultur oder invariante Kultur sollte übergeben werden (abhängig von Ihrer Situation).

Auf jeden Fall einige Fallen, auf die man achten sollte.

Es gibt wirklich keine andere Möglichkeit, dieses Problem zu lösen, indem Sie es einfach im Code reparieren.
Wenn Sie FxCop ausführen möchten, würden Sie schnell lernen, immer zu bleiben Übergeben Sie CultureInfo an alle möglichen Methoden ToString() oder Parse() . Ehrlich gesagt, sollte dies so gemacht werden, auch wenn Sie wissen, dass CultureInfo.CurrentCulture standardmäßig verwendet wird.
Indem Sie IFormatProvider immer übergeben, sagen Sie anderen Entwicklern:

1. ToString(CultureInfo.CurrentCulture) oder Parse(whatever, CultureInfo.CurrentCulture) - dies ist etwas, was der Endbenutzer sehen wird oder in Zukunft betreten kann. Daher müssen wir uns um seinen kulturellen Hintergrund kümmern.
2. ToString(CultureInfo.InvariantCulture) oder Parse(whatever, CultureInfo.InvariantCulture) - dies verwenden wir intern und es ist nicht dazu gedacht, dem Benutzer angezeigt zu werden.

Nun, ich weiß, es klingt nach viel Arbeit, aber das ist einfach etwas, was getan werden muss. Vielleicht möchten Sie nur einigen armen Menschen in Microsoft danken, die mit ihrer guten Absicht entschieden haben, dass CurrentCulture des Endbenutzers der beste Standard für Formatierungs-Anbieter ist ... Offensichtlich waren andere Framework-Designer, die das in der Vergangenheit taten, falsch und Leute aus MS haben recht, ha? Eine Menge Geld ist durch diesen blöden, unflexiblen Fehler verloren gegangen.