.NETの「de-CH」カルチャ番号グループ区切り文字がローカルとAzureで異なるのはなぜですか？
ローカルデスクトップとAzureで実行しているときに、「de-CH」カルチャの番号グループ区切り文字として別のUnicode文字が表示されます。
次のコードを.NETCore3.1または.NETFramework 4.7.2のデスクトップで実行すると、2019アポストロフィのように見えますが、同じではない出力が表示されます。
Azureで実行する場合、たとえば https://try.dot.netまたは（わずかに変更された）.NET Core 3.1（WindowsベースのApp Service上）で実行されているAzure関数で0027は、標準のASCIIアポストロフィになります。
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では機能します。
なぜ違いがあるのですか？
回答
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およびRegionInfoデータは、文化的設定に対する文化的、地域的、管理者、またはユーザーの好みを表します。アプリケーションは、このデータが安定していることに依存する仮定を行うべきではありません。唯一の例外（これはルールであるため、もちろん例外があります）はCultureInfo.InvariantCultureです。CultureInfo.InvariantCultureは、バージョン間でも安定しているはずです。
文化的データが変化する理由はたくさんあります。WhidbeyとCustomCulturesを使用すると、リストが少し長くなります。
- 最も明白な理由は、データにバグがあり、変更を加える必要があったことです。（信じられないかもしれませんが、間違いを犯します;-)）この場合、ユーザー（およびあなたも）は文化的に正しいデータを望んでいるため、既存のアプリケーションが壊れたとしてもバグを修正する必要があります。
- もう1つの理由は、文化的な好みが変わる可能性があることです。これが発生する可能性のある方法はたくさんありますが、実際に発生します。
- グローバルな認識、異文化交流、コンピューターの役割の変化などはすべて、文化的な好みに影響を与える可能性があります。
- 国際条約、貿易などは価値を変える可能性があります。ユーロの採用により、多くの国の通貨記号がユーロに変更されました。
- 国または地域の規制もこれらの値に影響を与える可能性があります。
- 単語の優先スペルは時間の経過とともに変化する可能性があります。
- 希望する日付形式などは変更される可能性があります。
- 文化には複数の好みが存在する可能性があります。推奨される最良の選択は、時間の経過とともに変化する可能性があります。
- ユーザーは、日付や時刻の形式など、一部の値を上書きできた可能性があります。これらはユーザーオーバーライドなしでリクエストできますが、アプリケーションでユーザーオーバーライドの使用を検討することをお勧めします。
- ユーザーまたは管理者は、カルチャの一般的なデフォルト値を企業固有、地域固有、またはその他の標準データのバリエーションに置き換えて、代替カルチャを作成することができます。
- 一部の文化では、設定によって好みが異なる場合があります。ビジネスはインターネットカフェよりも正式な形をしているかもしれません。
- 企業は、組織全体に対して特定の日付形式または時間形式を必要とする場合があります。
- 同じカスタムカルチャの異なるバージョン、または1つのマシンでカスタムであり、別のマシンでWindowsのみのカルチャであるバージョン。
したがって、特定の日付/時刻形式で文字列をフォーマットし、後でそれを解析しようとすると、バージョンが変更された場合、マシンが変更された場合、フレームワークのバージョンが変更された場合（新しいデータ）、またはカスタムカルチャの場合に解析が失敗する可能性がありますかわった。信頼できる形式でデータを永続化する必要がある場合は、バイナリメソッドを選択するか、独自の形式を提供するか、InvariantCultureを使用してください。
データを変更しなくても、Invariantを使用することを忘れないでください。あなたが違う場合。、1,000.29のような構文の場合、クライアントが1.000,29を期待していると、解析が混乱する可能性があります。この問題は、ユーザーの文化が開発者の文化とは異なることに気付いていないアプリケーションで見られました。Invariantまたは別の手法を使用すると、この種の問題が解決されます。
もちろん、現在のユーザーの「正しい」表示と、カルチャデータが変更された場合の完全なラウンドトリップの両方を行うことはできません。したがって、一般的には、InvariantCultureまたは別の不変の形式を使用してデータを永続化し、常に適切な形式のAPIを使用して表示することをお勧めします。アプリケーションには独自の要件があるため、慎重に検討してください。
照合（ソート順/比較）の場合、不変の動作でさえ変更される可能性があることに注意してください。一貫して安定したソート順が必要な場合は、ソートバージョン管理を使用してこれを回避する必要があります。
ユーザーフレンドリーにフォーマットされたデータを自動的に解析する必要がある場合は、2つのアプローチがあります。
- ユーザーが使用する形式を明示的に指定できるようにします。
- これを解析する前に、まず文字列から数字、マイナス記号、小数点記号を除くすべての文字を削除します。最初に正しい小数点を知る必要があることに注意してください。これを正しく推測する方法はなく、間違って推測すると大きな問題が発生する可能性があります。
可能な限り、ユーザーフレンドリーになるようにフォーマットされた数値の解析は避けてください。代わりに、可能な限り、厳密に定義された（不変の）形式で番号を要求するようにしてください。