Använda UTF-8-kodsidor i Windows-appar

Använd Unicode Transformation Format 8-bitars teckenkodning (UTF-8) för att maximera kompatibiliteten mellan webbappar och andra *nix-baserade plattformar (Unix, Linux och varianter), minimera lokaliseringsbuggar och minska testningskostnaderna.

UTF-8 är den universella kodsidan för internationalisering och kan koda hela Unicode-teckenuppsättningen. Den används mycket på webben och är standardkodning för både XML- och *nix-baserade plattformar.

Ange en processkodssida som UTF-8

Från och med Windows Version 1903 (maj 2019 Update) kan du ange egenskapen activeCodePage i appxmanifest för paketerade appar (eller fusionsmanifestet för uppackade appar) för att tvinga en process att använda UTF-8 som processkodsida.

Anmärkning

Windows-grafikenhetsgränssnittet (GDI) stöder för närvarande inte att ange egenskapen activeCodePage per process. I stället använder GDI den aktiva systemkodsidan som standard. Om du vill konfigurera din app för att återge UTF-8-text via GDI går du till Windows-inställningar>Tid och språk>Språk och region>Administrativa språkinställningar>Ändra systemspråk och kontrollerar Beta: Använd Unicode UTF-8 för stöd för globalt språk. Starta sedan om datorn för att ändringen ska börja gälla.

Du kan deklarera egenskapen activeCodePage och rikta och köra på tidigare Windows-versioner, men du måste hantera identifiering och konvertering av äldre kodsidor som vanligt. Med en lägsta målversion av Windows Version 1903 är processkodsidan alltid UTF-8, så äldre identifiering och konvertering av kodsidor kan undvikas.

Anmärkning

I UTF-8 representeras ett kodat tecken av en sekvens på 1 till 4 byte. (Se definitionen D92 i kapitel 3 iUnicode Standard för den formella specifikationen.)

Exempel

Appx-manifest för en paketerad 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 en uppackad 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>

Anmärkning

Lägg till ett manifest i en befintlig körbar fil från kommandoraden med mt.exe -manifest <MANIFEST> -outputresource:<EXE>;#1.

-A jämfört med -W API:er

Win32-API:er stöder ofta både -A och -W varianter.

-En variant identifierar ANSI-kodsidan som konfigurerats i systemet och stöder char*, medan -W varianter fungerar i UTF-16 och stöder WCHAR.

Tills nyligen har Windows betonat "Unicode" -W varianter över -A API:er. De senaste versionerna har dock använt ANSI-kodsidan och -A API:er som ett sätt att introducera UTF-8-stöd för appar. Om ANSI-kodsidan har konfigurerats för UTF-8 fungerar -A API:er vanligtvis i UTF-8. Den här modellen har fördelen att stödja befintlig kod som skapats med -A API:er utan några kodändringar.

Konvertering av kodsida

Eftersom Windows fungerar internt i UTF-16 (WCHAR) kan du behöva konvertera UTF-8-data till UTF-16 (eller vice versa) för att samverka med Windows-API:er.

MultiByteToWideChar och WideCharToMultiByte kan du konvertera mellan UTF-8 och UTF-16 (WCHAR) (och andra kodsidor). Detta är särskilt användbart när ett äldre Win32-API kanske bara förstår WCHAR. Med de här funktionerna kan du konvertera UTF-8-indata till WCHAR för att överföra till ett -W-API och sedan konvertera eventuella resultat tillbaka om det behövs.

Använd dwFlags av antingen 0 eller MB_ERR_INVALID_CHARS när du använder dessa funktioner med CodePage inställt på CP_UTF8 (annars inträffar en ERROR_INVALID_FLAGS).

Anmärkning

CP_ACP motsvarar CP_UTF8 endast om det körs på Windows Version 1903 (maj 2019-uppdateringen) eller senare, och egenskapen activeCodePage, som beskrivs ovan, är inställd på UTF-8. Annars respekteras den äldre systemkodsidan. Vi rekommenderar att du använder CP_UTF8 explicit.