ᏌᏊᏍᎦᏚᎩ为什么是美国的本地名称? [英] Why is ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ the native name of the U.S.?

问题描述

当我使用此代码时:

var ri = new RegionInfo("us");
var nativeName = ri.NativeName;   // ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ

为什么nativeName则是字符串"ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ"(在切罗基中)?

如果我更改为new RegionInfo("US")(仅区别为大写字母US)，则会得到"United States".

我要做，知道RegionInfo的首选用法是提供特定的区域性信息字符串，例如:

new RegionInfo("en-US")
new RegionInfo("chr-Cher-US")

，依此类推.但是，如果我使用小写的us，为什么切诺基优于英语的 ?

---

(在Windows 10(版本1803"2018年4月更新"，.NET Framework 4.7.2上看到).

---

更新:即使在同一台计算机上，这也不一致.例如，我尝试打开PowerShell多次，每次都将[System.Globalization.RegionInfo]'US'粘贴到其中.似乎很长一段时间以来，PowerShell的所有实例始终提供相同的结果.但是过了一会儿，PowerShell的实例就会得出相反的结果.这是其中两个窗口的屏幕截图，一个窗口始终具有一个NativeName，另一个窗口始终具有相反的一个.因此必须进行一些不确定的确定(大小写无差异):

解决方案

要注意的第一件事是然后它将尝试查找静态区域列表.但由于它使用的是 Dictionary.ContainsKey ，这是区分大小写的搜索.因此，如果您指定"US"，它将找到它，但不会找到"us".

稍后，它会搜索所有区域性 (来自CultureInfo.GetCultures(CultureTypes.SpecificCultures))针对您指定的区域，但这是不区分大小写的方式.

我无法确认，因为我无法单步执行该代码，但我的猜测是，因为它按顺序进行了遍历，因此在到达en-US之前它将到达chr-Cher-US.

为什么不一致?

其中一条评论说，即使使用大写字母，LinqPad也会找到切诺基.我不知道为什么会这样.我能够复制它，但是我也发现在Visual Studio中，使用"US"时是英语，而使用"us"时是切诺基，就像您描述的那样.但是我确实发现，如果我在LinqPad中打开使用实验性Roslyn程序集"，那么它会同时返回"US"和"us"的英语.因此，也许与确定的确切运行时版本有关，我不能肯定地说.

影响一致性的一件事是缓存:在按文化和地区与"us"会产生不同的结果，但是请在同一程序中尝试以下操作:

var nativeNameus = new RegionInfo("us").NativeName;
var nativeNameUS = new RegionInfo("US").NativeName;

然后交换它们并再次运行:

var nativeNameUS = new RegionInfo("US").NativeName;
var nativeNameus = new RegionInfo("us").NativeName;

两个结果将始终相等，因为第一个区域性被缓存并用于下一个区域.

代码外部可能有代码调用相同的方法并最终缓存了区域性值，从而改变了您执行相同操作时所获得的结果.

结论

所有说明，这些文档实际上说:

我们建议您使用区域性名称(例如，英语(美国)为"en-US")来访问NativeName属性.

所以这是一个有争议的问题:您要求的是地区，而不是语言.如果您需要特定的语言，则要求使用该语言，而不仅仅是区域.

如果您想保证英语，则可以:

1. 按照Microsoft的建议进行操作，并在以下地区指定语言:"en-US"，或
2. 使用 EnglishName 或 DisplayName 属性(即使NativeName是切诺基(Cherokee)，也可以使用英语.

When I use this code:

var ri = new RegionInfo("us");
var nativeName = ri.NativeName;   // ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ

why is nativeName then the string "ᏌᏊ ᎢᏳᎾᎵᏍᏔᏅ ᏍᎦᏚᎩ" (in Cherokee)?

If I change to new RegionInfo("US") (only difference, capital US), I get instead "United States".

I do know the preferred usage of RegionInfo is to give a specific culture info string such as:

new RegionInfo("en-US")
new RegionInfo("chr-Cher-US")

and so on, and that works. But why is Cherokee preferred over English only if I use lower-case us?

---

(Seen on Windows 10 (version 1803 "April 2018 Update"), .NET Framework 4.7.2.)

---

Update: This is not consistent, even on the same machine. For example I tried opening PowerShell very many times, each time pasting [System.Globalization.RegionInfo]'US' into it. It seems like for a long period, all instances of PowerShell are consistently giving the same result. But then after a while, the instances of PowerShell then give the opposite result. Here is a screenshot of two of the windows, one consistently having one NativeName, and the other one consistently having the opposite one. So there must be some non-deterministic determination going on (no difference in casing):

解决方案

The first thing to note is that the constructor for RegionInfo finds the region by finding a culture used in that region. So it's looking for a language in that country, not just the country.

Reading through that source code, it seems like the difference in upper/lower case is because of how the lookups are done if no culture is specified with the region.

For example, it tries a couple things first, but then it will try to look in a static list of regions. But because it's using Dictionary.ContainsKey, it's a case-sensitive search. So if you specify "US", it will find it, but not "us".

Later, it searches through all the cultures (from CultureInfo.GetCultures(CultureTypes.SpecificCultures)) for the region you gave, but it does so in a case-insensitive way.

I can't confirm since I can't step through that code, but my guess is that, because it's going through the list in order, it will get to chr-Cher-US before it gets to en-US.

Why is it not consistent?

One of the comments said that LinqPad finds Cherokee even when using upper case. I don't know why this is. I was able to replicate that, but I also found that in Visual Studio, it's English when using "US" and Cherokee when using "us", like you describe. But I did find that if I turn on "Use experimental Roslyn assemblies" in LinqPad, then it returns English for both "US" and "us". So maybe it has something to do with the exact runtime version targetted, I can't say for sure.

One thing that affects consistency is caching: the first thing that it will do when it does not get a complete match by culture + region is check a cache of already-found cultures. It lower-cases all the keys in that cache, so this cache is case-insensitive.

You can test this. We know that using "US" vs. "us" will yield different results, but try this in the same program:

var nativeNameus = new RegionInfo("us").NativeName;
var nativeNameUS = new RegionInfo("US").NativeName;

Then swap them and run it again:

var nativeNameUS = new RegionInfo("US").NativeName;
var nativeNameus = new RegionInfo("us").NativeName;

Both results will always be equal because the first culture is cached and used for the next.

It's possible that there is code outside of your code that calls the same methods and ends up caching a culture value, thereby changing the result you get when you do the same.

Conclusion

All that said, the docs actually say:

We recommend that you use the culture name—for example, "en-US" for English (United States)—to access the NativeName property.

So it is a bit of a moot point: you asked for a region, not a language. If you need a specific language, ask for that language, not just a region.

If you want to guarantee English, then either:

1. Do as Microsoft recommends and specify the language with the region: "en-US", or
2. Use the EnglishName or DisplayName properties (which are English even when the NativeName is Cherokee).

这篇关于ᏌᏊᏍᎦᏚᎩ为什么是美国的本地名称?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！