高秀敏,大同网,淘宝聚划算
cultureinfo类位于system.globalization命名空间内，这个类和命名空间许多人都不是很熟悉，实际我们在写程序写都经常间接性的接触这个类，当进行数字，日期时间，字符串匹配时，都会进行cultureinfo的操作，也就是说，也就是不同的cultureinfo下，这些操作的结果可能会不一样，由于我们大部分开发部署都是在同一种语言环境中，平日里可能没有感觉到它的用处，如果你的开发的项目是给国外用户用的，有可能在你机器上运行输出是一种效果，在客户机器上是另一种输出效果，这句需要用到cultureinfo类了，对使用用户来说，这也是ms提供的人性化的一面(比方说，同样是日期，中文环境输出符合中国人的习惯，德语环境中的输出符合德国人的习惯，这是默认的输出方式)，但对开发人员和服务数据中心来说，就要选择是保证统一的输出，还是用ms的默认方式了。
code如下：
我要评论 1 static readonly string[] culturesources = { "en-us", "zh-cn", "ar-iq", "de-de" };
2 static readonly random ran = new random(environment.tickcount);
3
4
5 static void main()
6 {
7 for (int i = 0; i < culturesources.length; i++){
8 threadpool.queueuserworkitem(client, i);
9 }
10 console.readline();
11 }
12
13
14 static void client(object obj)
15 {
16 int id = (int)obj;
17 thread.sleep(ran.next(1000));
18 cultureinfo culture = cultureinfo.getcultureinfo(culturesources[id]);
19 thread.currentthread.currentculture = culture;
20 console.writeline("操作系统语言设置成{0}\n数据输出是：{1}\n", culture.displayname, datetime.now.toshortdatestring());
21 }
运行结果如下：
结果看到了吧，同样的datetime.now.toshortdatestring()，在英语-美国，中文-中国，阿拉伯语-伊拉克和德语-德国的不同环境下，日期输出格式竟然有如此不同的输出结果，这样对使用的用户来说是很友好的，单对编程人员来说，如果对这些数据要处理，就要考虑不同的语言环境中，该怎么处理了，同时，这些数据让数据中心服务器情何以堪啊……
原因分析：
.net会考虑当前线程的cultureinfo，即thread.currentthread.currentculture（或者cultureinfo.currentculture），并根据cultureinfo，进行相应地区文化的数据处理，要解决这个问题，这样设置
thread.currentthread.currentculture = cultureinfo.invariantculture;//和new cultureinfo("");一样，使用固定区域性，固定区域性不区分区域性；它与英语语言关联，但不与任何国家/地区关联
这样不管客户端运行在什么语言环境下，输出的时间格式都是统一的，方便数据中心服务器对数据做后续处理。
结果如下图：
支持多种cultureinfo是整个.net framework更加人性化，因为这可以使同一个数据适应不同地区和文化，这样当然满足处于不同地区和文化的用户，但前提是数据给“人”看，如果这些数据用于计算机之间的传输，即给“机器”看，这样的多文化处理反而不妥，造成同一个数据的不同展现形式，尤其是读写两方的文化地区不同时，数据可能根本无法被正常读取或者产生潜在bug，因此这里，正是invariantculture的用武之地。
转载自：
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Blazor server side 自家的一些开源的, 实用型项目的进度之 CEF客户端
.NET IoC模式依赖反转(DIP)、控制反转(Ioc)、依赖注入(DI)
vue+.netcore可支持业务代码扩展的开发框架 VOL.Vue 2.0版本发布
网友评论