Important InvariantCulture in CultureInfo

Brief Introduction to CultureInfo

The CultureInfo class is located in System. in the Globalization namespace, this class and many people in this namespace do not know much and do not need to know much about it. In fact, these classes are often used indirectly in programs you write.

To put it simply: When a number, date, time, or string match is performed, the results of these operations may be different under different CultureInfo operations. Here we will introduce InvariantCulture, which is very easy to ignore.

 

Learn about InvariantCulture through examples

As mentioned above, different CultureInfo will affect the execution results of some functions ,. NET has a special CultureInfo: InvariantCulture, which is a bit like the English format, but it is not linked to the country, it can provide a reliable standard format in a multi-language environment.

For example, how do you write a program that transmits some time data to the data center server? Direct DateTime. ToString ()? Then you are very wrong. The following code is used to give a very vivid example. In the console, simulate the data center, and then release multiple threads to simulate the client program to transfer data.

Static readonly string [] CultureSources = {"en-us", "zh-cn", "ar-iq", "de-de "}; </p> <p> static readonly Random Ran = new Random (Environment. tickCount); </p> <p> static void Main () </p> <p >{</p> <p> Console. writeLine ("the data center starts to accept client data:"); </p> <p> for (int I = 0; I <CultureSources. length; I ++) </p> <p> ThreadPool. queueUserWorkItem (Client, I); </p> <p> Console. readKey (true); </p> <p> Console. writeLine (""); </p> <p> Console. WriteLine ("Data Center :............ "); </P> <p >}</p> <p> static void Client (object obj) </p> <p >{</p> <p> int id = (int) obj; </p> <p> Thread. sleep (Ran. next (1000); </p> <p> CultureInfo cul = CultureInfo. getCultureInfo (CultureSources [id]); </p> <p> Thread. currentThread. currentCulture = cul; </p> <p> Console. writeLine ("a client operating system language settings {0} \ n transfer data: {1} \ n", cul. displayName, new DateTime (1990, 10, 27 ). toShortDateString (); </p> <p>}

Running result:

The result is displayed, the same DateTime. tow.datestring (), in different English-US, Chinese-China, Arabic-Iraq and German-Germany environments, the output results in October 27, 1990 were so different, what makes the data center Server feel like ......

The reason has already been mentioned. During the date and time output ,. NET will consider the current Thread's CultureInfo, that is, Thread. currentThread. currentCulture (or CultureInfo. currentCulture), and according to the CultureInfo, the corresponding regional culture data processing. Do not confuse it with UICulture.

The solution is to use this special InvariantCulture.

Change the output code

Console. writeLine ("a client operating system language settings {0} \ n transfer data: {1} \ n", cul. displayName, </p> <p> new DateTime (1990, 10, 27 ). toString (</p> <p> CultureInfo. invariantCulture. dateTimeFormat. shortDatePattern, CultureInfo. invariantCulture ));

In this way, regardless of the language in which the client runs, the output time format is uniform, and the data center server will process the data later.

(Of course, this example is only used to demonstrate the usage of InvariantCulture. If there are any other mistakes, we will not discuss them here)

 

 

Comparison between InvariantCulture and string

The following code compares four character strings: zh-cn, en-us, And InvariantCulture (case sensitive ).

Static void Main () </p> <p >{</p> <p> string [] strs = </p> <p> {"", "A", "B", "B", "abc", "AB", "AB", "AB", "AB", "aaa", "00 ", "0001", "002", "a4", "a9", "a33" };</p> <p> Console. writeLine ("en-US"); </p> <p> Array. sort <string> (strs, StringComparer. create (CultureInfo. getCultureInfo ("en-us"), false); </p> <p> Console. writeLine (String. join ("<", strs); </p> <p> Console. writeLine ("zh-CN"); </p> <p> Array. sort <string> (strs, StringComparer. create (CultureInfo. getCultureInfo ("zh-CN"), false); </p> <p> Console. writeLine (String. join ("<", strs); </p> <p> Console. writeLine ("Ordinal"); </p> <p> Array. sort <string> (strs, StringComparer. ordinal); </p> <p> Console. writeLine (String. join ("<", strs); </p> <p> Console. writeLine ("Invariant"); </p> <p> Array. sort <string> (strs, StringComparer. invariantCulture); </p> <p> Console. writeLine (String. join ("<", strs); </p> <p>}Result:En-US </p> <p> 00 <0001 <002 <a <a33 <a4 <a9 <aaa <AB <AB <AB <AB <abc <B <B </p> <p> zh-CN </p> <p> 00 <0001 <002 <a <a33 <a4 <a9 <aaa <AB <AB <AB <AB <abc <B </p> <p> Ordinal </p> <p> 00 <0001 <002 <A <AB <B <a <a33 <a4 <a9 <AB <aaa <AB <abc <B </p> <p> Invariant </p> <p> 00 <0001 <002 <a <A <a33 <a4 <a9 <aaa <AB <AB <AB <abc <B </p> <p>

(All the following are case sensitive)

Ordinal is a traditional comparison method, that is, compare the values of each character. If they are equal, continue to compare the next group. If there is none, the length is large.

Invariant and most CultureInfo use a more user-friendly comparison method. First, determine whether a group of characters is different (case-insensitive). If the returned results are different, B> AB, B> abc. If they are the same, compare the next group. If they are all the same, compare the length, so abc> AB> AB. If they are both the same, then compare the case. The other character is always greater than the lower case, so AB> AB> AB> AB

So what is the function of comparing strings like InvariantCulture? In my opinion, the output format is more readable. In fact, the InvariantCulture character string is a case-insensitive comparison of Ordinal (but here the upper case letters> lower case letters ), if the results are not the same, compare the case-sensitive Ordinal (also, it is an upper-case letter> lower-case letter ). In this way, you can filter the strings at a large time, and then compare the details. For the following example, the comparison between Ordinal and InvariantCulture is more readable!

String [] arr = {"AB", "AB", "AB", "AB", "Abccccccc", "aBccccc", "Abd "}; </p> <p> Array. sort <string> (arr, StringComparer. ordinal); </p> <p> Console. writeLine (String. join ("\ n", arr); </p> <p> Console. writeLine (); </p> <p> Array. sort <string> (arr, StringComparer. invariantCulture); </p> <p> Console. writeLine (String. join ("\ n", arr ));

Result:

The result is obvious. The Ordinal sorting result on the Ordinal Machine Type looks messy, while the InvariantCulture is more readable.

 

Summary

Multiple types of CultureInfo are supported. NET Framework is more user-friendly, because it can adapt the same data to different regions and cultures. This certainly satisfies users in different regions and cultures, but the premise is that the data is presented to "people, if the data is used for transmission between computers, that is, for "machines", such multi-cultural processing is not appropriate, resulting in different display forms of the same data, in particular, when the cultural areas of both parties are different, data may not be normally read or may generate potential bugs. Therefore, InvariantCulture is useful here.