Script pour détecter si les paramètres régionaux du système Windows utilisent la page de codes UTF-8?
Sur les versions récentes de Win10, il est possible de définir la page de codes actifs (ACP) sur une page de codes UTF-8. Et comme indiqué ici , il est possible de définir les paramètres régionaux du système (utilisés pour mapper entre la version «A» et la version «W» de l'API Windows) pour utiliser la page de codes UTF-8.
Comment un script détecte-t-il si la page de codes UTF-8 est en cours d'utilisation?
Comme indiqué ici et ici , il est normalement possible d'utiliser WMI pour obtenir l'ID de la page de codes système:
For Each os In wmi.ExecQuery("SELECT * FROM Win32_OperatingSystem")
cs = os.CodeSet
Next
Lorsque j'essaie cela sur Win10, configuré pour utiliser le support utf-8 'beta' en anglais américain pour les programmes non-Unicode, WMI continue de signaler que la page de codes est 1252. Même si ce n'est clairement pas le cas (la page de codes 1252 a un point de code à 128, mais aucun à 49800: UTF-8 a un point de code à 49800, aucun à 128).
Comment un script détecte-t-il que les paramètres régionaux réels du système utilisent la page de codes UTF-8?
Réponses
Solutions PowerShell (basées sur le shell):
Pour déterminer la page de codes OEM des paramètres régionaux du système (à l'échelle du système) , qui est celle utilisée par les applications de console , utilisez le registre:
# $true, if the OEM code page is set to UTF-8 (code page 65001)
'65001' -eq (Get-ItemPropertyValue HKLM:\SYSTEM\CurrentControlSet\Control\Nls\CodePage OEMCP)
Noter:
L'utilisation de la prise en charge UTF-8 à l'échelle du système définit également la page de codes ANSI (
ACP
) sur65001
, utilisée par les applications GUI héritées, mais notamment Windows PowerShell [1] , signifie que l'encodage par défaut de Windows PowerShell pour l' applet de commandeGet-Content
etSet-Content
, par exemple, change.À partir de
cmd.exe
, vous pouvez exécuter
reg.exe query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage /v OEMCP
, mais vous devrez ensuite analyser sa sortie textuelle pour extraire uniquement le numéro de page de code.Notez que, malheureusement, l' Get-WinSystemLocaleapplet de commande de PowerShell ne peut pas être utilisée à ce jour, car l'
[cultureinfo]
instance qu'elle renvoie ne reflète pas un remplacement UTF-8 qui peut être en place - voir cette réponse ServerFault .
Pour déterminer la page de codes OEM active de la console actuelle - qui peut refléter ou non les paramètres régionaux du système, car les fenêtres de la console peuvent être configurées pour utiliser des pages de codes personnalisées et la page de codes peut même avoir été modifiée au préalable en session:
# $true, if the OEM code page is set to UTF-8 (code page 65001)
65001 -eq [Console]::OutputEncoding.CodePage
Noter:
- De
cmd.exe
vous pouvez exécuterchcp
chcp.com
, mais vous devrez ensuite analyser sa sortie textuelle pour extraire uniquement le numéro de la page de code
Solution basée sur l'API Windows :
À partir d'une application compilée, vous pouvez utiliser les fonctions API Windows GetACP () et GetOEMCP () pour interroger respectivement la page de codes ANSI et OEM active.
Vous pouvez même le faire à partir de PowerShell (bien que le fait qu'elle nécessite une compilation à la demande rende la solution de registre en haut préférable):
# Compile a helper type that calls the WinAPI functions.
Add-Type -Namespace Util -Name WinApi -MemberDefinition @'
[DllImport("Kernel32.dll")]
public static extern uint GetACP();
[DllImport("Kernel32.dll")]
public static extern uint GetOEMCP();
'@
[Util.WinAPI]::GetOEMCP(), [Util.WinAPI]::GetACP()
Noter:
- Si votre application compilée est une application console et que vous souhaitez connaître la page de codes OEM actuelle de la console associée - qui peut ou non être le jeu de pages par défaut via les paramètres régionaux du système - utilisez la GetConsoleOutputCP()fonction à la place.
[1] La page de codes ANSI active n'est plus pertinente pour PowerShell [Core] v6 + , qui utilise systématiquement UTF-8 sans nomenclature pour ses applets de commande, mais sous Windows, la page de codes OEM active, comme indiqué dans [Console]::OutputEncoding
, est toujours importante lors de la communication avec programmes externes .