同じUnicode（標準化）でも異なるエンコーディングがあるテーブルたとえばUTF-8エンコードの場合A に対応 0x0041しかし、UTF-16エンコードの場合も同様Aですとして表される 0xfeff0041。
これから素晴らしい記事Windows プラットフォーム用に C++ でプログラムし、Unicode を扱う場合、Unicode は 2 バイトで表現されることを知っておく必要があると学びました。しかし、エンコーディングについては何も書かれていません。(x86 CPU はリトルエンディアンであると書かれていても、その 2 バイトがメモリにどのように格納されるかはわかっています。) しかし、シンボルがメモリにどのように格納されるかについて完全な情報を得るために、Unicode のエンコーディングも知っておく必要があります。C++/Windows プログラマー向けの固定の Unicode エンコーディングはありますか?
ベストアンサー1
Windows のメモリに保存される値は、常に UTF-16 リトルエンディアンです。しかし、ここで話題にしているのはそれではなく、ファイルの内容です。Windows 自体はファイルのエンコードを指定せず、個々のアプリケーションに任せています。
ファイルの先頭にある0xfe 0xffはバイトオーダーマークまたはBOMファイルが Unicode である可能性が高いことを示すだけでなく、Unicode エンコーディングのバリアントも示します。
0xfe 0xff UTF-16 big-endian
0xff 0xfe UTF-16 little-endian
0xef 0xbb 0xbf UTF-8
BOM のないファイルは、そのファイルの書き方がわからない限り、8 ビット文字であると想定する必要があります。それでも、UTF-8 か他の Windows 文字エンコードかはわかりません。推測するしかありません。
これを実行する方法の例として、メモ帳を使用できます。ファイルに BOM がある場合、メモ帳はそれを読み取り、内容を適切に処理します。それ以外の場合は、[エンコード] ドロップダウン リストを使用して自分でコーディングを指定する必要があります。
編集：Windowsのドキュメントがエンコーディングについてより具体的に記述されていない理由は、WindowsがUnicodeを非常に早くから採用していたためであり、当時はのみ1つコードポイントあたり16ビットのエンコード65536 個のコード ポイントでは不十分であると判断されたため、範囲を拡張する方法としてサロゲート ペアが発明され、UTF-16 が誕生しました。Microsoft は既に Unicode を使用してエンコードを参照しており、変更することはありませんでした。