これまで、Multilanguage対応は苦手だった(考えていなかった!?)Microsoftが、Internetの影響で遂に本腰を入れた。従来Webブラウザ単体としてみた場合、Multilanguage対応についてはNetscape Navigatorが一歩リードしていたものの「OS本体が対応していない言語は表示できない」という、ごく普通の仕様であった。しかし、IE 3.0では例えば、US版Windows 95へこのInternational Extensions for Japanease Versionを入れると日本語の表示も可能になってしまうのが大きな違いである。
実は、IE 2.0にも"International Extensions for Microsoft Internet Explorer 2.0"が別モジュールとして存在していたが、今回IE 3.0になってこれを標準機能にしてしまったのだ。きっと、27カ国語個別対応するのに疲れたのだろう。(冗談)
すでに、エンジンは載っている状態なので、言語別のモジュールをインストールすればその言語が表示できてしまう。
現在、Microsoftのホームページにあるモジュールは、以下の通りである。
IE 3.0 International Extensions for Windows 95 & NT 4.0 - Chinese (Traditional)Version
IE 3.0 International Extensions for Windows 95 & NT 4.0 - Japanese Version
IE 3.0 International Extensions for Windows 95 & NT 4.0 - Korean Version
IE 3.0 International Extensions for Windows 95 & NT 4.0 - Pan Euro Version
これらのモジュールは、各国語Windows 95/NT 4.0すべての組み合わせで使用可能となっている。ただ残念な事は、同時リリースのInternet Mail News 1.0では機能しない事だ。IMEが動かないので入力できないまでも、せめて表示できる様になればかなり便利になるのだが……。 >Microsoft
実際インストールすると、例えばJapanese Versionの場合、組み込まれるモジュールは、
この2つで、ファイルコピー後、レジストリに情報を加えている。
「IE 3.0だけこんな美味しい機能を使っているのはもったいない!!」と考えた筆者は、そのカラクリを調べた。どうやらUnicodeを使っている様だ。「NT 4.0はともかく、Windows 95のUnicode APIって機能したっけ!?」と、MSDNでサーチしたところ……。
Windows 95で使用可能なワイドキャラクターAPIは、MSDN News: 1995 #4 "Yes,Virginia, Windows 95 Does Do Unicode!"によると、
※1 実際にはGetTextExtentWは存在しない。そもそも、GetTextExtentはWin32で削られ、代わりにGetTextExtentPoint32を使う様になっているため、GetTextExtentPointWで置き換えれば問題無い。
このAPIがWindows 95で機能するとなっている。VC++ 4.0でこれらのAPIを使用するには、プロトタイプを自分で宣言しなければならない。プロトタイプは、WINGDI.Hに記述されているのでそれをコピーする。(この時、「extern "C"」の指定を追加することを忘れない様に)もちろんVC++ 4.1以降の場合には不要である。
1.GetACP()で取れるコードページは932(Japanese)ではない。
MultiByteToWideChar()で変換するときにCP_ACPや、GetACP()で得られる値ではなくShiftJISの場合932を指定しなければならない。この時、IsValidCodePage()を使い932が使用可能かをチェックする。
2.IsDBCSLeadByte()や、CharNext/Prev()のようなAPIは動かない。
GetCPInfo()でリードバイトのレンジが取れるのでそれを使い、自力で処理する必要がある。すべては確認していないが、これまでの経験から以下のAPIはそのまま使ってはいけないと思われる。
3.メニュー/ダイアログ等のシステムが表示するものは不可。(つまり英語)
4.現状では入力はできない。(IMEが動かない)
5.禁則処理は自前で行う。
非常に簡単な例であるが、サンプルコードを載せる。(社内で正常に動く事は確認済み)もちろん、このコードは日本語版Windows 95でもそのまま動くので、やる気になれば各国語対応アプリケーションを一つのエンジンで作る事も可能である。
void CxxxView::OnDraw(CDC* pDC) { // m_Fontは表示フォントを持っているCFontクラス CFont* oldfont = pDC->SelectObject(m_Font); // 表示する文字列はUnicodeで定義 // もちろんMultiByteToWideChar()を使ってダイナミックに変更してもOK wchar_t* str1 = L"This is Englishtext."; wchar_t* str2 = L"これは日本語のテキストです。"; // Unicode対応の文字列表示関数で表示 TextOutW(pDC->GetSafeHdc(),0, 0,str1,wcslen(str1)); TextOutW(pDC->GetSafeHdc(),0,20,str2,wcslen(str2)); // VCで普通に使うとUnicodeアプリ以外はDrawTextWが使えない仕様である // 従って下記のコードはコンパイルできない // DrawTextW(pDC->GetSafeHdc(),str1,wcslen(str1),(LPRECT)&rect1,DT_LEFT); // DrawTextW(pDC->GetSafeHdc(),str2,wcslen(str2),(LPRECT)&rect2,DT_LEFT); pDC->SelectObject(oldfont); }
同じMicrosoftから出ている日本語TrueTypeFontと言っても、実は3種類存在する。
実験した結果、ヘッダー情報が違うらしくInternational Extensions付属のMSGOTHICしか使えない。筆者はフォントについて詳しくないが、フォント・メーカーなら調べれば何処が違うか直ぐにわかるだろう。余談になるが、もうそろそろ飽和状態の日本から、このInternational Extensions用にフォントをコンバートして海外向けに販売してはどうだろうか!? >各フォント・メーカー
如何だろうか!?IMEが動かないので、ワープロなどに応用するのは少し辛いが、辞書や翻訳系のアプリケーションであれば問題なくこの技術は応用でき、日本語・英語版Windows 95対応が即可能になる。ただ問題があるとすれば、IE 3.0を事前にインストールしないと、このInternational Extensionsが組み込めないのだ。幸い、IE 3.0は無料なのでバンドルし、更にこのInternational Extensionsも入れておけばOKである。但し、この作戦では競合メーカーは(プライドから)使えない。基本的にIE 3.0とこのInternational Extensionsの技術は無関係なのでMicrosoftは仕様を公開すべきだろう。
このページに関するご意見・ご感想などございましたら、筆者までメールをお願いします。