Freigeben über

Verwenden von UTF-8-Codepages in Windows-Apps

  • Artikel

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

UTF-8 ist die universelle Codepage für die Internationalisierung und kann den gesamten Unicode-Zeichensatz codieren. Sie kommt im Web verbreitet zum Einsatz und ist Standard bei *nix-basierten Plattformen.

Festlegen einer Prozesscodepage auf UTF-8

Ab Windows Version 1903 (Update vom Mai 2019) können Sie über die Eigenschaft ActiveCodePage im Appx-Manifest für gepackte Apps oder im Fusionsmanifest für ungepackte Apps einen Prozess zur Verwendung von UTF-8 als Prozesscodepage erzwingen.

Hinweis

Von GDI wird das Festlegen der Eigenschaft ActiveCodePage pro Prozess derzeit nicht unterstützt. Stattdessen legt GDI standardmäßig die aktive Systemcodepage fest. Wenn Sie Ihre App so zu konfigurieren möchten, dass UTF-8-Text über GDI gerendert wird, gehen Sie zu Windows Einstellungen>Zeit und Sprache>Sprache und Region>Administrative Sprachoptionen>Gebietsschema ändern und markieren Sie Beta: Unicode UTF-8 für die Unterstützung weltweiter Sprachen verwenden. Starten Sie den PC dann neu, damit die Änderung wirksam wird.

Sie können die Eigenschaft ActiveCodePage und die Zielsetzung/Ausführung auf früheren Windows-Builds deklarieren, müssen aber die Erkennung und Konvertierung älterer Codepages wie gewohnt vornehmen. Bei einer Mindestzielversion von Windows Version 1903 ist die Prozesscodepage immer UTF-8, sodass die Erkennung und Konvertierung älterer Codepages entfallen kann.

Hinweis

Ein codiertes Zeichen nimmt 1 bis 4 Byte in Anspruch. Die UTF-8-Codierung unterstützt längere Bytesequenzen, bis zu 6 Byte, aber der größte Codepunkt von Unicode 6.0 (U+10FFFF) nimmt nur 4 Byte in Anspruch.

Beispiele

Appx-Manifest für eine gepackte 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>

Fusionsmanifest für eine ungepackte 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

Fügen Sie über die Befehlszeile mit mt.exe -manifest <MANIFEST> -outputresource:<EXE>;#1 ein Manifest zu einer vorhandenen ausführbaren Datei hinzu.

-A- bzw. -W-APIs

Win32-APIs unterstützen oft sowohl -A- als auch -W-Varianten.

-A-Varianten erkennen die auf dem System konfigurierte ANSI-Codepage und unterstützen char*, während -W-Varianten mit UTF-16 arbeiten und WCHAR unterstützen.

Bis vor kurzem hat Windows „Unicode“-W-Varianten den -A-APIs vorgezogen. Neuere Releases verwenden jedoch die ANSI-Codepage und -A-APIs als Mittel zur Einführung der UTF-8-Unterstützung für Apps. Wenn die ANSI-Codepage für UTF-8 konfiguriert ist, arbeiten -A-APIs in der Regel mit UTF-8. Dieses Modell hat den Vorteil, dass ohne Codeänderungen der in -A-APIs vorhandene Code unterstützt wird.

Codepage-Konvertierung

Da Windows nativ mit UTF-16 (WCHAR) arbeitet, müssen Sie für das Zusammenwirken mit Windows-APIs gegebenenfalls UTF-8-Daten in UTF-16 konvertieren (oder umgekehrt).

MultiByteToWideChar und WideCharToMultiByte ermöglichen das Konvertieren zwischen UTF-8 und UTF-16 (WCHAR) (und anderen Codepages). Das ist besonders hilfreich, wenn eine ältere Win32-API eventuell nur WCHAR versteht. Mit diesen Funktionen können Sie UTF-8-Eingaben in WCHAR konvertieren, um sie an eine -W-API zu übergeben, und dann die Ergebnisse bei Bedarf zurückkonvertieren.

Verwenden Sie dwFlags von 0 oder MB_ERR_INVALID_CHARS, wenn Sie diese Funktionen mit CodePage auf CP_UTF8 gesetzt verwenden (andernfalls tritt ein ERROR_INVALID_FLAGS auf).

Hinweis

CP_ACP entspricht CP_UTF8 nur bei Ausführung unter Windows Version 1903 (Update vom Mai 2019) oder höher und Festlegung der oben beschriebenen Eigenschaft ActiveCodePage auf UTF-8. Andernfalls wird die Codepage des Legacysystems berücksichtigt. Wir empfehlen die explizite Verwendung von CP_UTF8.