Was bedeutet CultureInfo.InvariantCulture?

Ich habe eine Zeichenfolge wie folgt:

var foo = "FooBar"; 

Ich möchte eine zweite Saite mit der Bezeichnung ” bar deklarieren und diese gleich dem ersten und vierten Zeichen meines ersten foo , also mache ich das so:

 var bar = foo[0].ToString() + foo[3].ToString(); 

Das funktioniert wie erwartet, aber ReSharper rät mir, Culture.InvariantCulture in meine Klammern zu setzen, damit diese Zeile so endet:

 var bar = foo[0].ToString(CultureInfo.InvariantCulture) + foo[3].ToString(CultureInfo.InvariantCulture); 

Was bedeutet das, und wird es beeinflussen, wie mein Programm läuft?

Nicht alle Kulturen verwenden das gleiche Format für Datums- und Dezimal / Währungswerte.

Dies ist für Sie wichtig, wenn Sie Eingabewerte (Lesen) , die als Zeichenfolgen gespeichert sind, in DateTime , float , double oder decimal DateTime . Es spielt auch eine Rolle, ob Sie versuchen, die oben genannten Datentypen für die Anzeige oder Speicherung in Zeichenfolgen (Schreiben) zu formatieren.

Wenn Sie wissen, in welcher spezifischen Kultur Ihre Daten und Dezimal / Währungswerte im CultureInfo , können Sie diese spezifische CultureInfo Eigenschaft (dh CultureInfo("en-GB") ) verwenden. Zum Beispiel, wenn Sie eine Benutzereingabe erwarten.

Die CultureInfo.InvariantCulture Eigenschaft wird verwendet, wenn Sie eine Zeichenfolge formatieren oder analysieren, die von einer Software unabhängig von den lokalen Einstellungen des Benutzers analysiert werden kann.

Der Standardwert ist CultureInfo.InstalledUICulture sodass die Standard-CultureInfo von den Einstellungen des ausführenden Betriebssystems abhängt. Deshalb sollten Sie immer darauf achten, dass die Kulturinformationen zu Ihrer Absicht passen (siehe Martins Antwort für eine gute Richtlinie).

  • CultureInfo.InvariantCulture Beispiel
  • CultureInfo.InvariantCulture in StackOverflow
  • CultureInfo.InvariantCulture MSDN-Artikel
  • Vordefinierte CultureInfo-Namen

Wenn Zahlen, Daten und Zeiten in Strings formatiert oder aus Strings analysiert werden, wird eine Kultur verwendet, um zu bestimmen, wie es gemacht wird. ZB in der dominanten en-US Kultur haben Sie diese String-Darstellungen:

  • 1.000.000,00 – eine Million mit einem zweistelligen Bruchteil
  • 29/09/2013 – Datum dieses Beitrags

In meiner Kultur ( da-DK ) haben die Werte diese Stringdarstellung:

  • 1.000.000,00 – eine Million mit einem zweistelligen Bruchteil
  • 29.01.2013 – Datum dieses Beitrags

Im Windows-Betriebssystem kann der Benutzer sogar anpassen, wie Zahlen und Datum / Zeit formatiert werden, und kann auch eine andere Kultur als die Kultur seines Betriebssystems wählen. Die verwendete Formatierung ist die Wahl des Benutzers, wie es sein sollte.

Wenn Sie also einen Wert formatieren, der dem Benutzer beispielsweise mit ToString oder String.Format oder aus einer Zeichenfolge mit DateTime.Parse oder Decimal.Parse analysiert wird, verwendet der Standardwert CultureInfo.CurrentCulture . Dies ermöglicht dem Benutzer, die Formatierung zu steuern.

Bei der Formatierung und Analyse von Strings werden jedoch nicht zwischen der Anwendung und dem Benutzer Strings ausgetauscht, sondern zwischen der Anwendung und einem bestimmten Datenformat (z. B. einer XML- oder CSV-Datei). In diesem Fall möchten Sie CultureInfo.CurrentCulture nicht verwenden, da das Formatieren und Parsen mit verschiedenen Kulturen CultureInfo.CurrentCulture kann. In diesem Fall möchten Sie CultureInfo.InvariantCulture (das auf der en-US Kultur basiert) verwenden. Dies stellt sicher, dass die Werte ohne Probleme abgerundet werden können.

Der Grund dafür, dass ReSharper Sie warnt, ist, dass einige Anwendungsentwickler diese Unterscheidung nicht kennen, was zu unbeabsichtigten Ergebnissen führen kann, aber sie entdecken dies nie, weil ihre CultureInfo.CurrentCulture en-US ist, die dasselbe Verhalten wie CultureInfo.InvariantCulture . Sobald die Anwendung jedoch in einer anderen Kultur verwendet wird, in der die Möglichkeit besteht, eine Kultur für die Formatierung zu verwenden, und eine andere zum Analysieren der Anwendung, kann die Anwendung beschädigt werden.

Um es zusammenzufassen:

  • Verwenden Sie CultureInfo.CurrentCulture (Standard), wenn Sie eine Benutzerzeichenfolge formatieren oder analysieren.
  • Verwenden Sie CultureInfo.InvariantCulture wenn Sie eine Zeichenfolge formatieren oder analysieren, die von einer bestimmten Software analysiert werden soll.
  • Verwenden Sie selten eine bestimmte nationale Kultur, da der Benutzer nicht steuern kann, wie Formatierung und Parsing durchgeführt werden.

Laut Microsoft:

Die CultureInfo.InvariantCulture-Eigenschaft ist weder eine neutrale noch eine bestimmte Kultur. Es ist eine dritte Art von Kultur, die kulturunempfindlich ist. Es ist mit der englischen Sprache verbunden, aber nicht mit einem Land oder einer Region.

(von http://msdn.microsoft.com/en-us/library/4c5zdc6a(vs.71).aspx )

So ist InvariantCulture der Kultur “en-US” ähnlich, aber nicht genau dieselbe. Wenn du schreibst:

 var d = DateTime.Now; var s1 = d.ToString(CultureInfo.InvariantCulture); // "05/21/2014 22:09:28" var s2 = d.ToString(new CultureInfo("en-US")); // "5/21/2014 10:09:28 PM" 

dann haben s1 und s2 das Ähnlichkeitsformat, aber InvariantCulture fügt führende Nullen hinzu und “en-US” verwendet AM oder PM.

InvariantCulture ist also besser für den internen Gebrauch, wenn Sie zB ein Datum in eine Textdatei speichern oder Daten analysieren. Und eine angegebene CultureInfo ist besser, wenn Sie dem Endbenutzer Daten (Datum, Währung …) präsentieren.

Für Dinge wie Zahlen (Dezimalpunkte, Kommata in Mengen) werden sie normalerweise in der spezifischen Kultur bevorzugt.

Ein geeigneter Weg dazu wäre es auf der Kulturebene (für Deutsch) so zu setzen:

 Thread.CurrentThread.CurrentCulture.NumberFormat = new CultureInfo("de").NumberFormat; 

JetBrains bieten eine vernünftige Erklärung , aber wenn ich auf einer Seite arbeite, von der ich weiß, dass sie nur auf Englisch sein wird, ignoriere ich einfach den Vorschlag.