Unicode 変換形式 8 ビット (UTF-8) 文字エンコードを使用して、Web アプリと他の *nix ベースのプラットフォーム (Unix、Linux、およびバリアント) 間の互換性を最大化し、ローカライズのバグを最小限に抑え、テストのオーバーヘッドを削減します。
UTF-8 は国際化のためのユニバーサル コード ページであり、Unicode 文字セット全体をエンコードすることができます。 これは Web 上で広く使用されており、XML ベースと *nix ベースのプラットフォームの両方の既定のエンコードです。
プロセス コード ページを UTF-8 に設定する
Windows バージョン 1903 (2019 年 5 月の更新) の時点で、appxmanifest でパッケージ化されたアプリ (またはパッケージ化されていないアプリの場合は Fusion マニフェスト) の activeCodePage プロパティを指定して、プロセスで UTF-8 をプロセス コード ページとして使用するように強制できます。
注
Windows グラフィックス デバイス インターフェイス (GDI) では現在、プロセスごとの activeCodePage プロパティの設定はサポートされていません。 代わりに、GDI はデフォルトでアクティブなシステム コード ページに設定されます。 GDI 経由で UTF-8 テキストをレンダリングするようにアプリを構成するには、Windows の設定> 時刻と言語>言語と地域>管理言語設定>システム ロケールの変更 に移動し、 ベータ: 世界中の言語をサポートするには Unicode UTF-8 を使用します。 次に、変更を有効にするために PC を再起動します。
activeCodePage プロパティを宣言し、以前の Windows ビルドでターゲット/実行することはできますが、従来のコード ページの検出と変換は通常どおり処理する必要があります。 Windows バージョン 1903 の最小ターゲット バージョンの場合、プロセス コード ページは常に UTF-8 になるため、レガシ コード ページの検出と変換を回避することができます。
注
UTF-8 では、エンコードされた文字は 1 から 4 バイトのシーケンスで表されます。 (正式な仕様については、Unicode 標準の第 3 章の定義 D92 を参照してください)。
例
パッケージ化されたアプリの場合は appx マニフェスト:
<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
...
xmlns:uap7="http://schemas.microsoft.com/appx/manifest/uap/windows10/7"
xmlns:uap8="http://schemas.microsoft.com/appx/manifest/uap/windows10/8"
...
IgnorableNamespaces="... uap7 uap8 ...">
<Applications>
<Application ...>
<uap7:Properties>
<uap8:activeCodePage>UTF-8</uap8:activeCodePage>
</uap7:Properties>
</Application>
</Applications>
</Package>
パッケージ化されていない Win32 アプリの場合は fusion マニフェスト:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity type="win32" name="..." version="6.0.0.0"/>
<application>
<windowsSettings>
<activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
</windowsSettings>
</application>
</assembly>
注
mt.exe -manifest <MANIFEST> -outputresource:<EXE>;#1
を使用して、コマンド ラインから既存の実行可能ファイルにマニフェストを追加します。
-A と -W API の比較
多くの場合、Win32 API は - A と - W の両方のバリアントをサポートしています。
-A バリアントの場合、システムに構成されている ANSI コード ページを認識することができ、char*
をサポートします。一方、-W バリアントの場合、UTF-16 で動作し、WCHAR
をサポートします。
最近まで、Windows では、-A API よりも「Unicode」の -W バリアントを重視してきました。 ただし、最近のリリースでは、アプリに UTF-8 サポートを導入する手段として、ANSI コード ページと -A API が使われています。 ANSI コード ページが UTF-8 用に構成されている場合、-A API は通常 UTF-8 で動作します。 このモデルには、-A API を使って構築した既存のコードを、コードを変更することなくサポートできるという利点があります。
コード ページ変換
Windows は UTF-16 (WCHAR
) でネイティブに動作するので、場合によっては、Windows API と相互運用するために UTF-8 データを UTF-16 (またはその逆) に変換する必要があります。
MultiByteToWideChar と WideCharToMultiByte を使うと、UTF-8 と UTF-16 (WCHAR
) (およびその他のコード ページ) の間で変換できます。 これは、レガシ Win32 API が WCHAR
しか理解しない場合に特に便利です。 これらの関数を使うと、UTF-8 の入力を WCHAR
に変換して -W API に渡し、必要に応じて結果を変換して戻すことができます。
dwFlags
を 0
に設定してこれらの機能を使用する場合は、MB_ERR_INVALID_CHARS
または CodePage
のいずれかの CP_UTF8
を使用します (そうでない場合は ERROR_INVALID_FLAGS
が発生します)。
注
CP_ACP
は、Windows バージョン 1903 (2019 年 5 月の更新プログラム) 以降で実行されていて、上記の activeCodePage プロパティが UTF-8 に設定されている場合にのみ、 CP_UTF8
に相当します。 それ以外の場合は、レガシ システムのコード ページが使用されます。
CP_UTF8
を明示的に使うことをお勧めします。
関連トピック
Windows developer