Pourquoi le séparateur de groupe de numéros de culture «de-CH» .NET est-il différent localement et sur Azure?
Je vois un caractère Unicode différent comme séparateur de groupe de nombres pour la culture «de-CH» lors de l'exécution sur un bureau local et dans Azure.
Lorsque le code suivant est exécuté sur mon bureau dans .NET Core 3.1 ou .NET Framework 4.7.2, il génère ce 2019
qui ressemble à une apostrophe mais n'est pas le même.
Lorsqu'il est exécuté dans Azure, par exemple dans https://try.dot.netou (légèrement modifié) dans une fonction Azure exécutée sur .NET Core 3.1 (sur un App Service Windows) il en résulte 0027
, une apostrophe ASCII standard.
using System;
using System.Linq;
using System.Globalization;
Console.WriteLine(((int)(CultureInfo
.GetCultureInfo("de-CH")
.NumberFormat
.NumberGroupSeparator
.Single())) // Just getting the single character as an int
.ToString("X4") // unicode value of that character
);
Le résultat de ceci est que la tentative d'analyse de la chaîne 4'200.000
(où l'apostrophe est Unicode 0027
) sur le bureau local à l'aide de la culture «de-CH» échoue, mais cela fonctionne dans Azure.
Pourquoi la différence?
Réponses
Ce blog Microsoft de Shawn Steele explique pourquoi vous ne devriez pas vous fier à la stabilité d'un paramètre de culture spécifique (entièrement cité car il n'est plus en ligne sur MSDN):
https://web.archive.org/web/20190110065542/https://blogs.msdn.microsoft.com/shawnste/2005/04/05/culture-data-shouldnt-be-considered-stable-except-for-invariant/
Les données CultureInfo et RegionInfo représentent une préférence culturelle, régionale, administrative ou utilisateur pour les paramètres culturels. Les applications ne doivent PAS faire d'hypothèses reposant sur la stabilité de ces données. La seule exception (c'est une règle, donc bien sûr il y a une exception) est pour CultureInfo.InvariantCulture. CultureInfo.InvariantCulture est censé rester stable, même entre les versions.
Il existe de nombreuses raisons pour lesquelles les données culturelles peuvent changer. Avec Whidbey et Custom Cultures, la liste s'allonge un peu.
- La raison la plus évidente est qu'il y a un bogue dans les données et que nous avons dû faire un changement. (Croyez-le ou non, nous faisons des erreurs ;-)) Dans ce cas, nos utilisateurs (et les vôtres aussi) veulent des données culturellement correctes, nous devons donc corriger le bogue même s'il casse les applications existantes.
- Une autre raison est que les préférences culturelles peuvent changer. Cela peut se produire de nombreuses façons, mais cela arrive:
- La prise de conscience mondiale, les échanges interculturels, le rôle changeant des ordinateurs, etc. peuvent tous avoir un effet sur une préférence culturelle.
- Les traités internationaux, le commerce, etc. peuvent changer les valeurs. L'adoption de l'euro a changé le symbole monétaire de nombreux pays en €.
- Les réglementations nationales ou régionales peuvent également avoir un impact sur ces valeurs.
- L'orthographe préférée des mots peut changer avec le temps.
- Les formats de date préférés, etc. peuvent changer.
- Plusieurs préférences peuvent exister pour une culture. Le meilleur choix préféré peut alors changer avec le temps.
- Les utilisateurs peuvent avoir remplacé certaines valeurs, telles que les formats de date ou d'heure. Celles-ci peuvent être demandées sans remplacement utilisateur, mais nous recommandons aux applications d'envisager d'utiliser les remplacements utilisateur.
- Les utilisateurs ou les administrateurs peuvent avoir créé une culture de remplacement, remplaçant les valeurs par défaut communes d'une culture par des variations spécifiques à l'entreprise, régionales ou autres des données standard.
- Certaines cultures peuvent avoir des préférences qui varient en fonction du contexte. Une entreprise peut avoir une forme plus formelle qu'un café Internet.
- Une entreprise peut exiger un format de date ou d'heure spécifique pour l'ensemble de l'organisation.
- Différentes versions de la même culture personnalisée, ou une culture personnalisée sur une machine et une culture Windows uniquement sur une autre machine.
Donc, si vous formatez une chaîne avec un format de date / heure particulier, puis essayez de l'analyser plus tard, l'analyse peut échouer si la version a changé, si la machine a changé, si la version du framework a changé (données plus récentes), ou si une culture personnalisée a été changé. Si vous devez conserver les données dans un format fiable, choisissez une méthode binaire, fournissez votre propre format ou utilisez InvariantCulture.
Même sans modifier les données, se rappeler d'utiliser Invariant est toujours une bonne idée. Si vous avez différent. et, syntaxe pour quelque chose comme 1,000.29, alors l'analyse peut devenir confuse si un client attendait 1.000,29. J'ai vu ce problème avec des applications qui ne savaient pas que la culture d'un utilisateur serait différente de la culture du développeur. L'utilisation d'Invariant ou d'une autre technique résout ce genre de problème.
Bien sûr, vous ne pouvez pas avoir à la fois un affichage "correct" pour l'utilisateur actuel et un aller-retour parfait si les données de culture changent. Donc, en général, je recommande de conserver les données en utilisant InvariantCulture ou un autre format immuable, et toujours en utilisant les API de mise en forme appropriées pour l'affichage. Votre application aura ses propres exigences, alors considérez-les attentivement.
Notez que pour le classement (ordre de tri / comparaisons), même le comportement invariant peut changer. Vous devrez utiliser la gestion des versions de tri pour contourner ce problème si vous avez besoin d'ordres de tri stables et cohérents.
Si vous avez besoin d'analyser automatiquement des données formatées pour être conviviales, il existe deux approches:
- Autorisez l'utilisateur à spécifier explicitement le format utilisé.
- Supprimez d'abord tous les caractères sauf les chiffres, le signe moins et le séparateur décimal de la chaîne avant d'essayer d'analyser cela. Notez que vous devez d'abord connaître le séparateur décimal correct. Il n'y a aucun moyen de le deviner correctement et une mauvaise estimation pourrait entraîner des problèmes majeurs.
Dans la mesure du possible, essayez d'éviter d'analyser les nombres qui sont formatés pour être conviviaux. Au lieu de cela, chaque fois que possible, essayez de demander des nombres dans un format strictement défini (invariant).