名前: 森本 日時: 2005-05-11 23:32:29 IPアドレス: 218.217.61.*
>>35800 Windowsプログラミングはド素人ですが、gcc-3.2.3のSJIS対応に一時 関わっていた手前、わかることだけレポートさせていただきます。 > 問題は，これをどういうエンコーディングにすればnonunicodeで > ないほうでちゃんと表示されるか いろいろ試みましたが、今のバイナリでは原理的に無理なようです。 リソーススクリプトの識別子(ID)を用いてメニュー文字列を差し替えている ように推測されます。unicode版でも、de.txt等言語設定ファイル（とその 中の識別子）はASCIIエンコード（厳密にはISO-8859-1）になっています。 jp.txtを単にunicode(UTF-7/8/16)にすると識別子までマルチバイト文字に なってしまい、バイナリレベルでは識別子が不一致となるので、 差し替え文字列が認識されません。これはde.txt, fr.txt等でも同じです。 unicode版にSJISのjp.txtを与えると、文字列差し替えはできる（＝識別子は 認識されている）ものの、メニューが文字化けするのはご存知のとおりです。 バイナリエディタを用いて、識別子をASCIIのままとし、差し替え文字列のみを unicodeに書き換えたjp.txtファイルを用いても文字化けします。 その化け方を見る限り、マルチバイト文字の扱いに誤りがあります。というか、 マルチバイト文字として認識していません。1byte系として認識されてます。 マルチバイト文字を2byteばらばらに評価したときにprintableなbyteだけが 表示され、printableでないbyteが化けるのです。 jp.txtを読み込むルーチンがASCII用のものなのに、取り出した文字列を 生のまま、メニュー表示ルーチンでunicode用ライブラリに渡している 可能性があります。 あるいはMultiByteToWideChar()の使い方がおかしいのかもしれませんし、 内部で文字列型がwchar_t（VC++ではTCHAR）でなくcharになっていて 暗黙型変換されているのかもしれません。 （自信がありません。詳細は詳しい方よろしくお願いします） > そもそもこのnonunicodeでないバージョンにバグがあるのでしょうか。 nonunicode (=ASCII) のほうが正常動作です。ASCII用のライブラリなので、 Shift JISを与えると日本語Windows上では文字列が正しく表示されて当然です。 すなわち日本語Windowsではde.txtやfr.txtが文字化けし、英語Windowsでは jp.txtが文字化けします。「表示」とか0x5Cを含む漢字が化けないのは、 実行時にバイナリレベルでSJISが読み込まれASCII用ライブラリに与えられて いるためです。 unicode版のバグともいえますし、あるいは不可避の仕様かもしれません。 unicodeエンコードの言語設定用ファイル（当然、識別子はASCII文字も含めて 1文字が2byte）を読み込んで認識できることが必要と思いますが、非マルチ バイト圏用Windows上の.NET（バイナリを見る限りコンパイラは.NETと推測） を用いて、マルチバイト圏用の実行ファイルを作成可能かどうか、私には わかりません。 お詳しい方、よろしくお願いします。
この書き込みへの返事：