ここや他の場所 (以下を参照) の他の多くの投稿を見てきましたが、この質問に対する明確な答えはまだありません。
あれは：
では、Windows で (U+2008A) Han Character のようなコードを書きたい場合、Windows は何をするのでしょうか?
wchar_tWindows stdlibでの実装はUTF-16に依存しません。これは、約16ビットのコードユニットしか認識していません。
したがって、UTF-16サロゲートシーケンスを文字列に入れることができ、より高いレベルの処理を使用してそれを単一の文字として扱うことを選択できます。文字列の実装は、あなたを助けたり、邪魔したりすることは何もしません。これにより、UTF-16として解釈されたときに無効になるコード単位のシーケンスを文字列に含めることができます。
Windowsの高レベルの機能の多くは、UTF-16サロゲートで作成された文字をサポートしています。そのため、ファイル.txtを呼び出して、正しくレンダリングされ、正しく編集されることを確認できます（2回ではなく1回キーを押すだけで、文字）複雑なテキストレイアウトをサポートするExplorerなどのプログラム（通常はWindowsのUniscribeライブラリを使用）。
ただし、UTF-16の忘却が透けて見える場所はまだあります。たとえば.txt、と同じフォルダに呼び出されたファイルを作成できるという事実.txt、大文字と小文字を区別しないと許可されないという事実、または作成できるという事実などです。[U+DC01][U+D801].txtプログラムで。
これは、WindowsがUTF-16文字列を「サポート」するのかUCS-2のみをサポートするのかについて、衒学者が長くて基本的に無意味な議論をする方法です。
Windows は以前は UCS-2 を使用していましたが、Windows 2000 では UTF-16 を採用しました。現在、Windows の wchar_t API は UTF-16 を生成および使用しています。
すべてのサードパーティ プログラムがこれを正しく処理するわけではないため、BMP 以外のデータでバグが発生する可能性があります。
また、可変長エンコーディングである UTF-16 は、wchar_t で使用されるエンコーディングの C または C++ 要件に準拠していないことに注意してください。これにより、wctomb などの単一の wchar_t を取る一部の標準関数が Windows で BMP を超える文字を処理できない、および Windows が単一の文字を処理できるようにするために、より広い型を使用するいくつかの追加関数を定義するなど、いくつかの問題が発生します。 BMPの外。どの関数だったか忘れましたが、wchar_t の代わりに int を返す Windows 関数に出くわしました (そして、EOF が返される可能性のある関数ではありませんでした)。