このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
リソースの機能は、実装とデータの分離だけではない。
一昨日、言語依存の文字列という言い方をしたが、
リソースはプログラムの国際化にも効果を発揮する。
国際化と言うと大層な話にも感じられる。
まあ、日本語さえ使えれば、別に不要といえばそうなのだが、
プログラムに英語と日本語を入れておけば、
日本語 OS では日本語、それ以外の OS では英語と、
簡単に日本語以外の OS でも利用できるようになる。
また、Windows 2000 以降には多言語版というのがあり、
UI の言語を切り替える事ができる。
この環境では言語によって表示を変えることもできる。
.NET には国際化に対応した仕組みがある。
System.Globalization 名前空間にある、
CultureInfo クラスがその核を成している。
CultureInfo クラスは、「カルチャ」を表し、
「カルチャ」は、「言語」と「国名」の組み合わせだ。
それぞれに特定の文字列が定義されている。
例えば、日本語は「ja」、日本は、「JP」だ。
日本における日本語のカルチャは、「ja-JP」となる。
英語は「en」、アメリカは「US」、イギリスは「GB」だ。
アメリカ英語は「en-US」、イギリス英語は「en-GB」となる。
.NET では、実行中のスレッドに個別の
CultureInfo のインスタンスが割り当てられている。
これは、CultureInfo.CurrentCulture で取得できる。
（カルチャを変更することも可能である）
文字列を扱う String クラスや、
言語依存の文字列を生成する DateTime の ToString() 等は、
CultureInfo を参照して言語による違いを吸収しているのだ。
さて、ではリソースに関してはどうか。
.NET にはリソースの国際化をサポートする仕組みがある。
昨日使った ResourceManager クラスは、
言語によってリソースを切り替える仕組みを持っており、
GetString や GetObject メソッドは、
現在のカルチャに対応したリソースを取り出してくれるのだ。
ここで疑問点が浮上する。
.NET のリソースは、アセンブリに直接格納され、
リソースごとに固有の名前が付けられる。
リソースとして自由なデータが格納できるため、
これらはカルチャとは無関係のはずだ。
つまり、アセンブリには、言語によって異なる
複数のリソースを格納する場所等はない。
また、昨日作った resx ファイルを見ても、
複数の言語のデータを入力するような場所は見当たらない。
ではどうなっているのか。
.NET は、面白い方法でこれらをサポートする。
リソースを格納したアセンブリを言語ごとに用意するのだ。
つまり、固有のカルチャを持つリソースを含む
独立したリソース専用のアセンブリを作り、
それらをメインのアセンブリから参照して使うのだ。
こういったリソースのみを含むアセンブリを、
「サテライトアセンブリ」と呼ぶ。