Que signifie CultureInfo.InvariantCulture?

J'ai une chaîne de texte comme ceci:

var foo = "FooBar";

Je veux déclarer une deuxième chaîne appelée baret la rendre égale au premier et au quatrième caractère de mon premier foo, donc je fais ceci comme ceci:

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

Cela fonctionne comme prévu, mais ReSharper me conseille de mettre Culture.InvariantCultureentre mes crochets, donc cette ligne se termine comme suit:

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

Qu'est-ce que cela signifie et affectera-t-il le fonctionnement de mon programme?

Toutes les cultures n'utilisent pas le même format pour les dates et les valeurs décimales / monétaires.

Ce sera important pour vous lorsque vous êtes en train de convertir des valeurs d'entrée (de lecture) qui sont stockés sous forme de chaînes à DateTime, float, doubleou decimal. Cela importera également si vous essayez de formater les types de données susmentionnés en chaînes (écriture) pour l'affichage ou le stockage.

Si vous savez à l'avance dans quelle culture spécifique vos dates et vos valeurs décimales / monétaires se trouveront, vous pouvez utiliser cette CultureInfopropriété spécifique (c'est-à-dire CultureInfo("en-GB")). Par exemple, si vous attendez une entrée utilisateur.

La CultureInfo.InvariantCulturepropriété est utilisée si vous formatez ou analysez une chaîne qui doit être analysable par un logiciel indépendant des paramètres locaux de l'utilisateur.

La valeur par défaut est CultureInfo.InstalledUICulturedonc le CultureInfo par défaut dépend des paramètres du système d'exploitation en cours d'exécution. C'est pourquoi vous devez toujours vous assurer que les informations sur la culture correspondent à votre intention (voir la réponse de Martin pour une bonne ligne directrice).

• CultureInfo.InvariantCulture, exemple
• CultureInfo.InvariantCulture sur StackOverflow
• CultureInfo.InvariantCulture Article MSDN
• Noms CultureInfo prédéfinis

Lorsque les nombres, les dates et les heures sont formatés en chaînes ou analysés à partir de chaînes, une culture est utilisée pour déterminer comment cela est fait. Par exemple, dans la en-USculture dominante , vous avez ces représentations sous forme de chaîne:

• 1,000,000.00 - un million avec une fraction à deux chiffres
• 29/1/2013 - date de l'affichage

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

• 1.000.000,00 - un million avec une fraction à deux chiffres
• 29-01-2013 - date de cet affichage

Dans le système d'exploitation Windows, l'utilisateur peut même personnaliser le formatage des nombres et des dates / heures et peut également choisir une autre culture que la culture de son système d'exploitation. La mise en forme utilisée est le choix de l'utilisateur qui doit être ainsi.

Ainsi, lorsque vous formatez une valeur à afficher pour l'utilisateur en utilisant par exemple ToStringou String.Formatou analysée à partir d'une chaîne en utilisant DateTime.Parseou, Decimal.Parsela valeur par défaut est d'utiliser leCultureInfo.CurrentCulture . Cela permet à l'utilisateur de contrôler le formatage.

Cependant, une grande partie du formatage et de l'analyse des chaînes ne sont en fait pas des chaînes échangées entre l'application et l'utilisateur mais entre l'application et certains formats de données (par exemple un fichier XML ou CSV). Dans ce cas, vous ne souhaitez pas utiliser, CultureInfo.CurrentCulturecar si le formatage et l'analyse sont effectués avec des cultures différentes, ils peuvent être interrompus. Dans ce cas, vous souhaitez utiliser CultureInfo.InvariantCulture(qui est basé sur la en-USculture). Cela garantit que les valeurs peuvent aller-retour sans problème.

La raison pour laquelle ReSharper vous avertit est que certains auteurs d'applications ne sont pas conscients de cette distinction qui peut conduire à des résultats inattendus, mais ils ne le découvrent jamais car leur CultureInfo.CurrentCultureest en-USqui a le même comportement queCultureInfo.InvariantCulture . Cependant, dès que l'application est utilisée dans une autre culture où il est possible d'utiliser une culture pour la mise en forme et une autre pour l'analyse, l'application peut être interrompue.

Donc pour résumer:

• Utilisation CultureInfo.CurrentCulture (valeur par défaut) si vous formatez ou analysez une chaîne utilisateur.
• Utilisation CultureInfo.InvariantCulture si vous formatez ou analysez une chaîne qui doit être analysable par un logiciel.
• Utilisez rarement une culture nationale spécifique car l'utilisateur est incapable de contrôler la façon dont le formatage et l'analyse sont effectués.

Selon Microsoft:

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

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

Donc InvariantCulture est similaire à la culture "en-US" mais pas exactement la même chose. 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 auront un format similaire mais InvariantCulture ajoute des zéros non significatifs et "en-US" utilise AM ou PM.

Donc InvariantCulture est meilleur pour un usage interne, lorsque vous enregistrez par exemple une date dans un fichier texte ou analysez des données. Et un CultureInfo spécifié est meilleur lorsque vous présentez des données (date, devise ...) à l'utilisateur final.

Pour des choses comme les nombres (points décimaux, virgules dans les montants), ils sont généralement préférés dans la culture spécifique.

Une manière appropriée de le faire serait de le définir au niveau de la culture (pour l'allemand) comme ceci:

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

JetBrains offre une explication raisonnable ,

"La conversion ad hoc de structures de données en texte dépend en grande partie de la culture actuelle et peut conduire à des résultats inattendus lorsque le code est exécuté sur une machine dont les paramètres régionaux diffèrent de ceux du développeur d'origine. Pour éviter les ambiguïtés, ReSharper vous avertit de toutes les instances dans le code où un tel problème peut se produire. "

mais si je travaille sur un site dont je sais qu'il sera en anglais uniquement, j'ignore simplement la suggestion.