Co oznacza CultureInfo.InvariantCulture?

Mam taki ciąg tekstu:

var foo = "FooBar";

Chcę zadeklarować drugi wywołany ciąg bari uczynić go równym pierwszemu i czwartemu znakowi mojego pierwszego foo, więc robię to w ten sposób:

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

Działa to zgodnie z oczekiwaniami, ale ReSharper radzi mi umieścić Culture.InvariantCulturew nawiasach, więc ta linia kończy się tak:

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

Co to oznacza i czy wpłynie na sposób działania mojego programu?

Nie wszystkie kultury używają tego samego formatu dat i wartości dziesiętnych / walutowych.

Będzie to ważne dla ciebie, gdy jesteś przeliczania wartości wejściowych (odczyt) , które są przechowywane jako ciągi do DateTime, float, doublelub decimal. Będzie miało również znaczenie, jeśli spróbujesz sformatować wyżej wymienione typy danych na ciągi (zapis) do wyświetlania lub przechowywania.

Jeśli wiesz z wyprzedzeniem, jaka konkretna kultura, w której będą obowiązywały Twoje daty i wartości dziesiętne / walutowe, możesz użyć tej określonej CultureInfowłaściwości (tj CultureInfo("en-GB").). Na przykład, jeśli oczekujesz danych wejściowych użytkownika.

CultureInfo.InvariantCultureWłaściwość jest używana, jeśli formatowanie lub parsowania ciąg znaków, który powinien być parsowalnym przez kawałek oprogramowania, niezależnie od ustawień lokalnych użytkownika.

Wartość domyślna to, CultureInfo.InstalledUICulturewięc domyślna CultureInfo zależy od ustawień wykonywanego systemu operacyjnego. Dlatego zawsze powinieneś upewnić się, że informacje o kulturze pasują do twoich zamiarów (zobacz odpowiedź Martina, aby uzyskać dobrą wskazówkę).

• CultureInfo.InvariantCulture Przykład
• CultureInfo.InvariantCulture na StackOverflow
• CultureInfo.InvariantCulture Artykuł MSDN
• Wstępnie zdefiniowane nazwy CultureInfo

Gdy liczby, daty i godziny są formatowane w ciągi lub analizowane z ciągów, do określenia, jak to się robi, używana jest kultura. Na przykład w en-USkulturze dominującej masz następujące reprezentacje ciągów:

• 1000000,00 - milion z dwucyfrowym ułamkiem
• 29.01.2013 - data publikacji

W mojej kulturze ( da-DK) wartości mają następującą reprezentację ciągu:

• 1.000.000,00 - milion z dwucyfrową częścią
• 29-01-2013 - data tego nadania

W systemie operacyjnym Windows użytkownik może nawet dostosować formatowanie liczb i daty / czasu, a także może wybrać inną kulturę niż kultura jego systemu operacyjnego. Użyte formatowanie to wybór użytkownika, jaki powinien być.

Dlatego podczas formatowania wartości, która ma być wyświetlana użytkownikowi, za pomocą na przykład ToStringlub String.Formatlub przeanalizowanej z ciągu przy użyciu DateTime.Parselub, Decimal.Parsedomyślnie jest używana CultureInfo.CurrentCulture. Pozwala to użytkownikowi kontrolować formatowanie.

Jednak wiele formatowania i parsowania ciągów nie jest w rzeczywistości ciągami wymienianymi między aplikacją a użytkownikiem, ale między aplikacją a jakimś formatem danych (np. Plikiem XML lub CSV). W takim przypadku nie chcesz używać, CultureInfo.CurrentCultureponieważ jeśli formatowanie i analizowanie są wykonywane z różnymi kulturami, może się zepsuć. W takim przypadku chcesz użyć CultureInfo.InvariantCulture(który jest oparty na en-USkulturze). Dzięki temu wartości mogą być przesyłane w obie strony bez problemów.

Powodem, dla którego ReSharper ostrzega Cię, jest to, że niektórzy autorzy aplikacji nie są świadomi tego rozróżnienia, które może prowadzić do niezamierzonych wyników, ale nigdy tego nie odkryją, ponieważ ich zachowanie CultureInfo.CurrentCulturejest en-UStakie samo jak CultureInfo.InvariantCulture. Jednak gdy tylko aplikacja zostanie użyta w innej kulturze, w której istnieje możliwość użycia jednej kultury do formatowania, a innej do analizowania, aplikacja może się zepsuć.

Podsumowując:

• Użyj CultureInfo.CurrentCulture(wartość domyślna), jeśli formatujesz lub analizujesz ciąg użytkownika.
• Użyj, CultureInfo.InvariantCulturejeśli formatujesz lub analizujesz ciąg, który powinien być analizowany przez oprogramowanie.
• Rzadko używaj określonej kultury narodowej, ponieważ użytkownik nie może kontrolować sposobu formatowania i analizowania.

Według Microsoft:

Właściwość CultureInfo.InvariantCulture nie jest kulturą neutralną ani określoną. Jest to trzeci typ kultury niewrażliwy na kulturę. Jest powiązany z językiem angielskim, ale nie z krajem lub regionem.

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

Tak więc InvariantCulture jest podobna do kultury „en-US”, ale nie jest dokładnie taka sama. Jeśli napiszesz:

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"

wtedy s1 i s2 będą miały podobny format, ale InvariantCulture dodaje zera wiodące, a „en-US” używa AM lub PM.

Tak więc InvariantCulture jest lepsza do użytku wewnętrznego, kiedy np. Zapisujesz datę do pliku tekstowego lub analizujesz dane. A określony CultureInfo jest lepszy, gdy przedstawiasz dane (datę, walutę ...) użytkownikowi końcowemu.

W przypadku liczb (kropki dziesiętne, przecinki w kwotach) są one zwykle preferowane w określonej kulturze.

Odpowiednim sposobem na zrobienie tego byłoby ustawienie go na poziomie kultury (dla języka niemieckiego) w następujący sposób:

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

JetBrains oferuje rozsądne wyjaśnienie ,

„Konwersja ad-hoc struktur danych na tekst jest w dużej mierze zależna od aktualnej kultury i może prowadzić do niezamierzonych rezultatów, gdy kod jest wykonywany na maszynie, której ustawienia regionalne różnią się od ustawień oryginalnego programisty. Aby zapobiec niejasności, ReSharper ostrzega przed wszelkie przypadki w kodzie, w których może wystąpić taki problem ”.

ale jeśli pracuję w witrynie, o której wiem, że będzie tylko w języku angielskim, po prostu ignoruję sugestię.