次の方法で共有


Windows アプリで UTF-8 コード ページを使用する

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 (またはその逆) に変換する必要があります。

MultiByteToWideCharWideCharToMultiByte を使うと、UTF-8 と UTF-16 (WCHAR) (およびその他のコード ページ) の間で変換できます。 これは、レガシ Win32 API が WCHAR しか理解しない場合に特に便利です。 これらの関数を使うと、UTF-8 の入力を WCHAR に変換して -W API に渡し、必要に応じて結果を変換して戻すことができます。

dwFlags0 に設定してこれらの機能を使用する場合は、MB_ERR_INVALID_CHARS または CodePage のいずれかの CP_UTF8 を使用します (そうでない場合は ERROR_INVALID_FLAGS が発生します)。

CP_ACP は、Windows バージョン 1903 (2019 年 5 月の更新プログラム) 以降で実行されていて、上記の activeCodePage プロパティが UTF-8 に設定されている場合にのみ、 CP_UTF8 に相当します。 それ以外の場合は、レガシ システムのコード ページが使用されます。 CP_UTF8 を明示的に使うことをお勧めします。