ToString(“0”) par rapport à ToString(CultureInfo.InvariantCulture)
Je voudrais faire en sorte que certains numéros dans mon application sont imprimées sans séparateurs, groupements, etc. peu importe ce que l'environnement actuel. Il semble que l'une des deux méthodes suivantes produisent le même résultat (il y a peut-être plus):
123456789.ToString("0");
123456789.ToString(CultureInfo.InvariantCulture);
Connaissez-vous des cas limites ou défauts? Lequel est le plus "correct"? Laquelle aimeriez-vous utiliser?
J'ai utilisé la deuxième, mais récemment, j'ai trouvé le premier et commencé à l'utiliser car il ne nécessite pas la supplémentaires using System.Globalization
.
OriginalL'auteur Jan Zich | 2009-09-28
Vous devez vous connecter pour publier un commentaire.
Sur la base des réponses et la discussion ici, j'ai fait un peu plus d'enquête. Voici ce que j'ai trouvé:
Lorsque vous utilisez
12345678.ToString()
sans aucun argument .NET utilise général de la général spécificateur de format "G" qui est affectée par NumberFormatInfo.NegativeSign, NumberFormatInfo. NumberDecimalSeparator, NumberFormatInfo.NumberDecimalDigits et NumberFormatInfo.PositiveSign. Pour moi, cela dit que dans n'importe quelle culture12345678.ToString()
produisent toujours "12345678".Si vous voulez séparer les chiffres, vous devez utiliser le numérique spécificateur de format "N" (ou, bien sûr, de fournir une chaîne de format personnalisée). Le groupement des chiffres s'applique également aux "C" et "P".
La invariant de la culture ne en effet spécifier de groupement des chiffres (par 3 chiffres, bien sûr) et un chiffre séparateur. Donc, la raison qui
123456789.ToString(CultureInfo.InvariantCulture)
produit "123456789" n'est pas en raison de l'invariant de la culture, mais c'est à cause du défaut général numérique spécificateur de format "G".Je dirais donc que la conclusion est qu'il est parfaitement OK ne vous inquiétez pas sur argument supplémentaire et il suffit d'utiliser:
Je pense que c'est le meilleur de tous les cas, car cela signifie généralement que vous n'avez pas besoin d'appeler
ToString()
parce que la plupart de l'impression/écriture des fonctions acceptent toutes sortes d'arguments et de faire leToString()
pour vous.OriginalL'auteur Jan Zich
Les deux méthodes ne sont pas équivalentes: la première est l'aide de l'CurrentCulture. Cela pourrait entraîner un surcroît de points virgules dans certaines cultures (je n'ai pas d'exemples).
Lorsque vous utilisez InvariantCulture vous êtes certain que toujours la même mise en forme est utilisée.
Edit: Et, si vous utilisez CodeAnalysis, qui va se plaindre lorsque vous n'utilisez pas un CultureInfo.
Mais vous avez raison: InvariantCulture "sonne" plus explicite. Même MSDN dit "... il est associé à la langue anglaise, mais pas avec n'importe quel pays/région". Hmm, quand j'y pense plus, ToString(CultureInfo.InvariantCulture), cela signifie que le nombre si formaté à l'aide de la "G". Tout juste arrive à travailler UNIQUEMENT parce que "G" ne semble pas être l'aide d'un groupe quelconque. MAIS (j'ai juste regardé) l'invariant de la culture a certains regroupements spécifié. Par exemple, essayez de 12345789.ToString("N", CultureInfo.InvariantCulture).
OriginalL'auteur Hans Kesting
Comme je le vois, Le premier format est un nombre avec au moins un caractère à l'aide de la culture par défaut de l'ordinateur.
La deuxième forme comme un certain nombre en fonction de la InvariantCulture règles.
Bobby
Euh...il n'a vraiment pas. J'ai confondu avec une mise en forme de symbole comme "N0", qui fait appliquer les règles de la culture. Vous avez raison, puisque le 0 est une mise en forme directe, il ne s'applique pas aucun de la culture de l'information. Cependant, quelqu'un pourrait également utiliser 123456789.ToString(); .
OriginalL'auteur Bobby
(~5 ans plus tard...)
J'étais à la recherche de cette question exacte, mais puisqu'il n'y a pas de réponse, et même si Jan Zich est correct j'ai pensé que je voudrais mettre en place un petit exemple pour tester cela.
Je voudrais aussi aller jusqu'à dire qu'il n'y a pas de différence entre les deux .ToString(), .ToString("0"), et .ToString(Toute Info Culture) (autant que les entiers et les décimaux sont concernés)
LinqPad extrait de
OriginalL'auteur XenoPuTtSs
2 lignes de faire des choses différentes. La première ligne formats le nombre à la culture locale, et la seconde le convertit en chaîne, sans mise en forme, mais en utilisant CultureInfo.InvariantCulture.
Vous utilisez CultureInfo.InvariantCulture avec ce genre de méthodes (ToString, ToLower ...), à faire en sorte que quand la valeur est utilisée par n'importe quel logiciel (base de données, d'une autre bibliothèque ...), quel que soit leur culture est, il y aura la même valeur et quand ils peuvent ramasser cette valeur, ils peuvent poursuivre le traitement. Toutefois, si vous ne l'utilisez pas cet les autres logiciels est de comprendre ce que votre culture est. Vouliez-vous dire séparateur décimal à virgule ou autre chose ... ?
À toutes et à tous d'utiliser CultureInfo.InvariantCulture lorsque vous souhaitez échanger/valeurs d'usage entre les bibliothèques, les bases de données et l'utilisation CultureInfo.CurrentCulture pour montrer aux utilisateurs de votre application.
OriginalL'auteur Gokce Mutlu
La .ToString() et .ToString(CultureInfo.InvariantCulture) toujours donner le même résultat pour les entiers.
Le code ci-dessous donne "809 cultures testées, 0 différences" résultat sur mon PC:
OriginalL'auteur Vlad Rudenko
Si vous êtes désireux de vous assurer de spécifier "pas de mise en forme, n'importe quel" personnellement, je pense que la première option que vous avez:
mieux communique l'intention. L'inconvénient serait le cas d'une culture de l'emportait sur la chaîne de format de "0" pour le type numérique que vous utilisez.
Êtes-vous sûr de la surcharge? MSDN (msdn.microsoft.com/en-us/library/dwhawy9k.aspx) dit: "n'Importe quel caractère [que l'une de celles standard] jette un FormatException au moment de l'exécution."
Je n'étais pas sûr que ce soit le cas ou pas. Je vois un rapide voyage à la bibliothèque MSDN aurait montré moi :).
OriginalL'auteur Nicolas Webb