Verwenden von UTF-8-Codepages in Windows-Apps

Verwenden Sie UTF-8-Zeichencodierung für eine optimale Kompatibilität zwischen Web-Apps und anderen *nix-basierten Plattformen (Unix, Linux und Varianten), minimieren Sie Lokalisierungsfehler und verringern Sie den Testaufwand.

UTF-8 ist die universelle Codeseite für die Internationalisierung und kann den gesamten Unicode-Zeichensatz codieren. Sie wird im Web pervasiv verwendet und ist die Standardeinstellung für *nix-basierte Plattformen.

Festlegen einer Prozesscodeseite auf UTF-8

Ab Windows Version 1903 (Mai 2019 Update) können Sie die ActiveCodePage-Eigenschaft im Appxmanifest für verpackte Apps oder das Fusionsmanifest für unpackte Apps verwenden, um einen Prozess zur Verwendung von UTF-8 als Prozesscodeseite zu erzwingen.

Sie können diese Eigenschaft und diese Ziel-/Ausführung auf früheren Windows Builds deklarieren, aber Sie müssen die Erkennung und Konvertierung von Legacycodeseiten wie gewohnt behandeln. Mit einer Mindestzielversion von Windows Version 1903 wird die Prozesscodeseite immer UTF-8 sein, sodass ältere Codeseitenerkennung und -konvertierung vermieden werden können.

Hinweis

Ein codiertes Zeichen dauert zwischen 1 und 4 Bytes. UTF-8-Codierung unterstützt längere Bytesequenzen, bis zu 6 Bytes, aber der größte Codepunkt von Unicode 6.0 (U+10FFFF) benötigt nur 4 Bytes.

Beispiele

Appx-Manifest für eine verpackte App:

<?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>

Fusion-Manifest für eine entpackte Win32-App:

<?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>

Hinweis

Hinzufügen eines Manifests zu einer vorhandenen ausführbaren Datei aus der Befehlszeile mit mt.exe -manifest <MANIFEST> -outputresource:<EXE>;#1

-A vs. -W-APIs

Win32-APIs unterstützen häufig sowohl -A- als auch -W-Varianten.

-Eine Variante erkennt die AUFSI-Codeseite, die auf dem System konfiguriert ist und unterstützt char*, während -W-Varianten in UTF-16 und Support WCHARfunktionieren.

Bis vor kurzem hat Windows "Unicode" -W-Varianten über -A-APIs hervorgehoben. Die letzten Versionen haben jedoch die ANSI-Codeseite und -A-APIs als Mittel verwendet, um UTF-8-Unterstützung für Apps einzuführen. Wenn die ANSI-Codeseite für UTF-8 konfiguriert ist, funktionieren -A-APIs normalerweise in UTF-8. Dieses Modell bietet den Vorteil, vorhandenen Code zu unterstützen, der mit -A-APIs erstellt wurde, ohne dass Codeänderungen vorgenommen werden.

Codeseitenkonvertierung

Da Windows nativ in UTF-16 (WCHAR) funktioniert, müssen Sie möglicherweise UTF-8-Daten in UTF-16 (oder umgekehrt) konvertieren, um mit Windows-APIs zu interoperieren.

MultiByteToWideChar und WideCharToMultiByte ermöglichen es Ihnen, zwischen UTF-8 und UTF-16 () (WCHARund anderen Codeseiten) zu konvertieren. Dies ist besonders hilfreich, wenn eine Ältere Win32-API möglicherweise nur verstehen WCHARkann. Mit diesen Funktionen können Sie UTF-8-Eingabe konvertieren, um WCHAR sie an eine W-API zu übergeben und dann bei Bedarf alle Ergebnisse wieder zu konvertieren. Wenn Sie diese Funktionen mit festgelegter Einstellung verwenden dwFlags0, verwenden Sie entweder oder MB_ERR_INVALID_CHARS, andernfalls tritt einERROR_INVALID_FLAGS.CodePageCP_UTF8

Hinweis

CP_ACPentspricht nur, wenn sie auf Windows Version 1903 (Update vom Mai 2019) oder höher ausgeführt wird und die oben beschriebene CP_UTF8 ActiveCodePage-Eigenschaft auf UTF-8 festgelegt ist. Andernfalls wird die Legacy-Systemcodeseite berücksichtigt. Es wird empfohlen, explizit zu verwenden CP_UTF8 .