為什么 .NET“de-CH”文化數字組分隔符在本地和 Azure 上不同？

Question

當在本地桌面和 Azure 中運行時，我看到不同的 Unicode 字符作為“de-CH”區域性的數字組分隔符。

當以下代碼在 .NET Core 3.1 或 .NET Framework 4.7.2 中在我的桌面上運行時，它輸出2019 ，它看起來像一個撇號，但並不相同。

當在 Azure 中運行時，例如在https://try.dot.net或（稍作修改）在 Azure function 中運行時，在 .NET Core 3.1 中運行（在基於標准應用程序服務的 Windows 上運行，apose0SCII 結果為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-不變的/

CultureInfo 和 RegionInfo 數據表示文化設置的文化、區域、管理員或用戶偏好。 應用程序不應做出任何依賴此數據穩定的假設。 唯一的例外（這是一個規則，所以當然有例外）是 CultureInfo.InvariantCulture。 CultureInfo.InvariantCulture 應該保持穩定，即使在不同版本之間也是如此。

文化數據發生變化的原因有很多。 使用 Whidbey 和 Custom Cultures，列表會變得更長一些。

• 最明顯的原因是數據中存在錯誤，我們不得不進行更改。 （信不信由你，我們會犯錯誤；-)）在這種情況下，我們的用戶（以及您的用戶）需要文化上正確的數據，因此即使它破壞了現有的應用程序，我們也必須修復錯誤。
• 另一個原因是文化偏好可以改變。 發生這種情況的方式有很多種，但它確實發生了：
  • 全球意識、跨文化交流、計算機角色的變化等等都會影響文化偏好。
  • 國際條約、貿易等可以改變價值。 歐元的采用將許多國家的貨幣符號更改為€。
  • 國家或地區法規也會影響這些值。
  • 單詞的首選拼寫會隨着時間而改變。
  • 首選日期格式等可以更改。
• 一種文化可能存在多種偏好。 然后，首選的最佳選擇可以隨時間改變。
• 用戶可能已經覆蓋了一些值，例如日期或時間格式。 這些可以在沒有用戶覆蓋的情況下請求，但是我們建議應用程序考慮使用用戶覆蓋。
• 用戶或管理員可以創建替換文化，用公司特定、區域特定或標准數據的其他變體替換文化的通用默認值。
  • 某些文化的偏好可能因環境而異。 企業的形式可能比 Inte.net Café 更正式。
  • 企業可能需要整個組織的特定日期格式或時間格式。
• 相同自定義區域性的不同版本，或者在一台機器上自定義的版本和另一台機器上的 windows 唯一區域性。

因此，如果您使用特定日期/時間格式格式化字符串，然后稍后嘗試解析它，則如果版本更改、機器更改、框架版本更改（更新數據）或自定義文化，解析可能會失敗被改變了。 如果您需要以可靠的格式保存數據，請選擇二進制方法，提供您自己的格式或使用 InvariantCulture。

即使不更改數據，記住使用 Invariant 仍然是一個好主意。 如果你有不同。 和 1,000.29 之類的語法，如果客戶期望 1.000,29，那么解析可能會混淆。 我在沒有意識到用戶文化與開發人員文化不同的應用程序中看到過這個問題。 使用不變量或其他技術可以解決此類問題。

當然，如果文化數據發生變化，您不能同時為當前用戶提供“正確”的顯示和完美的往返。 因此，通常我建議使用 InvariantCulture 或其他不可變格式來持久化數據，並始終使用適當的格式化 API 進行顯示。 您的應用程序將有自己的要求，因此請仔細考慮。

請注意，對於排序規則（排序順序/比較），即使是不變的行為也會發生變化。 如果您需要始終穩定的排序順序，則需要使用排序版本控制來解決這個問題。

如果您需要自動解析格式化為用戶友好的數據，有兩種方法：

• 允許用戶明確指定使用的格式。
• 在嘗試解析之前，首先從字符串中刪除除數字、減號和小數分隔符之外的所有字符。 請注意，您首先需要知道正確的小數點分隔符。 沒有辦法正確猜測這個，猜錯可能會導致重大問題。

盡可能避免解析格式化為用戶友好的數字。 相反，盡可能嘗試以嚴格定義（不變）的格式請求數字。

Answer 2

在本地桌面和 Azure 上運行時，我看到一個不同的 Unicode 字符作為“de-CH”文化的數字組分隔符。

當以下代碼在 .NET Core 3.1 或 .NET Framework 4.7.2 的桌面上運行時，它會輸出2019 ，它看起來像撇號，但並不相同。

When run in Azure, for instance in https://try.dot.net or (slightly modified) in an Azure function running on .NET Core 3.1 (on a Windows based App Service) it results in 0027 , a standard ASCII apostrophe.

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。

為什么有區別？