Différence entre la culture actuelle, la culture invariante, la culture actuelle et la culture intégrée

je voudrais essayer de donner une réponse un peu plus perspicace que celui-ci .

CurrentCulture doit être utilisé pour le formatage. C'est-à-dire, les nombres, les devises, les pourcentages, les Dates et les heures devraient toujours être formaté avec cette culture avant les affichant à l'utilisateur . Quelques exemples ici:

const string CURRENCY_FORMAT = "c";
const string PERCENTAGE_FORMAT = "p";

DateTime now = DateTime.UtcNow; // all dates should be kept in UTC internally
// convert time to local and format appropriately for end user
dateLabel.Text = now.ToLocalTime().ToString(CultureInfo.CurrentCulture);

float someFloat = 12.3456f;
// yields 12,3456 for pl-PL Culture
floatLabel.Text = someFloat.ToString(CultureInfo.CurrentCulture);
// yields 12,35 zł for pl-PL Culture - rounding takes place!
currencyLabel.Text = someFloat.ToString(CURRENCY_FORMAT, CultureInfo.CurrentCulture);
// yields 1234,56% for pl-PL Culture - 1.0f is 100%
percentageLabel.Text = someFloat.ToString(PERCENTAGE_FORMAT, CultureInfo.CurrentCulture);

Une chose importante à noter est que vous ne devez jamais utiliser float ni double pour stocker des informations relatives à la monnaie en premier lieu ( decimal est le bon choix).

L'autre cas d'usage courant pour CurrentCulture est l'analyse parsing tenant compte de la localisation. Votre application devrait toujours permettre aux utilisateurs de fournir des données dans leur format régional:

float parsedFloat;
if (float.TryParse(inputBox.Text, NumberStyles.Float, CultureInfo.CurrentCulture, out parsedFloat))
{
    MessageBox.Show(parsedFloat.ToString(CultureInfo.CurrentCulture), "Success at last!");
}

veuillez noter que je fournis toujours le paramètre IFormatProvider , bien qu'il soit implicite et supposé être CultureInfo.CurrentCulture . La raison en est que je veux communiquer avec d'autres développeurs: c'est quelque chose qui sera affiché aux utilisateurs finaux. C'est une des raisons pour lesquelles FxCop traite d'omettre ce paramètre comme une erreur.

---

la culture invariante d'autre part doit être utilisée pour convertir de manière fiable l'une des classes mentionnées ci-dessus à sa représentation textuelle. Donc, si vous voulez par exemple transmettre DateTime , float , double ou un objet similaire via le réseau, le stocker dans une base de données ou une sorte de fichier texte (y compris XML), vous devez toujours utiliser InvariantCulture :

float someFloat = 1234.56f;
// yields 1234.56
string internalFloat = someFloat.ToString(CultureInfo.InvariantCulture);
DateTime now = DateTime.UtcNow;
// yields something like 04/16/2011 19:02:46
string internalDateAndTime = now.ToString(CultureInfo.InvariantCulture);

une chose à noter ici est que le format date/heure offert par InvariantCulture est en fait exactement le même qu'en-US. Bien qu'elle soit fiable, elle n'est pas exactement correcte. Ce qui devrait vraiment être utilisé est ISO8601 Interchangeables Date & Heure Format . Pour une raison quelconque Microsoft ne fournit même pas un tel modèle( les plus proches sont Modèle Sortable - "s" et modèle universel - "u" qui ne ressemble au format ISO8601), vous auriez besoin de créer votre propre comme ceci:

const string iso8601Pattern = "yyyy-MM-dd'T'HH:mm:ss'Z'";
string iso8601Formatted = now.ToString(iso8601Pattern);

très important note latérale: IFormatProvider est en fait requis ici car omettre ce paramètre peut entraîner de graves erreurs. Une fois, J'ai dû réparer un défaut du système D'exploitation Français. Le code était ainsi:

float dbVersion = // some kind of logic that took float from database
string versionString = dbVersion.ToString(); // culture-aware formatting used
Version ver = new Version(versionString); // exception thrown here

la raison en était très simple: le float formaté sur L'OS français (avec le formatage régional français) a été formaté à quelque chose comme 10,5 et la classe Version nécessite une entrée culture-invariant.

---

CurrentUICulture est responsable de charger les ressources traduisibles appropriées pour votre application. C'est-à-dire qu'il doit être utilisé pour afficher des messages texte corrects, des couleurs et des images.

En Asp.Net application si vous voulez, pour une raison ou une autre, implémenter le mécanisme de localisation CSS (possibilité de modifier les définitions CSS par langue), CurrentUICulture est une bonne façon de procéder (à condition que vous lisiez réellement cette propriété du navigateur web).

De même, si vous voulez mettre en œuvre le mécanisme de commutation de langue, CurrentUICulture est celui qui devrait être dépassé.

---

InstalledUICulture est câblé à OS UI Locale par défaut. Comme MSDN dit:

cette propriété est l'équivalent de GetSystemDefaultUILanguage dans L'API Windows.

pour réellement comprendre ce qu'est cette propriété, nous devons creuser dans une certaine théorie. Il y a différentes gammes de produits Windows:

• langue unique (c'est à dire l'anglais, le français, l'allemand, le Japonais, etc.)
• MUI (Interface Utilisateur Multilingue - anglais de base de l'OS et des Packs de Langue)

pour les gammes de produits monolingues, Installduiculture retournera toujours la langue du système D'exploitation, tandis que pour MUI il devra toujours retourner l'anglais (États-Unis) alias en-US. Est-il utile? Je ne sais pas, je n'ai jamais eu besoin d'une telle information. Et personnellement, je n'ai pas vu de programme qui a profité de cette propriété.