これらの面白い地域設定

今日は、地域の設定についてお話します。 しかし、最初に、小さなタスク：以下のコードは何を出力しますか？ （コードはC＃ですが、かなり一般的な問題が考慮されているため、代わりに他の言語を想像できます。）

Console.WriteLine((-42).ToString() == "-42"); Console.WriteLine(double.NaN.ToString() == "NaN"); Console.WriteLine(int.Parse("-42") == -42); Console.WriteLine(1.1.ToString().Contains("?") == false); Console.WriteLine(new DateTime(2014, 1, 1).ToString().Contains("2014")); Console.WriteLine("i".ToUpper() == "I" || "I".ToLower() == "i");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

真の値をいくつ取得しましたか？ 0より大きい場合、正解は「依存」であるため、地域の設定について詳しく知る必要はありません。 残念ながら、多くのプログラマーは、異なる環境でのこれらの設定が異なる可能性があるとはまったく考えていません。 また、このプログラマーがすべてのコードにInvariantCultureを設定するのは面倒で、その結果、美しいアプリケーションは非常に奇妙に動作し、他の国のユーザーに届きます。 。 この記事では、地域の設定によって影響を受けるいくつかの重要なポイントの簡単な選択を提供します。







ちょっとした理論：.NETでは、特定の言語と地域の設定に関するすべての情報はCultureInfoクラスを使用して見つけることができます。 以前にカルチャに遭遇したことがない場合、 この投稿は最初の慣れに適しています。 既存のさまざまな地域設定の調査に熱心な経験豊富なプログラマーは、すべてのCultureInfoを手動で表示するのにうんざりするかもしれません。 個人的には、ある時点で疲れました。 したがって、CultureInfoExplorerと呼ばれる小さなWPFアプリケーション（ GitHub 、 バイナリ へのリンク ）が表示され、上のスクリーンショットに示されています。 次のことができます。

• このCultureInfoによると、その主要なプロパティの意味と、事前に準備された文字列パターンがどのように見えるかを見てください。
• このプロパティについては、可能な値と、各値に対応するすべてのCultureInfoのリストを参照してください。
• このパターンについては、変換可能なオプションの可能なオプションを参照してください。各オプションについては、関連するCultureInfoのリストも参照してください。

このプログラムが役立つ読者がいることを願っています。 さまざまな地域の設定について多くを学ぶことができます。 さて、例のために。

数字

数値の表現については、 NumberFormatInfo （ CultureInfo.NumberFormatからアクセス可能）を担当します 。 そして、これは通常の数字だけでなく、パーセンテージと金銭的価値にも言及しています。 正と負の値があることに注意してください。ローカリゼーション/グローバリゼーションを扱う場合、これに注意を払うことが重要です。 少なくともドキュメントに目を通し、利用可能なプロパティを確認することを強くお勧めします。



人に問題を引き起こす最も一般的なプロパティの1つは、 NumberDecimalSeparatorと呼ばれます 。 これは、数値をデコードするときに整数部が何から分離されるかを担当します。 エラーの典型的な例：プログラマは小数の配列を文字列にマージし、それらをコンマで区切ります。 その後、彼は文字列を解析して配列に戻します。 NumberDecimalSeparatorがポイントに等しい場合、すべてが正常です。 たとえば、en-USカルチャーが公開されたため、すべてがプログラマーのために機能し、彼は製品をリリースしました。 この製品はru-RUカルチャーを持つユーザーによってダウンロードされ、悲しみ始めます：結局、彼のNumberDecimalSeparatorはコンマに等しい：要素1.2および3.4​​の配列は、そのようなマージでストリング「1,2,3,4」にマージされ、解析するのに問題があります。 個人的には、同様の問題に遭遇したプログラマーが、フォーマット時に正しいNumberFormatInfoを示すことで通常は解決しようとせず、ドットをコンマに、またはコンマをドットに置き換えることを思いつき始めると、さらに悲しくなります。 原則として、 NumberDecimalSeparatorが任意であることを理解する必要があります。 たとえば、fa-IR（ペルシャ）文化では、スラッシュ（ '/'）と同じです。



利息と通貨についても同様のプロパティがあります： PercentDecimalSeparatorとCurrencyDecimalSeparator 。 これらの3つの値すべてが一致する必要はありません。 たとえば、カザフスタン（kk-KZ）の場合、 NumberDecimalSeparatorとPercentDecimalSeparatorはカンマに等しく、CurrencyDecimalSeparatorはマイナス記号に等しくなります（負の数値が示されるものとまったく同じです）。



整数が文字列に変換されると、数字のみで構成される値が得られると考える人もいます。 ただし、これらの数値はグループに分けることができます。 NumberGroupSizesプロパティはグループのサイズを担当し、 NumberGroupSeparatorはセパレータを担当します（パーセントと通貨は同様のプロパティを持っていますが、再び一致する必要はありません）。 グループのサイズはさまざまです。たとえば、多くのカルチャ （as-IN、bn-BD、gu-IN、hi-INなど） では 、 NumberGroupSizesは{ 3、2 }です。 as-INカルチャの番号1234567は、 「12.34.567」のようになります。 \ u0020スペースはセパレータとして使用できます（たとえば、af-ZAおよびlt-LTで）が、それを見るときは、文字列の解析とフォーマットに別の松葉杖を駆り立てないでください。 ほとんどの場合、通常のスペースの代わりに、不可解なスペースが使用されます\ u00A0（ネイティブru-RU）。



負の数と正の数を示す記号もカルチャに含まれます： NegativeSign 、 PositiveSign 。 ありがたいことに、利用可能なすべての文化において、マイナスとプラスに等しいのですが、これに依存するべきではありません。環境を再定義し、プロパティをプロパティに設定できます。 そして、最も興味深いのは、記号ではなく、正と負の値のフォーマットパターンです。 たとえば、負の数値の書式設定は、次の5つの値を持つNumberNegativePatternを使用して決定されます。

 0 (n) 1 -n 2 - n 3 n- 4 n -
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、ti-ET文化（Tigrinya（エチオピア））では、-5の値がフォーム（5）に表示されます。 パーセンテージと通貨（ PercentNegativePattern 、 PercentPositivePattern 、 CurrencyNegativePattern 、 CurrencyPositivePattern ）を使用すると、状況はさらに楽しくなります。 たとえば、 CurrencyNegativePatternには、最大16個の値があります。

 0 ($n) 1 -$n 2 $-n 3 $n- 4 (n$) 5 -n$ 6 n-$ 7 n$- 8 -n $ 9 -$ n 10 n $- 11 $ n- 12 $ -n 13 n- $ 14 ($ n) 15 (n $)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特殊文字と特別な数値の特別なプロパティもあります： PercentSymbol 、 PerMilleSymbol 、 NaNSymbol 、 NegativeInfinitySymbol 、 PositiveInfinitySymbol 。 doubleが取得され、文字列にフォーマットされた（もちろん、現在のユーザーカルチャーでは）実際のプロジェクトを見て、文字列形式で"-Infinity"と比較しました。 この現在の文化に応じて、 NegativeInfinitySymbolはさまざまな意味を持ちます。

 '- ', '-- អនន្ត', '(-) முடிவிலி', '-∞', '-Anfeidredd', '-Anfin', '-begalybė', '-beskonačnost', 'Éigríoch dhiúltach', '-ifedh', '-INF', '-Infini', '-infinit', '-Infinit', '-Infinito', '-Infinitu', '-infinity', 'Infinity-', '-Infinity', 'miinuslõpmatus', 'mínusz végtelen', '-nekonečno', '-neskončnost', '-nieskończoność', '-njekónčne', '-njeskóńcnje', '-onendlech', '-Sonsuz', '-tükeniksizlik', '-unendlich', '-Unendlich', '-Άπειρο', '-', ' ', '-უსასრულობა', 'אינסוף שלילי', '-لا نهاية', 'منهای بی نهایت', 'مەنپىي چەكسىزلىك', '-අනන්තය', 'ᠰᠦᠬᠡᠷᠬᠦ ᠬᠢᠵᠠᠭᠠᠷᠭᠦᠢ ᠶᠡᠬᠡ', 'མོ་གྲངས་ཚད་མེད་ཆུང་བ།', 'ߘߊ߲߬ߒߕߊ߲߫-', 'ꀄꊭꌐꀋꉆ', '負無窮大', '负无穷大'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

分析したさまざまな有用な特性の例。 そして、ちょっとしたトリックをやってみましょう。ロシアの文化を少し変えて、新しい意味が私たちの人生を台無しにするように、投稿の最初から例を示します。

 var myCulture = (CultureInfo)new CultureInfo("ru-RU").Clone(); myCulture.NumberFormat.NegativeSign = "!"; myCulture.NumberFormat.PositiveSign = "-"; myCulture.NumberFormat.PositiveInfinitySymbol = "+Inf"; myCulture.NumberFormat.NaNSymbol = "Not a number"; myCulture.NumberFormat.NumberDecimalSeparator = "?"; Thread.CurrentThread.CurrentCulture = myCulture; Console.WriteLine(-42); // !42 Console.WriteLine(double.NaN); // Not a number Console.WriteLine(int.Parse("-42")); // 42 Console.WriteLine(1.1); // 1?1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おそらくここの誰かが私に言う：「なぜそのような例が考慮されるべきなのか？」 プログラマーがそのようなことを書くことはありません！」 そして、私は答えます：「まあ、まあ、誰もいないでしょう、どうして？」 あるライブラリを配布すると状況は悲しくなり、そのユーザーの1人が文化を楽しむことにしました。 たぶん、彼はただ楽しんでいるのが好きなだけかもしれません。あるいは、ある種の風変わりな文化（死んだ、または架空の言語）のアプリケーションを書いているかもしれません。 しかし、それは問題ではありません。 そして、重要なことは、あなたのライブラリがそれに対する珍しい環境で奇妙に振る舞い始めるということです。 したがって、 NegativeSignとPositiveSignが決して変わらないという事実に依存しないでください。 必要な文化を明示し、幸せに暮らすことをお勧めします。



また、John Skeetによる最近の投稿The BobbyTables cultureを読むことをみんなに勧めます。 簡単な要約：John Skeetは、SQLクエリのパラメーターが数字や日付であっても、それらをエスケープしない人を誓います。 そして、ジョンはいくつかのリクエストを受け取ります

 "SELECT * FROM Foo WHERE BarDate > '" + DateTime.Today + "'" "SELECT * FROM Foo WHERE BarValue = " + (-10)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして奇跡の文化を定義します：

 CultureInfo bobby = (CultureInfo) CultureInfo.InvariantCulture.Clone(); bobby.DateTimeFormat.ShortDatePattern = @"yyyy-MM-dd'' OR ' '=''"; bobby.DateTimeFormat.LongTimePattern = ""; bobby.NumberFormat.NegativeSign = "1 OR 1=1 OR 1=";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

手を振ると、クエリは次のようになります。

 SELECT * FROM Foo WHERE BarDate > '2014-08-08' OR ' '=' ' SELECT * FROM Foo WHERE BarValue = 1 OR 1=1 OR 1=10
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、これ以上の説明は必要ないと思います。

日時

日付と時刻では、すべてが特に困難です。 日付には、 DateTimeFormatInfoクラス（ CultureInfo.DateTimeFormatプロパティ）があり、 Calendarがあります 。 さらに、メインカルチャーカレンダー（ CultureInfo ）があり、使用可能なカレンダーのリスト（ CultureInfo.OptionalCalendar ）があります。 標準カレンダーの大きなバンドルがあります： ChineseLunisolarCalendar 、 EastAsianLunisolarCalendar 、 GregorianCalendar 、 HebrewCalendar 、 HijriCalendar 、 JapaneseCalendar 、 JapaneseLunisolarCalendar 、 JulianCalendar 、 KoreanCalendar 、 KoreanLunisolarCalendar 、 PersianCalendar 、 TaiwanCalendar、。 彼らの論理は非常に異なっています。 このトピックについてはインターネット上の詳細情報で十分であり、一連の独立した投稿に十分な資料があるため、ここでは詳しく説明しません。 日付と時刻のフォーマットルールは、数字よりもさらに楽しいものです。さまざまな日付フォーマットオプションのパターンの束、月と曜日のネイティブ名、AM / PMの表記、セパレータなど。 2014年12月31日は、次の形式で送信できます（ dateTime.ToString（ "d"） ）。

 09/03/36 10/3/1436 12/31/2014 1436/3/10 2014.12.21. 2014/12/21 2014-12-21 31. 12. 2014 31.12.14 31.12.14 ý. 31.12.2014 31.12.2014 . 31.12.2014. 31/12/14 31/12/2014 31/12/2557 31-12-14 31-12-2014 31- 14 31--14
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これらはデフォルト値にすぎません（オプションのカレンダーを接続することはありません）。 しかし、ここでもさまざまな時間スケールを見ることができます。誰かが庭に1436人、2557人がいます（これは記事の冒頭からの例の最後から2番目の行への参照です）。 日付を使用して操作している場合は、常に同じ形式で表示するか、ユーザーに合わせて日付をより見慣れた形式で表示するかを検討する必要があります。 さて、日付の解析については黙っています。

七面鳥試験

あなたのコードはトルコのテストに合格しますか？ 。 詳細については語りませんが、オリジナルを自分で読む方が良いでしょう。 トルコテストの要点は次のとおりです。現在の文化をtr-TR（トルコ語（トルコ））に変更し、アプリケーションを実行します。 すべて正常に動作しますか？ この文化では、日付、数字、文字列で十分な楽しみがあります。 最初の例に戻ると、検討中のカルチャでは、 「i」.ToUpper（）は 「I」と等しくなく、 「I」.ToLower（）は 「i」と等しくありません（大文字と小文字について詳しく知りたい場合は、私はこの投稿とこのUTF-8に関するSO-answerを強くお勧めします 、これは問題ありません）。 投稿の最後に、アラビア数字「٤٦٠٣٨」で構成される文字列が正規表現\ d {5}と 一致する素晴らしい例を示します。

結論の代わりに

地域設定の科学は複雑です。 この投稿では、私は彼らが何に影響を与えることができるかについての完全な情報を提供するふりを決してしません。 内在化に関連する興味深いことがたくさんあります（右から左へ行くテキストについてのみ考えます。1つではなく、別の投稿を書くことができます）。 CultureInfo.CurrentCultureがアプリケーションにどのように影響するかについて、いくつかの興味深い例を示したかっただけです。 一般的な博学の拡大という観点から、この資料が誰かに役立つことを願っています。 一般的な教訓は次のとおりです。世界にさまざまな文化があると考えたくない場合は、 CultureInfo.InvariantCulture （または自分に適した別の文化）をどこでも使用します。ほとんどの場合、平和に眠ることができます。 そして、あなたがそれについて考えるならば、それからこの領域をより徹底的に研究することは素晴らしいでしょう。 この優れた本はこれに役立ちます： ネット国際化：グローバルWindowsおよびWebアプリケーション構築のための開発者ガイド 。



CultureInfoがさまざまな機能の動作にどのように影響するかについての追加の事実は歓迎します。 多くの人が自分の魅力的な物語を見つけると思います。