Windows_setmbcp関数では、有効なコード ページを使用できます...
(サポートされていない UTF-7 と UTF-8 を除く)
OK、UTF-7 をサポートしないのは理にかなっています。文字の表現は一意ではないため、複雑さとセキュリティ リスクが生じます。
しかし、なぜ UTF-8 ではないのでしょうか?
私が理解しているように、Windows API 関数の「ANSI」バージョンは引数を UTF-16 に変換し、同等の「W」関数を呼び出し、出力内のすべての文字列を「ANSI」に変換します。これは私が手動で行ってきたことです。では、なぜ Windows がそれを実行できないのでしょうか。
「ANSI」コードページは基本的にレガシーです: Windows 9X 時代。とにかく、最新のソフトウェアはすべて Unicode (つまり、UTF-16) ベースであるべきです。
基本的に、Ansi コード ページが最初に設計されたとき、UTF-8 は発明されていなかったので、マルチバイト エンコーディングのサポートはかなり行き当たりばったりでした (つまり、一部の東アジア コード ページを除いて、ほとんどの Ansi コード ページはシングル バイトです)。これは 1 または 2 バイトです)。とにかくすべての新しい開発を UTF-16 で行う必要がある場合、「適切な」マルチバイトエンコーディングのサポートを追加することは、おそらく努力する価値がないと見なされました。
Microsoft の国際化の専門家である Michael Kaplan は、彼のブログでこれに答えようとしました。
基本的に彼の説明は、Windows API 関数の "ANSI" バージョンが異なるコード ページを処理することを意図しているにもかかわらず、歴史的に、文字エンコーディングにはコード ポイントごとに最大 2 バイトが必要であるという暗黙の期待があったということです。UTF-8 はその期待に応えられず、これらの関数をすべて変更するには、膨大な量のテストが必要になります。
_setmbcp()はVC++RTL関数であり、Win32API関数ではありません。RTLが文字列を解釈する方法にのみ影響します。Win32APIA関数には何の影響もありません。それらがW内部で対応するものを呼び出すとき、A関数は常にコードページ0（）を使用して指定MultiByteToWideChar()し、変換にシステムのデフォルトのAnsiコードページを使用します。WideCharToMultiByte()CP_ACP