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.
Related
I'm quite new at C#. ReSharper warned me that using "string.IndexOf" is culture-specific. What exactly is being culture-specific?
Culture is referring to the language for example American English (en-us) and British English (en-gb) (Obviously the same language but different cultures as far as .NET is concerned). The reason it might matter when using "string.IndexOf" is because certain characters (think characters with accents and umlauts) get treated differently in different cultures. There aren't enough unicode values to represent every character in every language so within certain culture settings certain character combinations (such as an 'a' followed by an umlaut) are combined into a single character but in other culture settings they may not be. So using "string.IndexOf" on a string with an umlaut might yield different results depending on the set culture. But in most circumstances, especially if you're just learning, default behavior of the string class will be just fine.
Resharaper is a extension to follow some coding standard if any method accepting culture as a overload.then it is very good practice to provide these features in your code
comparisonType
parameter specifies to search for the value parameter using the current or invariant culture, using a case-sensitive or case-insensitive search, and using word or ordinal comparison rules.
More Info
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.
What's the difference and when to use what? What's the risk if I always use ToLower() and what's the risk if I always use ToLowerInvariant()?
Depending on the current culture, ToLower might produce a culture specific lowercase letter, that you aren't expecting. Such as producing ınfo without the dot on the i instead of info and thus mucking up string comparisons. For that reason, ToLowerInvariant should be used on any non-language-specific data. When you might have user input that might be in their native language/character-set, would generally be the only time you use ToLower.
See this question for an example of this issue:
C#- ToLower() is sometimes removing dot from the letter "I"
TL;DR:
When working with "content" (e.g. articles, posts, comments, names, places, etc.) use ToLower(). When working with "literals" (e.g. command line arguments, custom grammars, strings that should be enums, etc.) use ToLowerInvariant().
Examples:
=Using ToLowerInvariant incorrectly=
In Turkish, DIŞ means "outside" and diş means "tooth". The proper lower casing of DIŞ is dış. So, if you use ToLowerInvariant incorrectly you may have typos in Turkey.
=Using ToLower incorrectly=
Now pretend you are writing an SQL parser. Somewhere you will have code that looks like:
if(operator.ToLower() == "like")
{
// Handle an SQL LIKE operator
}
The SQL grammar does not change when you change cultures. A Frenchman does not write SÉLECTIONNEZ x DE books instead of SELECT X FROM books. However, in order for the above code to work, a Turkish person would need to write SELECT x FROM books WHERE Author LİKE '%Adams%' (note the dot above the capital i, almost impossible to see). This would be quite frustrating for your Turkish user.
I think this can be useful:
http://msdn.microsoft.com/en-us/library/system.string.tolowerinvariant.aspx
update
If your application depends on the case of a string changing in a predictable way that is unaffected by the current culture, use the ToLowerInvariant method. The ToLowerInvariant method is equivalent to ToLower(CultureInfo.InvariantCulture). The method is recommended when a collection of strings must appear in a predictable order in a user interface control.
also
...ToLower is very similar in most places to ToLowerInvariant. The documents indicate that these methods will only change behavior with Turkish cultures. Also, on Windows systems, the file system is case-insensitive, which further limits its use...
http://www.dotnetperls.com/tolowerinvariant-toupperinvariant
hth
String.ToLower() uses the default culture while String.ToLowerInvariant() uses the invariant culture. So you are essentially asking the differences between invariant culture and ordinal string comparision.
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.
Why does:
DateTime.Now.ToString("M")
not return the month number? Instead it returns the full month name with the day on it.
Apparently, this is because "M" is also a standard code for the MonthDayPattern. I don't want this...I want to get the month number using "M". Is there a way to turn this off?
According to MSDN, you can use either "%M", "M " or " M" (note: the last two will also include the space in the result) to force M being parsed as the number of month format.
What's happening here is a conflict between standard DateTime format strings and custom format specifiers. The value "M" is ambiguous in that it is both a standard and custom format specifier. The DateTime implementation will choose a standard formatter over a customer formatter in the case of a conflict, hence it is winning here.
The easiest way to remove the ambiguity is to prefix the M with the % char. This char is way of saying the following should be interpreted as a custom formatter
DateTime.Now.ToString("%M");
Why not use
DateTime.Now.Month?
You can also use System.DateTime.Now.Month.ToString(); to accomplish the same thing
You can put an empty string literal in the format to make it a composite format:
DateTime.Now.ToString("''M")
It's worth mentioning that the % prefix is required for any single-character format string when using the DateTime.ToString(string) method, even if that string does not represent one of the built-in format string patterns; I came across this issue when attempting to retrieve the current hour. For example, the code snippet:
DateTime.Now.ToString("h")
will throw a FormatException. Changing the above to:
DateTime.Now.ToString("%h")
gives the current date's hour.
I can only assume the method is looking at the format string's length and deciding whether it represents a built-in or custom format string.