C#中的CultureInfo类
CultureInfo类位于System.Globalization命名空间内，这个类和命名空间许多人都不是很熟悉，实际我们在写程序写都经常间接性的接触这个类，当进行数字，日期时间，字符串匹配时，都会进行CultureInfo的操作，也就是说，也就是不同的CultureInfo下，这些操作的结果可能会不一样，由于我们大部分开发部署都是在同一种语言环境中，平日里可能没有感觉到它的用处，如果你的开发的项目是给国外用户用的，有可能在你机器上运行输出是一种效果，在客户机器上是另一种输出效果，这句需要用到CultureInfo类了，对使用用户来说，这也是ms提供的人性化的一面(比方说，同样是日期，中文环境输出符合中国人的习惯，德语环境中的输出符合德国人的习惯，这是默认的输出方式)，但对开发人员和服务数据中心来说，就要选择是保证统一的输出，还是用ms的默认方式了。
code如下：
static readonly string[] CultureSources = { "en-us", "zh-cn", "ar-iq", "de-de" };
static readonly Random Ran = new Random(Environment.TickCount);
static void Main()
{
for (int i = 0; i < CultureSources.Length; i++){
ThreadPool.QueueUserWorkItem(Client, i);
}
Console.ReadLine();
}
static void Client(object obj)
{
int id = (int)obj;
Thread.Sleep(Ran.Next(1000));
CultureInfo culture = CultureInfo.GetCultureInfo(CultureSources[id]);
Thread.CurrentThread.CurrentCulture = culture;
Console.WriteLine("操作系统语言设置成{0}\n数据输出是：{1}\n", culture.DisplayName, DateTime.Now.ToShortDateString());
}
运行结果如下：
操作系统语言设置成阿拉伯语(伊拉克)
数据输出是：7/01/2020
操作系统语言设置成中文(简体，中国)
数据输出是：2020/1/7
操作系统语言设置成德语(德国)
数据输出是：7.01.2020
操作系统语言设置成英语(美国)
数据输出是：1/7/2020
结果看到了吧，同样的DateTime.Now.ToShortDateString()，在英语-美国，中文-中国，阿拉伯语-伊拉克和德语-德国的不同环境下，日期输出格式竟然有如此不同的输出结果，这样对使用的用户来说是很友好的，单对编程人员来说，如果对这些数据要处理，就要考虑不同的语言环境中，该怎么处理了，同时，这些数据让数据中心服务器情何以堪啊……
原因分析：
.NET会考虑当前线程的CultureInfo，即Thread.CurrentThread.CurrentCulture(或者CultureInfo.CurrentCulture)，并根据CultureInfo，进行相应地区文化的数据处理，要解决这个问题，这样设置
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;//和new CultureInfo("");一样，使用固定区域性，固定区域性不区分区域性;它与英语语言关联，但不与任何国家/地区关联
这样不管客户端运行在什么语言环境下，输出的时间格式都是统一的，方便数据中心服务器对数据做后续处理。
结果如下：
操作系统语言设置成英语(美国)
数据输出是：1/7/2020
操作系统语言设置成德语(德国)
数据输出是：7.01.2020
操作系统语言设置成中文(简体，中国)
数据输出是：2020/1/7
操作系统语言设置成阿拉伯语(伊拉克)
数据输出是：7/01/2020
支持多种CultureInfo是整个.NET Framework更加人性化，因为这可以使同一个数据适应不同地区和文化，这样当然满足处于不同地区和文化的用户，但前提是数据给“人”看，如果这些数据用于计算机之间的传输，即给“机器”看，这样的多文化处理反而不妥，造成同一个数据的不同展现形式，尤其是读写两方的文化地区不同时，数据可能根本无法被正常读取或者产生潜在bug，因此这里，正是InvariantCulture的用武之地。