Ce n'CultureInfo.InvariantCulture moyenne

Question

J'ai un string de texte comme ceci:

var foo = "FooBar";

Je veux déclarer un second string appelés bar et de faire de cette égalité à la première et à la quatrième caractère de mon premier foo, donc ce que je fais comme ceci:

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

Cela fonctionne comme prévu, mais ReSharper est me conseille de mettre Culture.InvariantCulture à l'intérieur de mes supports, de sorte que cette ligne se termine de la sorte:

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

Qu'est-ce que cela signifie, et elle affectera la façon dont mon programme fonctionne?

Answer 1

Pas toutes les cultures utilisent le même format pour les dates et les décimaux / de la valeur des devises.

Ce qui importe pour vous lors de la conversion des valeurs d'entrée (lire) qui sont stockés sous forme de chaînes de DateTime, float, double ou decimal. Il sera également question si vous essayez de formater les données mentionnées ci-dessus types de chaînes (write) pour l'affichage ou le stockage.

Si vous savez ce que culture spécifique que vos dates de séjour et décimal / monnaie valeurs seront à l'avance, vous pouvez utiliser le CultureInfo propriété ( CultureInfo("en-GB")).

L' CultureInfo.InvariantCulture propriété est utilisée lorsque vous ne savez pas à l'avance ce que la culture format vos dates et décimal / de la valeur des devises sera.

La valeur par défaut est CultureInfo("en-US") donc si vous travaillez exclusivement en anglais Américain, alors vous n'avez pas besoin de s'inquiéter à ce sujet.

• CultureInfo.InvariantCulture Exemple
• CultureInfo.InvariantCulture sur StackOverflow
• CultureInfo.InvariantCulture Article MSDN
• Prédéfinis CultureInfo Noms

Answer 2

Lorsque les nombres, les dates et les heures sont au format en chaînes ou analysés à partir de chaînes de caractères d'une culture est utilisée pour déterminer comment il est fait. E. g. dans la dominante en-US culture que vous avez ces représentations de chaîne:

• De 1 000 000.00 - un million à deux chiffres) fraction
• 1/29/2013 - la date de cette publication

Dans ma culture (da-DK) les valeurs ont cette représentation de chaîne:

• 1.000.000,00 - un million à deux chiffres) fraction
• 29-01-2013 - la date de cette publication

Dans le système d'exploitation Windows, l'utilisateur peut même personnaliser la façon dont les nombres et les dates/heures sont formatés et peuvent également choisir une autre culture que la culture de son système d'exploitation. La mise en forme d'utilisation est le choix de l'utilisateur, qui est la façon dont il devrait être.

Ainsi, lorsque vous formatez une valeur à afficher à l'utilisateur, par exemple, ToString ou String.Format ou analysé à partir d'une chaîne à l'aide de DateTime.Parse ou Decimal.Parse la valeur par défaut est d'utiliser l' CultureInfo.CurrentCulture. Cela permet à l'utilisateur de contrôler la mise en forme.

Toutefois, une grande partie de la chaîne de mise en forme et l'analyse est en réalité pas les chaînes échangés entre l'application et l'utilisateur, mais entre la demande et certains format de données (par exemple, un fichier XML ou CSV). Dans ce cas, vous ne voulez pas utiliser CultureInfo.CurrentCulture parce que si la mise en forme et l'analyse est effectuée avec différentes cultures, il peut casser. Dans ce cas, vous souhaitez utiliser CultureInfo.InvariantCulture (sur la base de l' en-US de la culture). Cela garantit que les valeurs peuvent aller sans problèmes.

La raison que ReSharper vous donne l'avertissement, c'est que certains écrivains sont pas au courant de cette distinction qui peut conduire à des résultats, mais ils n'ont jamais le découvrir, parce que leur CultureInfo.CurrentCulture est en-US qui a le même comportement que l' CultureInfo.InvariantCulture. Cependant, dès que l'application est utilisée dans une autre culture où il y a une chance de l'utilisation d'une culture pour la mise en forme et l'autre pour l'analyse de la demande risque de se briser.

Donc, pour résumer:

• Utiliser CultureInfo.CurrentCulture (valeur par défaut) si vous êtes à la mise en forme ou de l'analyse d'une chaîne utilisateur.
• Utiliser CultureInfo.InvariantCulture si vous êtes à la mise en forme ou de l'analyse d'une chaîne de caractères qui doit être parseable par un morceau de logiciel.
• Rarement utiliser un spécifique de la culture nationale, car l'utilisateur est incapable de contrôler la façon dont le formatage et l'analyse est effectuée.

Answer 3

Selon Microsoft:

CultureInfo.Propriété InvariantCulture n'est ni neutre, ni un culture spécifique. C'est un troisième type de culture qui est insensible culture. Il est associé à la langue anglaise, mais pas avec un pays ou une région.

(à partir de http://msdn.microsoft.com/en-us/library/4c5zdc6a(v. 71).aspx)

Donc InvariantCulture est similair à la culture "en-US", mais pas exactement le même. Si vous écrivez:

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"

alors s1 et s2 aura similair format mais InvariantCulture ajoute les zéros à gauche et "en-US" utilise de l'AM ou PM.

Donc InvariantCulture est mieux pour une utilisation à l'interne, lorsque vous e.g enregistre une date d'un fichier texte ou l'analyse des données. Et un certain CultureInfo est mieux quand vous vous présentez les données (date, devise...) à l'utilisateur final.

Answer 4

JetBrains offre raisonnable d'explication, mais si je travaille sur un site je sais qu'il sera en anglais seulement, je viens d'ignorer la suggestion.