回答1
Not all cultures use the same format for dates and decimal / currency values.
This will matter for you when you are converting input values (read) that are stored as strings to DateTime, float, double or decimal. It will also matter if you try to format the aforementioned data types to strings (write) for display or storage.
If you know what specific culture that your dates and decimal / currency values will be in ahead of time, you can use that specific CultureInfo property (i.e. CultureInfo("en-GB")). For example if you expect a user input.
The CultureInfo.InvariantCulture property is used if you are formatting or parsing a string that should be parseable by a piece of software independent of the user's local settings.
The default value is CultureInfo.InstalledUICulture so the default CultureInfo is depending on the executing OS's settings. This is why you should always make sure the culture info fits your intention (see Martin's answer for a good guideline).
回答2
When numbers, dates and times are formatted into strings or parsed from strings a culture is used to determine how it is done. E.g. in the dominant en-US culture you have these string representations:
- 1,000,000.00 - one million with a two digit fraction
- 1/29/2013 - date of this posting
In my culture (da-DK) the values have this string representation:
- 1.000.000,00 - one million with a two digit fraction
- 29-01-2013 - date of this posting
In the Windows operating system the user may even customize how numbers and date/times are formatted and may also choose another culture than the culture of his operating system. The formatting used is the choice of the user which is how it should be.
So when you format a value to be displayed to the user using for instance ToString or String.Format or parsed from a string using DateTime.Parse or Decimal.Parse the default is to use the CultureInfo.CurrentCulture. This allows the user to control the formatting.
However, a lot of string formatting and parsing is actually not strings exchanged between the application and the user but between the application and some data format (e.g. an XML or CSV file). In that case you don't want to use CultureInfo.CurrentCulture because if formatting and parsing is done with different cultures it can break. In that case you want to use CultureInfo.InvariantCulture (which is based on the en-US culture). This ensures that the values can roundtrip without problems.
The reason that ReSharper gives you the warning is that some application writers are unaware of this distinction which may lead to unintended results but they never discover this because their CultureInfo.CurrentCulture is en-US which has the same behavior as CultureInfo.InvariantCulture. However, as soon as the application is used in another culture where there is a chance of using one culture for formatting and another for parsing the application may break.
So to sum it up:
- Use
CultureInfo.CurrentCulture (the default) if you are formatting or parsing a user string.
- Use
CultureInfo.InvariantCulture if you are formatting or parsing a string that should be parseable by a piece of software.
- Rarely use a specific national culture because the user is unable to control how formatting and parsing is done.
回答3
JetBrains offer a reasonable explanation,
"Ad-hoc conversion of data structures to text is largely dependent on the current culture, and may lead to unintended results when the code is executed on a machine whose locale differs from that of the original developer. To prevent ambiguities, ReSharper warns you of any instances in code where such a problem may occur."
but if I am working on a site I know will be in English only, I just ignore the suggestion.
Ad-hoc conversion of data structures to text is largely dependent on the current culture, and may lead to unintended results when the code is executed on a machine whose locale differs from that of the original developer. To prevent ambiguities, ReSharper warns you of any instances in code where such a problem may occur.
For example, take the following code
void Test(float foo)
{
Console.WriteLine(foo.ToString()); ;
}
While one might think that a float is culture-invariant, this is in fact not the case: for example, the decimal separator can be different depending on culture. As a result, it often makes sense to specify either a specific culture (for example, the Thread.CurrentThread.CurrentCulture) or an invariant culture CultureInfo.InvariantCulture for string conversions.
Not all cultures use the same format for dates and decimal / currency values.
This will matter for you when you are converting input values (read) that are stored as strings to
DateTime,float,doubleordecimal. It will also matter if you try to format the aforementioned data types to strings (write) for display or storage.If you know what specific culture that your dates and decimal / currency values will be in ahead of time, you can use that specific
CultureInfoproperty (i.e.CultureInfo("en-GB")). For example if you expect a user input.The
CultureInfo.InvariantCultureproperty is used if you are formatting or parsing a string that should be parseable by a piece of software independent of the user's local settings.The default value is
CultureInfo.InstalledUICultureso the default CultureInfo is depending on the executing OS's settings. This is why you should always make sure the culture info fits your intention (see Martin's answer for a good guideline).When numbers, dates and times are formatted into strings or parsed from strings a culture is used to determine how it is done. E.g. in the dominant
en-USculture you have these string representations:In my culture (
da-DK) the values have this string representation:In the Windows operating system the user may even customize how numbers and date/times are formatted and may also choose another culture than the culture of his operating system. The formatting used is the choice of the user which is how it should be.
So when you format a value to be displayed to the user using for instance
ToStringorString.Formator parsed from a string usingDateTime.ParseorDecimal.Parsethe default is to use theCultureInfo.CurrentCulture. This allows the user to control the formatting.However, a lot of string formatting and parsing is actually not strings exchanged between the application and the user but between the application and some data format (e.g. an XML or CSV file). In that case you don't want to use
CultureInfo.CurrentCulturebecause if formatting and parsing is done with different cultures it can break. In that case you want to useCultureInfo.InvariantCulture(which is based on theen-USculture). This ensures that the values can roundtrip without problems.The reason that ReSharper gives you the warning is that some application writers are unaware of this distinction which may lead to unintended results but they never discover this because their
CultureInfo.CurrentCultureisen-USwhich has the same behavior asCultureInfo.InvariantCulture. However, as soon as the application is used in another culture where there is a chance of using one culture for formatting and another for parsing the application may break.So to sum it up:
CultureInfo.CurrentCulture(the default) if you are formatting or parsing a user string.CultureInfo.InvariantCultureif you are formatting or parsing a string that should be parseable by a piece of software.