Notez qu'un système donné a deux pages de codes actives d'intérêt , comme déterminé par le paramètre hérité nommé langue pour les programmes non Unicode , anciennement appelé paramètres régionaux du système (voir la section inférieure pour des informations générales):
- la page de codes OEM à utiliser par les applications de console héritées ,
- la page de codes ANSI à utiliser par les applications GUI héritées .
Remarque: Il y a deux autres pages de code, mais elles sont rarement utilisées et ne sont donc pas abordées ici: le code EBCDIC et la page de code Mac (pré-OS X) Mac - voir la documentation WinAPI .
La page de codes OEM active est plus facilement obtenue via chcp
, comme indiqué dans la réponse utile de Forgotten Semicolon - en supposant qu'elle n'a pas été explicitement modifiée dans la session avec chcp <codePageNum>
.
La détermination de la page de codes ANSI active n'est pas aussi simple, mais PowerShell peut vous aider, également à déterminer le nom et la langue des paramètres régionaux du système:
Sous Windows 8+ / Windows Server 2012+ : utilisez l' Get-WinSystemLocale
applet de commande:
Get-WinSystemLocale | Select-Object Name, DisplayName,
@{ n='OEMCP'; e={ $_.TextInfo.OemCodePage } },
@{ n='ACP'; e={ $_.TextInfo.AnsiCodePage } }
Remarque: Il peut être tentant d'utiliser [cultureinfo]::CurrentCulture.TextInfo.ANSICodePage
, par exemple, mais cela ne reflète pas nécessairement la page de codes ANSI active à l' échelle du système ; il s'agit plutôt de la page de codes ANSI associée aux paramètres régionaux (culture) de l' utilisateur actuel , qui peuvent être différents.
Sur un système US-anglais, les résultats ci-dessus donnent:
Name DisplayName OEMCP ACP
---- ----------- ----- ---
en-US English (United States) 437 1252
OEMCP
est la page de codes OEM, ACP
la page de codes ANSI.
Une méthode basée sur le registre qui fonctionne également sur les anciens systèmes jusqu'à Windows XP :
# Get the code pages:
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Nls\CodePage |
Select-Object OEMCP, ACP
Sur un système US-anglais, les résultats ci-dessus donnent:
OEMCP ACP
----- ---
437 1252
Si vous souhaitez également obtenir le nom et le LCID des paramètres régionaux du système (notez cependant que les LCID sont obsolètes):
[Globalization.CultureInfo]::GetCultureInfo([int] ('0x' + (
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Language' Default
).Default)
)
Sur un système US-anglais, les résultats ci-dessus donnent:
LCID Name DisplayName
---- ---- -----------
1033 en-US English (United States)
Informations générales :
Les paramètres régionaux du système sont le nom hérité de ce qui est maintenant appelé de manière plus descriptive la langue pour les programmes non Unicode (voir la terminologie NLS ) et, comme les noms le suggèrent:
Le paramètre s'applique uniquement aux programmes hérités (programmes qui ne prennent pas en charge Unicode).
Il s'applique à l'ensemble du système , quels que soient les paramètres régionaux d'un utilisateur donné , et des privilèges administratifs sont nécessaires pour le modifier.
Il est important de noter qu'il s'agit d' un paramètre hérité , car les pages de codes ne s'appliquent plus aux programmes qui utilisent Unicode en interne et appellent les versions Unicode de l'API Windows.
Il détermine notamment les pages de codes actives , c'est-à-dire l' encodage des caractères utilisé par défaut :
la page de codes ANSI à utiliser lorsque des programmes non Unicode appellent les versions non Unicode (ANSI) de l'API Windows, notamment la version ANSI de la TextOut
fonction de traduction des chaînes vers et depuis Unicode, qui détermine notamment la façon dont les chaînes du programme s'affichent dans le GUI .
la page de codes OEM à activer par défaut dans les fenêtres de la console , comme indiqué par chcp
.
- La page de codes active d'une fenêtre de console détermine la façon dont les entrées et sorties du clavier des applications de console sont interprétées et affichées .
- Notez que cela signifie que même la sortie des applications de la console Unicode est traduite dans la page de codes active, ce qui peut entraîner une perte d'informations; l'utilisation de la pseudo page de code
65001
, qui représente le codage UTF-8 d'Unicode, est une solution, mais qui peut entraîner des programmes de ligne de commande hérités à mal interpréter les données et même à échouer - voir cette réponse StackOverflow pour plus de détails.
- Contrairement à la page de codes ANSI, vous pouvez modifier la page de codes [OEM] active à la demande pour une fenêtre de console donnée ; par exemple, pour basculer vers la page de codes OEM
850
, exécuter chcp 850
dans cmd.exe
et $OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = [text.encoding]::GetEncoding(850)
dans PowerShell.
- en outre, les pages de codes EBCDIC et Mac rarement utilisées .
Malgré le mot locale utilisé dans le terme hérité et le mot langue dans le terme actuel:
Les seuls aspects contrôlés par le paramètre sont l' ensemble des pages de codes actives et les polices bitmap par défaut , pas également les autres éléments des paramètres régionaux (qui sont contrôlés par les paramètres régionaux au niveau de l'utilisateur).
Une page de code donnée est généralement partagée par de nombreux paramètres régionaux et couvre plusieurs langues; Par exemple, la page de codes largement utilisée1252
est utilisée par de nombreuses langues d'Europe occidentale, y compris l'anglais.
Cependant, lorsque vous modifiez le paramètre via le Panneau de configuration, vous choisissez le paramètre au moyen d' un paramètre régional spécifique.
Pour une liste de toutes les pages de codes Windows, voir https://docs.microsoft.com/en-us/windows/desktop/Intl/code-page-identifiers
chcp
vous obtiendrez la page de codes OEM active . Comme l'indique mklement dans sa réponse, il existe toujours une autre page de codes active utilisée par Windows, la page de codes ANSI. Pour plus d'informations, voir la réponse de mklement .