So I have the following line of code :
Single xFreq = Convert.ToSingle(param, CultureInfo.InvariantCulture);
Variable param is a System.Object Any reason the result is not the same if the "," separator is used instead of the "."? For example 0.45 is converted correctly but 0,45 is converted to 45... This thing keeps bugging me for the last hour...
Not sure what your question is since you explicitly specifying InvariantCulture for parsing the string value - hence "." is used as separator.
You need to specify CultureInfo that matches your input. Generally to parse user input you need to use current culture. If input comes from some other source you have to know what culture it was serialized with.
Because the decimal separator is Culture dependent, as other posts clarified, for InvariantCulture it's "." (CultureInfo.InvariantCulture.NumberFormat). You can look at the NumberFormatInfo article for more details regarding other separators for number types.
Invariant culture converts from and to "." like a separator. Instead the string you converting from is not in in ariant culture format, hou need specify string's culture.
Thd basic technique in this case could be to STORE in invariant culture, but show to user what he wants like a separator, so you will get rid of any culture dependent problem and user will happy to see what he likes to see.
Regards.
Related
I have strange situation, when I use API. I get object in JSON, which I deserialize. This object contains string property which is parsed to decimal.
To do this I use this code. I live in Poland where decimal separator is ',', so I use replace method.
string input ="160.00"; //value from API
decimal result;
decimal.TryParse(input.Replace('.',','), out result);
From time to time I result is equals 16000!! (I suppose TryParse method delete separator, it not determined).
How can I prevent this situation? Can I parse
Numbers should be serialized as InvariantCulture anyway so the InvariantCulture for parsing is a good start. The code serializing the numbers should also be checked whether it follows this rule.
string input ="160.00";
decimal result = decimal.Parse(
input,
System.Globalization.CultureInfo.InvariantCulture);
Not serializing numbers as culture invariant is one of the most common source of problems like it runs on my machine I have no idea why it doesn't on yours... oh you say your system is in a different language oops ;-)
Instead of replacing decimal point character you should be using a proper overload of TryParse method, i.e. decimal.TryParse(String, NumberStyles, IFormatProvider, Decimal):
string input ="160.00";
NumberStyles style = NumberStyles.Number;
decimal number = 0;
CultureInfo culture = CultureInfo.CreateSpecificCulture("en-US");
decimal.TryParse(input, style, culture, out number)
Make sure to specify the correct culture which is suitable for your case.
I have some code that is logging a timestamp in format from a thick client app
DateTime.UtcNow.ToString("MM/dd/yy HH:mm:ss")
Now, on a client running in China (not sure exactly which locale) this is producing a date in the log with the format
11-20-13 02:14:03
I notice it's using - instead of / to delimit the parts, even though I explicitly wanted /
I tried to set the current culture to Chinese simplified zh-CN but I wasn't able to reproduce how the remote client was able to produce that string
Does current culture locale affect the output of this format string? Or does / have some other meaning I'm not aware of?
Yes, the / character is a placeholder for whatever the current culture uses to separate parts of the date. From MSDN:
The "/" custom format specifier represents the date separator, which is used to differentiate years, months, and days. The appropriate localized date separator is retrieved from the DateTimeFormatInfo.DateSeparator property of the current or specified culture.
As with other format specifiers, you can escape the / with a \:
DateTime.UtcNow.ToString(#"MM\/dd\/yy HH\:mm\:ss")
Or specify an explicit culture when formatting the string:
DateTime.UtcNow.ToString("MM/dd/yy HH:mm:ss", CultureInfo.InvariantCulture)
Yes, that's how it works. / is being replaced with the local date separator. The same applies to : as a time separator. You can find more on MSDN: Custom Date and Time Format Strings.
To change that, escape them with \:
DateTime.UtcNow.ToString(#"MM\/dd\/yy HH\:mm\:ss")
ASP.NET MVC doesn't bind "1.5" double value(because invalid format for current culture). So i am trying to parse it manualy for current culture.
My solution is replacing "1.5" float point with valid float seperator for current culture.
How can i replace float seperator by valid seperator in current culture ?
Do you have better solution for it ?
Just specify which culture you want to use when parsing:
CultureInfo culture = new CultureInfo(Request.UserLanguages[0]);
return double.Parse("1.5", culture.NumberFormat);
See the documentation for more detail.
If you just want to have "1.5" parse no matter the culture, try this:
var culture = System.Globalization.CultureInfo.GetCultureInfo("en-US");
Double.Parse("1.5", culture.NumberFormat);
That creates an instance of the en-US culture and tells the parser to use it in this specific case.
I have a string, that could look like "123,34", "123123,09", "1234", "123.34", "123123.09"
(Stringrepresentation of 10,2 decimal that will be stored into a MySql DB)
Due to the culture of the ASP.net thread may differ, because my application supports localization, I need to find a safe way to convert the most likely user input into a decimal.
How is that possible?
I tried various Decimal.Parse attemps, that all failed so far.
Solution:
My final solution was a mixed one. I used string replace to ensure my date is formatted into the specified CultureInfo I used for parsing
You should read current Culture Info
and than you could
//CultureInfo culture = new CultureInfo("en-US");
Convert.ToDecimal(value, System.Globalization.CultureInfo.CurrentCulture)
Decimal.Parse is the way to go but you need the particular overload that incorporates localisation, Decimal.Parse Method (String, IFormatProvider).
Once the decimal is turned into a string, there is really no foolproof way of telling which culture formatting was used to format it.
You have two options :
Record the formatting culture used and pass that back with the string, then use that for the appropriate decimal.Parse(string, IFormatProvider)
Perform the parse at the UI level (where the culture is known) and pass the value back as a decimal type.
Decimal.Parse (String, IFormatProvider)
where IFormatProvider is culture-specific format for your strings
Convert your string with the InvariantCulture
Decimal.parse(yourstring,System.Globalization.CultureInfo.InvariantCulture);
Thought you might get some weird results if your string is not compatible with the cultureinfo of the system.
I have some Excel data including an Excel column I created programatically in sql table my excel column on the other hand. One of the column's name's is mydetail. When I try to convert it to uppercase I get MYDETAİL. How do I use the ToUpper() method to obtain MYDETAIL not MYDETAİL?
I'm guessing that you are Turkish, or at least using a Turkish computer.
In Turkish the "i" does convert to "İ" in upper case.
You need to use a different culture when doing the conversion by using String.ToUpper method that takes an CultureInfo object as an argument. If you use en-US or en-GB you should get what you want.
In fact the example on the page I linked to uses en-US and tr-TR (Turkey-Turkish) on the word "indigo" as an example of the differences.
Try something like:
String result = source.ToUpper(CultureInfo.InvariantCulture);
From MSDN:
use the InvariantCulture to ensure that the behavior will be consistent regardless of the culture settings of the system
You will need to call .ToUpper() with the desired CultureInfo. See MSDN with some examples on how to use .ToUpper(CultureInfo).
It is recommended to specify CultureInfo on all String manipulation methods like String.Format(), <primitive>.ToString() or for example Convert.Int32(object, CultureInfo).
FxCop does a good job in reminding you on issues with this in your code.