Culture-Insensitive String Operations
The culture-sensitive string operations described in the topiccan be an advantage to developers creating applications designed to display results to users on a per-culture basis. By default, culture-sensitive methods obtain the culture to use from the current thread's property. For more information about how this property is set, see . However, culture-sensitive string operations are not always the desired behavior. Using culture-sensitive operations in scenarios where results should be independent of culture can cause code to fail on cultures with .
Whether string operations should be culture-sensitive or culture-insensitive depends on how the application uses the results. String operations that display results to the end user should typically be culture-sensitive. For example, if an application displays a sorted list of localized strings in a list box to the user, you should perform a culture-sensitive sort. Results of string operations that are used internally should typically be culture-insensitive. In general, if you are working with file names, persistence formats, or symbolic information that is not displayed to the end user, results of string operations should not vary by culture. For example, if an application compares a string to determine whether it is a recognized XML tag, the comparison should not be culture-sensitive. In addition, if a security decision is based on the result of a string comparison or case change operation, the operation should be culture-insensitive to ensure that the result is not affected by the value of CultureInfo.CurrentCulture.
Regardless of whether you are developing an application that includes code to handle localization and globalization issues, you should be aware of the .NET Framework methods that return culture-sensitive results by default. The purpose of this topic is to illustrate the correct way to use these methods when you want to obtain culture-insensitive results.