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.
Related
DateTime time = DateTime.ParseExact("946AM", "hmmtt", CultureInfo.InvariantCulture);
Is there something wrong here? I have tried several different variations of the format, but this is the one I'd expect to work.
Thanks
The documentation for ParseExact contains the following note in the remarks section:
If format is a custom format pattern that does not include date or time separators (such as "yyyyMMdd HHmm"), use the invariant culture for the provider parameter and the widest form of each custom format specifier. For example, if you want to specify hours in the format pattern, specify the wider form, "HH", instead of the narrower form, "H".
You are indeed lacking separators. Worse, your data uses at least one variable-width field -- it is likely that you will need to write some of the parsing logic yourself or at least sanitize the data before passing it to ParseExact
I have a file-path that's been created from DateTime stamp:
"C:\\Logs\\Tests\\2015\\Mar\\24\\13_32_09\"
Now I am trying to convert my file-path back to DateTime object.
With Regex I can easily remove "C:\\Logs\\Tests\", but now I am assume I need to provide implementation of IFormtProvider to convert 2015\\Mar\\24\\13_32_09\ into a DateTime object, but I haven't come along any similar example of how that's usually done.
Any example, may not be particular solution to my answer, would be helpful.
Thanks
You can use DateTime.ParseExact like:
DateTime dt = DateTime.ParseExact("2015\\Mar\\24\\13_32_09\\",
#"yyyy\\MMM\\dd\\HH_mm_ss\\",
CultureInfo.InvariantCulture);
No, you don't need to create an IFormatProvider at all. The invariant culture is fine for this (assuming the month name is always in English). You can just use DateTime.ParseExact, passing in the appropriate custom format string (quoting the literal characters, either with apostrophes around them or backslashes before them):
var dateTime = DateTime.ParseExact(
text,
#"yyyy'\'MMM'\'dd'\'HH'_'mm'_'ss'\'",
CultureInfo.InvariantCulture);
Note that this assumes the path really does use backslashes... it won't work on Unix as-is. (You might want to canonicalize the directory separators first.)
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.
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.
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.