開発から見た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の国際化機能

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from Tadahiro Ishisaka

More from Tadahiro Ishisaka (20)

Recently uploaded

Recently uploaded (8)

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