2

C++ で新しいコマンド ライン アプリケーションを作成しています。私たちがサポートするプラットフォームの 1 つは、もちろん Windows です。

デフォルトでは、Windows コンソールはロケールに応じて OEM コード ページを使用します (たとえば、私のマシンでは CP437 / DOS.Western です)。Windowsのキリル文字版だったらCP866とかだったと思います。これらの OEM コード ページには 256 文字しか含まれていません)

これは、Windows コンソールが入力キー ストロークをデフォルト コード ページに基づいて文字に変換することを意味すると思います。(また、現在選択されているフォントによっては、対応するグリフがあれば表示されます)。

  1. このような場合、アプリケーションで wmain/wchar_t および wide char 型を使用することは理にかなっていますか?
  2. ワイドタイプを使用する利点はありますか? または、char * だけを使用すると重大な問題がありますか?
  3. ワイド char 型が使用されている場合、コマンド ライン引数と環境文字列のエンコーディングは何ですか - (wchar_t * argv[] および wchar_t * envp[])、つまり。それらは Windows CRT によって UTF-16 に変換されますか、それともそのままですか?

貢献していただきありがとうございます。

4

1 に答える 1

2

Windows が指定されたコードページで内部的に動作すると想定しているようです。それは真実ではない。Windows は内部的に Unicode (UTF-16) で動作します。charの代わりに使用するレガシー ソフトウェアのwchar_t場合、入力と出力は指定されたコードページに変換されます。

これが意味することは、Windows コンソールが入力キーストロークをデフォルトのコードページに基づいて文字に変換することだと思います

これは正しくありません。(Unicode) 文字へのキー ストロークのマッピングは、キーボード レイアウトによって定義されます。これは、コード ページから完全に独立しています。たとえば、キリル文字のコード ページを使用するシステムで中国語のキーボード レイアウトを使用できます。

  1. を使用するのは完全に理にかなっているだけでなくwchar_t、推奨される方法です。
  2. はい、利点があります。プログラムは、Windows でサポートされているすべての文字を処理できます。char を使用する場合、現在のコード ページにない文字は処理できません。
  3. それらは変換されません。つまり、UTF-16 文字のままです。

残念ながら、コマンド プロンプト自体は「ANSI」アプリケーションであるため、「ANSI」のすべての制限を受け、コマンド プロンプトから使用するとアプリケーションに影響します。ただし、コンソール アプリケーションは、コマンド プロンプト ウィンドウなしで他の方法で使用でき、Unicode を完全にサポートできます。

于 2013-03-10T22:06:00.640 に答える