開発から見たwindowsの国際化機能
DESCRIPTION
Windowsおよび.NET Frameworkアプリケーションでの国際化要件についてTRANSCRIPT
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.WIN32COM.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/wceinternational5/html/wce50conSpecifyingLocaleswithNLS.htm
Language IDは言語とその文字集合を表す数値 ms-
help://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.WIN32COM.v10.en/msagent/pacontrol_4w2y.htm
Sort IDは照合順序(Collation)を表す数値
Primary LanguageSub LanguageSort IDReserve
Language ID
Locale ID
12bit 4bit 6bit 10bit
.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を通しLPK.DLLにパーシングさせることで間接的に使用することも出来る
Aplication
LPK.DLLUniscribeUser/GDI
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:リソースのパッケージ化と配置
http://msdn2.microsoft.com/ja-jp/library/sb6a8618(VS.80).aspx
MSDN:固有カルチャのリソースの検索と使用 http://msdn2.microsoft.com/ja-
jp/library/s9ckwb4b(VS.80).aspx
MSDN: Windows フォームリソースのローカライズ http://msdn2.microsoft.com/ja-
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
http://d.hatena.ne.jp/NyaRuRu/20070309/p1
http://d.hatena.ne.jp/NyaRuRu/20070310/p1
Creative Commons Attribution-
Noncommercial-Share Alike 2.1 Japan
http://creativecommons.org/licenses/by-nc-
sa/2.1/jp/