開発から見たWindowsの国際化機能

NT Committee2 石坂忠広
MVP for Visual Developer C#

 http://www.isisaka.com/
 NT-Committee2会員
 PASS-Jスタッフ
 Microsoft MVP for Visual Developer C#

 なぜ国際化なのか
 従来の国際化(日本語化)
 World Ready
 ローカライズ
 文化・カルチャ？

 企業の多国籍化
 オフショア
 日本語がネイティブでない環境での開発
 コア部分開発とUI部分の分業
 国内市場の行き詰まり
 日本以外のマーケットを開拓する
 すべてが日本語化されるべきと期待される今
の特権的地位はいつまで続くだろうか

 いずれかの言語でアプリケーションを開発す
る
 たいていは英語で開発する。
 それを各国語に翻訳する。
 リソースDLLは分かれているか？
 バイナリリソースエディタでテキストを置き換える
 ソースコード内のテキスト文字の翻訳
 sed s/hoge/ほげ/でうまくいくのか

 バイナリリソースエディタ
 そもそもオリジナルの作成者が国際化を前提に、
リソースを外部DLL化してくれていないといけな
い。
 確かにテキストの置き換えは簡単にできる。
 エリアからはみ出す文字、余りすぎるテキスト
ボックス。文字が途中でとぎれるボタン。
 エディタでリサイズ・チェック、リサイズ・
チェック
 ああ「能」の字が化けてる。orz

 ソースの変更
 ああここも直ってない。。
 一千も二千もあるソースリソースからテキストを見
つけ出さなくちゃいけない。
 エラーメッセージが英語だよ。
 そ、それは、英語ランタイムが出すメッセージだか
ら直せないんだよ。。。
 やっぱり「能」の字が化けるよ。orz
 バックスペースしたら、漢字が半分無くなったよ。

 日本語ランタイムと英語ランタイムの違いが
あり、日本語を正常に扱うには日本語の開発
環境でビルドが必要。
 でも、どことは言わないけど日本語ランタイ
ムには英語にないバグがっ
 そもそも開発元が日本語環境でのビルドを許
してくれない。(ソースを渡してくれない)

 まだこの状態で苦しんでおられる方が多いと
思います。
 根本的解決策は、なんとしてもソースコード
を入手すること、翻訳後のソースは向こうで
管理させることです。
 もしくは、根本的に作り替えるこ
と！

 言語を問わずシングルバイナリを目指して開
発すること
 Windowsのもつ国際化対応機能を柔軟に使用
し、それらの支援を受けながらアプリケー
ションの仕様決定、開発を行う。
 開発を二つに分ける
 Core CodeのGlobalization化
 リソースDLLによるLocalize

 Unicodeに完全対応したアプリケーションを記述す
る
 コード内で数値、金銭、日付等のフォーマッティン
グを直接行わない
 テキスト入力の言語、入力方法の違いを考慮する
 特定のフォントに依存させない
 テキスト中の複数言語混在に対応させる(m17n)
 MUIに対応させる
 UIのローカリゼーション容易性への配慮
 右から始まる言語への配慮(UIのミラーリング)

 UNICODE自体の説明は省きます。
 以下の点はまず注意してください
 Windowsのバージョンによって、対応している
UNICODEのバージョンが違います。
 その他、Java, VB, VC++(CRT)のそれぞれのバージョ
ンが持つランタイムでも対応しているUNICODEの
バージョンが違います
 これで何がまずいか？
 使える文字と使えない文字が出て
きます

 Windows 2000
 UNICODEに完全対応した最初のバージョン
 UNICODE 2.0
 UCS-2エンコード
 Windows XP / 2003
 UNICODE 3.0
 UTF-16LE以下同様
 .NET Framework
 UNICODE 3.2
 いわゆるJIS2004の文字を含む
 Windows Vista / 2008
 UNICODE 5.0

 SQL Server(7.0以降)
 UCS2 + サロゲートペアに対応
 一応UNICODE 3.0以降の文字もnchar, nvarchar
フィールドには格納できる。
 ただ、いろいろ問題が。。
 詳しくはPASSJアフタースクールへ(宣伝)
 Officeは？Exchangeは？？？？

 アプリケーションをUNICODE対応とするには
 ネイティブコード
 あんまり詳しくやりません(終わらなくなる)
 #define UNICODE
 Visual StudioではWizardの中でチェックをする/しない
 文字列
 LPTSTRマクロを使う(UNICODEがDefineされていれば
自動的にLPWSTRに変えてくれる)
 文字列定数の前には大文字のLをつける
 LPTSTR str = L”僕の名前は石坂忠広です。”;
 MFCが使えるならCStringクラスを使う
 COMはVT_BSTRで
 これらは相互変換のマクロ、クラスメソッドがある

 .NET Frameworkでの開発
 .NET FxはUNICODEに完全に対応
 内部では文字列はUTF-16でエンコードされる。
 char型は2バイト
 ただし、テキスト入出力とXMLのデフォルトエン
コーディングはUTF-8なので注意。
 基本的にIEが使用できる文字コード(Shift-
JIS/EUC.jp)にはファイル入出力の時点で変換する
ことが出来る。同様にコードページを指定したエ
ンコード、デコードも可能。

 WEB Page
 基本的にはW3Cの標準通り。
 現状はUTF-8を推奨
 Java
 内部はUTF-8
 コマンドプロンプト
 基本的にUNICODEには対応していない
 ただし、表示できる範囲ではUNICODEとの相互
変換が自動的に実行される

 Locale(ロケール)
 本来は英語の意味通り地域(ローカル)を表す。
 かつてC言語標準化の中で、ローカル変数の
「ローカル」と紛らわしいとされ、訳語が「ロ
ケール」に統一されたと聞いています
 Windowsでは特定の国や地域の言語と文化上の慣
例を反映させた Windows 設定のコレクションの
意味です。

 System Locale
 UNICODE以外での言語環境を特定します。
 DOS, OS/2, Win16でのCode Pageに該当します。
 いわゆるANSI APIが使用された場合、この設定に
より実際の言語・文字コード(CP)が特定されます。
 User Locale
 User毎に設定するLocale。
 設定は小林さんスライド参照。
 名前と違い実際には非ログオンのサービスアカウ
ントにも影響

 Thread Locale
 実行単位毎に持つLocale。何もしなければUser Locale
を継承する。
 つまりUser Localeと違うロケールをスレッド毎に持
つことも可能
 Input Locale
 文字入力のLocale。
 言語ツールバーで設定する。
 インプットメソッドの切り替え
 User Locale以降のLocale操作、状態の取得、機
能の使用にはNLS APIを使用する。

 WindowsおよびWindows上に実装されたアプ
リケーションで複数地域・複数言語に対応す
るためのAPIセット
 NLS APIが持っている機能
 現在のLocale設定の取得
 動的なThread Localeの変更
 数値、日付等のフォーマット
 ロケールに合わせた並び替えの支援
 Input Method系のAPI

 NLSの各設定（書式とか）はLCIDで管理されている
 NLS APIに何か仕事をさせたい場合にはLCIDでロ
ケールを指定して、仕事をさる。
 LCIDはロケール毎に一意に32ビットの整数値で番号
を持つ。
 Windows Vista以降で追加されたAPIではLocale
Name(Exp. Ja-Jp)で指定できる場合がある。
 Locale Name:
ms-
help://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.WIN32CO
M.v10.en/intl/nls_Locale_Name.htm

 LCID自体は16ビットのLanguage IDと4ビットのSort IDからなる。
 ms-
help://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.WINCE.v50.en/wceinter
national5/html/wce50conSpecifyingLocaleswithNLS.htm
 Language IDは言語とその文字集合を表す数値
 ms-
help://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.WIN32COM.v10.en/msa
gent/pacontrol_4w2y.htm
 Sort IDは照合順序(Collation)を表す数値

Language ID

Reserve Sort ID Sub Language Primary Language

12bit 4bit 6bit 10bit

Locale ID

 .net FxではCultureInfoクラスでLCIDを管理す
る。
 カルチャの名前、書記体系、使用される暦、
日付の書式設定と文字列の並べ替え方法など、
特定のカルチャに関する情報を提供する。

全ロケールの取得とカレントロケールの取得

 日付の書式
 通常どちらかの書式を使用する
 Long Format(長い形式)
 英語(US)：Saturday , October 27, 2007
 日本語：2007年10月27日
 Short Format(短い形式)
 英語(US)：10/27/07
 日本語：07/10/27
 日本の年号への対応、ヘブライ歴等の西暦以外
への変換

 テキストフォーマッティングの書式で日付書
式文字の”d”(Short Format)や”D”(Long
Format)等を使用する。
 逆に”YYYY/mm/dd hh:mm”のような固定書式
にしてはいけない。
 このように記述してしまったコードはもはや
Globalization対応とは言えない
 http://msdn2.microsoft.com/ja-
jp/library/az4se3k1(VS.80).aspx

日付のフォーマッティング

 12時間か24時間か
 時刻の書式文字で区別
 hまたはhh:12時間計、HまたはHH:24時間計
 時分秒の区切りに文字を使うのか
 タイムゾーンと現在時刻
 NLSのロケールで現在時刻を求めないので注意
 TimeZone設定でUTCから現地時間の算出を行う
 そのときには夏時間の設定がそのタイムゾーンに
あればそれを考慮して現地時間を算出する

Vistaでは世界地図が無くなって寂しい

 時刻書式の詳細は書式文字列を使って行う
 カスタムの書式
http://msdn2.microsoft.com/ja-
jp/library/8kb3ddd4(VS.80).aspx
 TimeZone
 TimeZoneに関する操作はSystem.TimeZoneクラ
スを使用します。
 http://msdn2.microsoft.com/ja-
jp/library/system.timezone.aspx

時刻書式とTimeZoneの処理

 金銭の単位
 日本：¥
 アメリカ：$
 マイナス値の表示方法
 小数点
 日本・アメリカ：「.」
 欧州：「,」
 桁区切り
 日本・アメリカ：「,」
 欧州：「.」

 テキストフォーマッティングの書式で金銭書
式文字の”c/C”や十進数書式”D”等を使用する。
 日付の場合と同様固定書式にしてはいけない。
 このように記述してしまったコードはもはや
Globalization対応とは言えない
 標準の数値書式指定文字列
http://msdn2.microsoft.com/ja-
jp/library/dwhawy9k(VS.80).aspx

 ロケール毎に文字列の並び替えに使用するため
の文字毎の重み付けと何と何を同じ文字として
扱うかという設定がある。
 これをSQL Serverでは参照順序(Collation)と呼
ぶ
 ロケール毎に複数の参照順序を持つ場合がある
 現在のWindows Vistaの場合Ja-JPの場合XJIS(デフォ
ルト)と部首・画数の二種類がコントロールパネルか
ら選択可能
 日本語関連 CompareInfo と、部首画数での並べ替え
＠河端善博ブログ / SQL Server / PASSJ
 http://blogs.sqlpassj.org/yoshihirokawabata/archive/2007/
07/27/23864.aspx

 .net FxのString.Compare()メソッドやArrayク
ラスのSortメソッド等ではスレッドのカル
チャが持つソート順序を使用して処理を行う
 並び替えの設定によっては単純なコード順並
び替えや比較ではないので注意する

 ロケールの管理、各種機能はNLS APIにより
提供される
 Locale, CultureはLCIDで管理される
 日時、金銭、数字のフォーマットは自分で
コードに細かく記述せず、NLSに任せる
 テキスト比較はソート順序の設定が使用され、
その設定が目的通りに設定され英無いと予想
外の結果になる

 Input Language
 Complex Script
 Font

 Text Service Framework(TSF)
 Windows XP以降Input Method
Manager(IMM/AIMM)がText Service
Framework(TSF)に拡張されていく中で、ただの
アジア言語(日本語)入力機能から、複数言語入力
の切り替え、キーボードマップの動的な変更、音
声入力、手書き入力等への拡張がなされた。
 .net FxではInputMethodクラスで制御を行う

 複数言語を同一データ内で同時に入力、表示、
保存させること
 UniscribeといわれるUnicode Script
Processor(USP10.DLL)がComplex Scriptの実行
エンジンになっている
 Applicationは直接
Uniscribeを呼び出すこと
も出来るし、GDIを通し Aplication
LPK.DLLにパーシングさ
せることで間接的に使用
することも出来る User/GDI
LPK.DLL
Uniscribe

 Standard Edit Control
 Complex Scriptに関して標準的に対応されている。
 実装例：
 メモ帳(Notepad.exe)
 Rich Edit Control
 Text Object Model(TOM)のインターフェイス
 Uよりリッチな多言語環境、マルチフォント環境の提供
 実装例：
 ワードパッド
 アプリケーション開発においては、これらのコント
ロールを使用するのが現実的

 .net Framework
 .NET Fx 2.0以降ではGDI+のComplex Script対応機能
を使用し、Windows Formのすべてのコントロールで
同レベルのサポートを実現している
 Application.SetUseCompatibleTextRenderingDefault
メソッドをプロセスでFormを最初に作るときに呼び
出すことで、個別コントロールでの設定をなくすこと
が出来る
 Complex Scriptに関するMSDN Magazineの記事
 http://msdn.microsoft.com/msdnmag/issues/06/03/Text
Rendering/

 最終的に文字を表示できるかどうかはFontで決まる。
 Globalizationに対応したFontを使用する
 UIにはシステムフォントを使う
 Windows XP / 2003 / VistaはTahomeを標準に
 はねのないゴシックのLattain-1、ヘブライ語用フォント
 フォントリンクもしくはFallbackでそのほかの言語用フォント
がリンクされており、体裁はともかくとにかく表示はしてくれ
る
 Arial Unicodeの問題
 Unicode 2.0「の」文字はすべて表示可能
 それゆえに表示できない文字がある

 Fallback
 Uniscribeが現状フォントで表示できない文字列がある
と判断した場合に、その文字が表示可能なFontを割り
当てる。
 GDI+のテキストレンダリングエンジンが使用する
 そのときにどのフォントを割り当てるか重み付けがあ
るらしく、どうもそれがVistaで変更されようだ。
 かつて漢字が表示できない場合にはMSPゴシックが選択
されたが、VistaではMingLiuが選択される確率が高いよ
うに思える。MingLiuはセリフフォントなので、見た目
が変わりすぎるので困るのだ

 Font Linking
 システムフォントが文字列を表示できなかった場
合にどのフォントで代用するかを指定した設定
 レジストリの
HKLM¥SOFTWARE¥Microsoft¥Windows
NT¥CurrentVersion¥FontLink¥SystemLinkにその
設定がある
 Font LinkはGDIのレンダリング、GDI+でFall Back
がうまくいかなかったときに使用される

 アプリケーションのMUI
 MUIの戦略
 言語毎の実行ファイル。各言語リソースは、コー
ドと一緒に一つのバイナリに
 一つの言語ニュートラルな実行ファイルと複数言
語のリソースを含んだ1つのリソースDLL
 一つの言語ニュートラルな実行ファイルと格言午
後とのリソースDLL
 今のWindowsそのものを含む一般的なMUIの戦略

 作成手順
 何かの言語で実行ファイルとリソースをビルドす
る。(この時の言語がデフォルトリソースとなる)
 追加リソースのDLLを作成する。
 実行時のリソースの選択順序
 まずデフォルトリソースで起動される。
 現在システムのMUIで設定されているロケールと
同じリソースDLLがあればそれをロードする。
 システムのMUI設定にかかわらずUIのロケールを
User Localeにあわせて変更するにはカレントス
レッドのCurrentUICultureプロパティをコンポー
ネントの初期化前に変更する。

 ＠IT .NET Tips Windowsフォームを多言語対
応にするには？
 http://www.atmarkit.co.jp/fdotnet/dotnettips/314win
multilang/winmultilang.html
 一番簡単で、有用なチュートリアル
 作業が増えるだけで、これ以上でも以下でもない

WinFormでのMUIアプリケーションの作成
UIをUser Localeにあわせて変更する。

 ローカライズ対象となるリソースの分離
 文字列だけでなく、図、ビットマップ、ダイアログ
ボックスも必要に応じてCoreのバイナリから分離する。
 .net Fxにおける詳細
 MSDN:リソースのパッケージ化と配置
jp/library/sb6a8618(VS.80).aspx
 MSDN:固有カルチャのリソースの検索と使用
jp/library/s9ckwb4b(VS.80).aspx
 MSDN: Windows フォームリソースのローカライズ
jp/library/yys3e2fd(VS.80).aspx

 アラビア語のような右から書き始める言語に
合わせ、諸々のUIを右から書き始めるように
する。
 ツリービュー、グリッドコントロールの開始位置
が右など
 標準コントロールや.net FxのWinFormのコント
ロールでは、各コントロールの右から書き始めを
示すプロパティをセットする。
 .NET Fx ではRightToLeftプロパティが一般的

http://msdn2.microsoft.com/ja-jp/library/aa350685(VS.80).aspx

NLSで対応できない文化的な違いをどうするのか

 日本人は感覚的に理解できない
 毎時処理等では、夏時間の開始時と終了時に
は1日の時間が24時間ではないので注意が必
要(特別な処理がたいていに場合には必要)
 可能な限り時刻をキーとしたデータ管理では、
時刻データとしてはUTCを使用する。
 時差があってもデータの比較を行いやすくする
 夏時間の影響を排除する

 国や地域によって、住所のルールが違う
 特に日本は住所から位置の推定が全く出来な
い。600番地の隣が865番地なんて欧米では
ほぼあり得ない
 基本は可変長テキストで保存
 特定の位置情報が必要であれば、ジオメトリ
のデータを使用する。(経度緯度情報など)

 米と欧・日での用紙サイズの違い
 米国はLetter, Legalが標準的な用紙サイズ
 欧・日その他多くの地域はISO(JIS)のA4, A3等の用紙
サイズ
 特定の用紙を前提とした印字処理をしない
 プリンタの問題
 欧米：ビジネス用途ならHP-PLかPost Script何れか
 日本：メーカー毎のページ記述言語。。
 WindowsのAPI経由ではあまり大きな問題にならない
が、プリンタドライバ、それの英語版があるか無いか
はかなり問題が起こるポイント
 正直なところ世の中のプリンタメーカはHPだけでい
いです

 正直NLS APIで面倒見てくれないかと思う
 EUが妥協して、イギリスはメートル法とヤー
ド・ポンド制を併用してよくなった(Fack)
 アプリケーションで何とかするしかない
 基本はSI単位(SI条約)を使用する
 国内では非SI単位の使用は原則システム提供側
が計量法違反
 商慣習上必要な場合、法適用外あるいはお目こ
ぼしされる
 真珠の匁（もんめ）
 印刷でのヤード・ポンド制使用

 パッケージやアプリケーション内で人物写真
を使う場合何か注意がいるのか？
 多分日本人（多分韓国人、中国人も）には感覚的
に理解できない
 多くの国で、人種、性差に対しての配慮が必要
 子供の取り扱いもかなり微妙

 基本的に女性の写真を使うのはNG
 イスラム的正しさが必要
 ほかのアラブ諸国ではここまで厳しくない

 会議を表す図か写真をアプリケーションで使
いたい場合
 あきらめてこれらの図の
ように人物を入れないか、
人としかわからない図に
する

 NLSのCultureはあくまでもビジネスの世界か
ら見た地域文化やルールのわずかな一側面に
対応するだけ
 UIを翻訳すればLocalizeなんだろうか？
 Localizeとは結局その地域の文化にアプリ
ケーションを対応させること
 Excelのふりがな

 基本は英語版OS, 英語版Visual Studio
 今でも原則はen-US版アプリケーションを作成し、そ
れを別言語にする
 多言語化ターゲットの試験環境
 仮装化環境で用意するのが便利
 パフォーマンス試験が基本言語環境以外でも必要か設
計時に見積もる
 MSDN サブスクリプションサービスの購入が必
須
 Vistaは本当にシングルバイナリで、多言語開発
環境として英語版以外でもそれが可能なのか？

 バージョン管理システムのスケール、柔軟性につい
て考慮が必要
 インターネット環境ではVSSは使い物にならない
 国際イントラネットがある場合には何とかなることもある
 TFSは多国籍間の開発に耐えられるか？
 国をまたがる開発環境での調査、試験は未実施
 Subversion推奨
 TatoiseSVNがある
 Visual Studioのアドインもあるけど使っていません
 ディレクトリ構造にはVS管理のリソース以外のドキュメン
ト等についても多言語であることを留意して標準化を

 コメント
 開発チームが複数にまたがる場合、コメントに日
本語やその他のローカル言語を許容するのか決め
る必要がある
 訳語の統一
 少なくともプロジェクト内ではExcelでもいいから
訳語のデータベースを作って訳語の統一を図る
 マイクロソフトの取り組みが参考に
 前者および翻訳プロバイダまで含めた訳語データ
ベースの作成による訳語の管理

 欧米人には漢字は絵にしか見えない。(文字
として認識することにまず訓練がいる)
 欧州人開発者における国際化とは
ISO-8859(Latin-1)の中で各国語とそれ用の
キーボードに対応することであり、DBCS環
境への対応ではない
 とにかく最初は理解されることは期待できな
いので、粘り強く交渉

 Developing International
Software, Second Edition
 著者 Dr. International
 ISBN 0-7356-1583-7
 CJKV日中韓越情報処理
 著者 Ken Lunde
 ISBN 4-87311-108-0

 文字コード超研究
 著者深沢千尋
 ISBN 978-4899770510

 JIS X 0213:2004 / Unicode 実装ガイド
 http://download.microsoft.com/download/e/3/c/e3c
1a451-1882-49fe-86a8-
e25680f6c46c/JIS_Unicode_guide.pdf
 Microsoft SQL Server 2005 のインターナ
ショナル機能
 http://www.microsoft.com/japan/msdn/sqlserver/sq
l2005/bb330962.aspx

 Microsoft Global Development and
Computing Portal
 http://www.microsoft.com/globaldev/default.mspx
 Sorting It All Out (Michael Kaplan's)
 http://blogs.msdn.com/michkap/default.aspx

 Windows XP Professional の多言語機能
 http://www.microsoft.com/japan/technet/prodtechn
ol/winxppro/plan/multilingual.mspx
 NyaruruさんによるTFS解説
 http://d.hatena.ne.jp/NyaRuRu/20070308/p1

 Creative Commons Attribution-
Noncommercial-Share Alike 2.1 Japan
 http://creativecommons.org/licenses/by-nc-
sa/2.1/jp/

開発から見たWindowsの国際化機能

More Related Content

What's hot

Similar to 開発から見たWindowsの国際化機能

More from Tadahiro Ishisaka

Recently uploaded

開発から見たWindowsの国際化機能