CultureInfo, classe

La classe CultureInfo spécifie un nom unique pour chaque culture, basé sur la norme RFC 4646 (Windows Vista et les versions ultérieures). Le nom est une combinaison d'un code de culture à deux lettres minuscules ISO 639 associé à une langue et d'un code de sous-culture à deux lettres majuscules ISO 3166 associé à un pays ou une région.

Le format du nom de culture est "<languagecode2>-<country/regioncode2>", où <languagecode2> est le code de langue et <country/regioncode2> est le code de sous-culture. Il peut s'agir, par exemple, de ja-JP pour le japonais (Japon) et d'en-US pour l'anglais (États-Unis). Dans les cas où un code de langue à deux lettres n'est pas disponible, un code à trois lettres dérivé de la norme ISO 639-2 est utilisé.

Notez que certains noms de cultures spécifient également un script ISO 15924. Par exemple, "-Cyrl" spécifie le script cyrillique et "-Latn" spécifie le script latin. Sur Windows Vista et les versions ultérieures, un nom de culture comprenant un script peut être rendu à l'aide du modèle <languagecode2>-<scripttag>-<country/regioncode2>. uz-Cyrl-UZ pour l'ouszbek (Ouzbékistan, Cyrillique) constitue un exemple de ce type de nom de culture. Sur les systèmes d'exploitation antérieurs à Windows Vista, un nom de culture comprenant un script est rendu à l'aide du modèle <codelangue2>-<pays/coderégional2>-<balisescript>, par exemple, uz-UZ-Cyrl pour l'ouzbek (Ouzbékistan, Cyrillique).

Une culture neutre est spécifiée par le seul code de langue à deux lettres minuscules. Par exemple, "fr" spécifie la culture neutre pour le français, et "de" spécifie la culture neutre pour l'allemand.

Remarque
Il y a deux noms de cultures qui contredisent cette règle. Les cultures Chinois simplifié (zh-Hans) et Chinois traditionnel (zh-Hant) sont des cultures neutres. Les noms de cultures représentent la norme actuelle et doivent être utilisés à moins que vous n'ayez une raison pour utiliser les noms plus anciens "zh-CHS" et "zh-CHT".

Un identificateur de culture est une abréviation numérique internationale standard et a les composants nécessaires pour identifier uniquement l'une des cultures installées. Votre application peut utiliser des identificateurs de culture prédéfinis ou définir des identificateurs personnalisés.

Certains noms et identificateurs de cultures prédéfinis sont utilisés par cette classe et d'autres classes de l'espace de noms System.Globalization. Des informations détaillées relatives à la culture sont indiquées dans Référence de l'API NLS (National Language Support) du Centre de développement sur la globalisation.

Souvenez-vous que les noms de culture et les identificateurs représentent uniquement un sous-ensemble des cultures qui se trouvent sur un ordinateur particulier. Les versions de Windows ou des Service Packs peuvent modifier les cultures disponibles. Les applications ajoutent des cultures personnalisées à l'aide de la classe CultureAndRegionInfoBuilder. Les utilisateurs ajoutent leurs propres cultures personnalisées à l'aide de l'outil Générateur de paramètres régionaux de Microsoft. Le Générateur de paramètres régionaux de Microsoft est écrit en code managé à l'aide de la classe CultureAndRegionInfoBuilder.

Plusieurs noms distincts sont étroitement associés à une culture, notamment les noms associés aux membres de classe suivants :

• CultureInfo.ToString

• CultureInfo.Name

• CompareInfo.Name

Pour obtenir une description de la relation entre ces noms, consultez Noms associés à un objet CultureInfo.

Les cultures sont généralement regroupées en trois jeux : les cultures dites indifférentes, les cultures neutres et les cultures spécifiques.

Une culture dite indifférente ne tient pas compte de la culture. Votre application spécifie la culture indifférente par son nom à l'aide d'une chaîne vide ("") ou par son identificateur. InvariantCulture définit une instance de la culture indifférente. Elle est associée à la langue anglaise, mais n'est associée à aucun pays/à aucune région. Elle est utilisée dans quasiment n'importe quelle méthode de l'espace de noms Globalization requérant une culture.

Une culture neutre est associée à une langue, mais elle n'est associée à aucun pays/à aucune région. En revanche, une culture spécifique est associée à la fois à une langue et à un pays ou une région. Par exemple, fr est le nom neutre pour la culture française, et fr-FR est le nom de culture spécifique Français (France). Notez que Chinois (simplifié) et Chinois (traditionnel) sont également considérés comme étant des cultures neutres.

Il est déconseillé de créer une instance d'une classe CompareInfo pour une culture neutre car les données qu'elle contient sont arbitraires. Pour afficher et trier des données, spécifiez la langue et la région. Par ailleurs, la propriété Name d'un objet CompareInfo créée pour une culture neutre retourne uniquement le pays et n'inclut pas la région.

Les cultures définies ont une hiérarchie dans laquelle le parent d'une culture spécifique est une culture neutre et le parent d'une culture neutre est la culture dite indifférente. La propriété Parent contient la culture neutre associée à une culture spécifique. Les cultures personnalisées doivent définir la propriété Parent en conformité avec ce modèle.

Si les ressources d'une culture spécifique ne sont pas disponibles dans le système d'exploitation, les ressources de la culture neutre associée sont utilisées. Si les ressources de la culture neutre ne sont pas disponibles, les ressources incorporées dans l'assembly principal sont alors utilisées. Pour plus d'informations sur le processus de secours pour les ressources, consultez Empaquetage et déploiement de ressources.

La liste des paramètres régionaux dans l'API Windows est légèrement différente de la liste des cultures prises en charge par le .NET Framework. Si l'interopérabilité avec Windows est nécessaire, par exemple, via le mécanisme p/invoke, l'application doit utiliser une culture spécifique définie pour le système d'exploitation. L'utilisation de la culture spécifique garantit la cohérence avec les paramètres régionaux Windows équivalents, identifiés par un identificateur de paramètres régionaux identique à LCID.

DateTimeFormatInfo ou NumberFormatInfo ne peut être créé que pour la culture dite indifférente ou pour des cultures spécifiques, et non pour des cultures neutres.

Si DateTimeFormatInfo.Calendar est TaiwanCalendar mais que Thread.CurrentCulture n'est pas "zh-TW", alors DateTimeFormatInfo.NativeCalendarName, DateTimeFormatInfo.GetEraName et DateTimeFormatInfo.GetAbbreviatedEraName retournent une chaîne vide ("").

Lorsque vous préparez le logiciel pour gérer des cultures personnalisées, considérez les éléments suivants :

• Les cultures personnalisées peuvent avoir des valeurs qui dépassent les plages des cultures livrées par Microsoft. Par exemple, certaines cultures ont des noms de mois exceptionnellement longs, des formats de date ou d'heure inattendus ou d'autres données exceptionnelles.

• Respectez les valeurs de données de culture de l'utilisateur ; par exemple, l'utilisateur peut souhaiter une horloge au format de 24 heures ou un format de date aaaaMMjj.

• Souvenez-vous que les cultures personnalisées substituent les valeurs par défaut. Par conséquent, vous ne pouvez pas considérer les données de culture comme des données stables. Les noms de pays, formats de date, orthographes, etc., risquent d'être modifiés dans le futur. Si votre application doit sérialiser en utilisant ces données, comme pour les fonctions de DateTime mise en forme et d'analyse, elle doit utiliser la culture dite indifférente ou un format spécifique.

Excepté pour la culture dite indifférente, les données de culture sont dynamiques. Cela est vrai même pour les cultures prédéfinies. Par exemple, lorsque des pays ou des régions adoptent de nouvelles devises, modifient l'orthographe de leurs mots ou modifient leur calendrier par défaut, les définitions de culture changent pour refléter ces modifications. Les cultures personnalisées peuvent faire l'objet de modifications sans préavis, et toute culture spécifique peut être substituée par une culture personnalisée de remplacement. En outre, comme indiqué ci-dessous, un utilisateur individuel peut substituer des préférences culturelles. Les applications doivent toujours obtenir les données de culture au moment de l'exécution.

Attention
Lors de l'enregistrement des données, votre application doit utiliser la culture indifférente, un format binaire ou un format spécifique indépendant de la culture. Les données enregistrées en fonction des valeurs actuelles associées à une culture particulière (autre que la culture dite indifférente) peuvent devenir illisibles ou changer de signification si cette culture change.

Lorsqu'un objet CultureInfo est sérialisé, tout ce qui est réellement stocké est Name et UseUserOverride. Il est désérialisé avec succès uniquement dans un environnement où Name a la même signification. Les trois exemples suivants illustrent pourquoi ce n'est pas toujours le cas :

• Si CultureTypes indique CultureTypes.WindowsOnlyCultures et si cette culture a été introduite initialement dans Windows Vista, il n'est pas possible de le désérialiser sur Windows XP. De même, si la culture a été introduite initialement dans le Service Pack 2 Windows XP, il n'est pas possible de le désérialiser dans un système Windows XP sur lequel la culture n'a pas été installée.

• Si CultureTypes indique CultureTypes.UserCustomCulture et si cette culture personnalisée par l'utilisateur n'est pas installée sur l'ordinateur où il est désérialisé, il n'est pas possible de le désérialiser.

• Si CultureTypes indique CultureTypes.ReplacementCultures et si cette culture de remplacement ne se trouve pas sur l'ordinateur où il est désérialisé, il est désérialisé sous le même nom, mais pas avec toutes les mêmes caractéristiques. Par exemple, si "en-US" est une culture de remplacement sur l'ordinateur A, mais pas sur l'ordinateur B, et si un objet CultureInfo qui fait référence à cette culture, est sérialisé sur l'ordinateur A et désérialisé sur l'ordinateur B, aucune des caractéristiques personnalisées de la culture n'est alors transmise. La culture est désérialisée avec succès, mais avec une signification différente.

À partir de la version 2.0 du .NET Framework, le constructeur CultureInfo prend en charge l'utilisation des paramètres régionaux Windows, qui sont équivalents aux cultures, pour générer automatiquement des cultures qui n'existent pas dans le .NET Framework. Pour plus d'informations, consultez Cultures générées à partir de paramètres régionaux Windows.

L'utilisateur peut choisir de substituer certaines des valeurs associées à la culture Windows en cours par le biais des options régionales et linguistiques du Panneau de configuration. Ainsi, il peut modifier le format d'affichage des dates ou utiliser une devise autre que la devise par défaut de la culture. Vos applications doivent généralement honorer ces substitutions par l'utilisateur.

Si UseUserOverride a la valeur true et si la culture spécifiée correspond à la culture actuelle de Windows, CultureInfo utilise ces substitutions, notamment les paramètres utilisateur pour les propriétés de l'instance de DateTimeFormatInfo retournée par la propriété DateTimeFormat et les propriétés de l'instance de NumberFormatInfo retournée par la propriété NumberFormat. Si les paramètres utilisateur ne sont pas compatibles avec la culture associée à CultureInfo par exemple, si le calendrier sélectionné n'est pas l'un des OptionalCalendars, les résultats des méthodes et les valeurs des propriétés ne sont pas définis.

Pour les cultures qui utilisent l'euro, le .NET Framework et Windows XP définissent l'euro comme devise par défaut. Toutefois, les versions antérieures de Windows ne le font pas. Par conséquent, la devise risque d'être incorrecte si l'utilisateur d'une version antérieure de Windows ne modifie pas la devise par le biais des options régionales et linguistiques du Panneau de configuration. Pour utiliser la devise par défaut du .NET Framework, l'application doit utiliser une surcharge du constructeur CultureInfo acceptant un paramètre useUserOverride et avec la valeur false.

La culture espagnole (Espagne) utilise deux identificateurs de culture, 0x0C0A qui utilise l'ordre de tri international par défaut, et 0x040A qui utilise l'ordre de tri traditionnel. Si CultureInfo est construit à l'aide du nom de culture es-ES, le nouveau CultureInfo utilise l'ordre de tri international par défaut. Pour l'ordre de tri traditionnel, l'objet est construit en utilisant le nom es-ES_tradnl. Pour plus d'informations sur les autres cultures qui utilisent des tris de substitution, consultez Comparaison et tri des données pour une culture spécifique.

Cette classe implémente l'interface ICloneable pour activer la duplication d'objets CultureInfo. Elle implémente aussi IFormatProvider pour fournir les informations de mise en forme aux applications.

Vous devez tenir compte de considérations uniques lorsque vous utilisez un thread associé à un objet CultureInfo. Pour plus d'informations sur les cultures et les domaines d'application, consultez Domaines d'application et threads.