c# - 为什么 .NET "de-CH"区域性数字组分隔符在本地和 Azure 上不同？

Question

在本地桌面和 Azure 中运行时，我看到不同的 Unicode 字符作为“de-CH”区域性的数字组分隔符。

当以下代码在我的桌面上的 .NET Core 3.1 或 .NET Framework 4.7.2 中运行时，它会输出 2019，它看起来像撇号，但并不相同。

在 Azure 中运行时，例如在 https://try.dot.net 中运行时或者(稍加修改)在 .NET Core 3.1(基于 Windows 的应用服务)上运行的 Azure 函数中，它会生成标准 ASCII 撇号 0027。

using System;
using System.Linq;
using System.Globalization;

Console.WriteLine(((int)(CultureInfo
    .GetCultureInfo("de-CH")
    .NumberFormat
    .NumberGroupSeparator
    .Single())) // Just getting the single character as an int
    .ToString("X4") // unicode value of that character
    );

这样做的结果是尝试使用“de-CH”文化在本地桌面上解析字符串 4'200.000(其中撇号是 Unicode 0027)失败，但它可以在 Azure 中运行。

为什么会有差异？

Answer 1

Shawn Steele 的这篇 Microsoft 博客解释了为什么不应依赖稳定的特定文化设置(完整引用，因为它不再在 MSDN 上在线):

https://web.archive.org/web/20190110065542/https://blogs.msdn.microsoft.com/shawnste/2005/04/05/culture-data-shouldnt-be-considered-stable-except-for-invariant/

CultureInfo and RegionInfo data represents a cultural, regional, adminor user preference for cultural settings. Applications should NOTmake any assumptions that rely on this data being stable. The onlyexception (this is a rule, so of course there's an exception) is forCultureInfo.InvariantCulture. CultureInfo.InvariantCulture issupposed to remain stable, even between versions.

There are many reasons that cultural data can change. With Whidbeyand Custom Cultures the list gets a little longer.

• The most obvious reason is that there is a bug in the data and we had to make a change. (Believe it or not we make mistakes ;-)) In this case our users (and yours too) want culturally correct data, so we have to fix the bug even if it breaks existing applications.
• Another reason is that cultural preferences can change. There're lots of ways this can happen, but it does happen:
  • Global awareness, cross cultural exchange, the changing role of computers and so forth can all effect a cultural preference.
  • International treaties, trade, etc. can change values. The adoption of the Euro changed many countries currency symbol to €.
  • National or regional regulations can impact these values too.
  • Preferred spelling of words can change over time.
  • Preferred date formats, etc can change.
• Multiple preferences could exist for a culture. The preferred best choice can then change over time.
• Users could have overridden some values, like date or time formats. These can be requested without user override, however we recommend that applications consider using user overrides.
• Users or administrators could have created a replacement culture, replacing common default values for a culture with company specific, regional specific, or other variations of the standard data.
  • Some cultures may have preferences that vary depending on the setting. A business might have a more formal form than an Internet Café.
  • An enterprise may require a specific date format or time format for the entire organization.
• Differing versions of the same custom culture, or one that's custom on one machine and a windows only culture on another machine.

So if you format a string with a particular date/time format, and thentry to Parse it later, parse might fail if the version changed, if themachine changed, if the framework version changed (newer data), or ifa custom culture was changed. If you need to persist data in areliable format, choose a binary method, provide your own format oruse the InvariantCulture.

Even without changing data, remembering to use Invariant is still agood idea. If you have different . and , syntax for something like1,000.29, then Parsing can get confused if a client was expecting1.000,29. I've seen this problem with applications that didn't realize that a user's culture would be different than the developer'sculture. Using Invariant or another technique solves this kind ofproblem.

Of course you can't have both "correct" display for the current userand perfect round tripping if the culture data changes. So generallyI'd recommend persisting data using InvariantCulture or anotherimmutable format, and always using the appropriate formatting APIs fordisplay. Your application will have its own requirements, so considerthem carefully.

Note that for collation (sort order/comparisons), even Invariantbehavior can change. You'll need to use the Sort Versioning to getaround that if you require consistently stable sort orders.

如果您需要自动解析格式为用户友好的数据，有两种方法:

• 允许用户明确指定使用的格式。
• 首先从字符串中删除除数字、减号和小数点分隔符之外的所有字符，然后再尝试解析该字符串。请注意，您需要首先知道正确的小数分隔符。无法正确猜测这一点，猜测错误可能会导致重大问题。

尽可能避免解析用户友好格式的数字。相反，只要有可能，请尝试以严格定义的(不变)格式请求数字。