Wie kann ich die CodePage und das Gebietsschema des aktuellen Betriebssystems manuell ermitteln?

Gibt es eine Möglichkeit, dass ein Benutzer die aktuelle Codepage und das Gebietsschema seines Windows-Betriebssystems manuell nachschlägt? Gibt es eine Registrierungseinstellung, in der diese Informationen gespeichert werden?

Es wäre auch nützlich, wenn die Technik bis Windows 2000 zurückreicht.

Mit chcp erhalten Sie die aktive Codepage.

systeminfo zeigt unter anderem das Systemgebietsschema und das Eingabegebietsschema an.

" Hinweis : Dieser Befehl (systeminfo) ist in Windows 2000 nicht verfügbar. Sie können jedoch Windows 2000-Computer abfragen, indem Sie diesen Befehl auf Windows XP- oder Windows 2003-Computern ausführen und den Remotecomputer auf Windows 2000-Computer einstellen. Wenn sich der aktuelle Benutzer anmeldet, der dies ausführt Der Befehl hat bereits Berechtigungen auf dem Remotecomputer (z. B. Domänenadministratoren). Sie müssen / u und / p nicht verwenden. "
Von hier aus .

Beachten Sie, dass ein bestimmtes System über zwei aktive Codepages von Interesse verfügt , die durch die Legacy-Einstellung namens language für Nicht-Unicode-Programme bestimmt werden , die früher als Systemgebietsschema bezeichnet wurde (Hintergrundinformationen finden Sie im unteren Abschnitt):

• die OEM -Codepage zur Verwendung durch ältere Konsolenanwendungen ,
• Die ANSI -Codepage zur Verwendung durch ältere GUI- Anwendungen.

^{Hinweis: Es gibt zwei weitere Codepages, die jedoch nur noch selten verwendet werden und daher hier nicht behandelt werden: den EBCDIC- Code und die Mac- Codepage (vor OS X) - siehe WinAPI-Dokumente .}

Die aktive OEM-Codepage kann am einfachsten über abgerufen werden chcp, wie in der hilfreichen Antwort von Forgotten Semicolon gezeigt - vorausgesetzt, sie wurde in der Sitzung mit nicht explizit geändert chcp <codePageNum>.

Das Ermitteln der aktiven ANSI-Codepage ist nicht so einfach, aber PowerShell kann auch beim Ermitteln des Namens und der Sprache des Systemgebietsschemas helfen :

In Windows 8+ / Windows Server 2012+ : Verwenden Sie das Get-WinSystemLocaleCmdlet:

Get-WinSystemLocale | Select-Object Name, DisplayName, 
                        @{ n='OEMCP'; e={ $_.TextInfo.OemCodePage } }, 
                        @{ n='ACP';   e={ $_.TextInfo.AnsiCodePage } }

^{Hinweis: Die Verwendung ist möglicherweise verlockend, spiegelt [cultureinfo]::CurrentCulture.TextInfo.ANSICodePagejedoch nicht unbedingt die systemweit aktive ANSI-Codepage wider . Stattdessen ist es die ANSI-Codepage, die dem Gebietsschema (der Kultur) des aktuellen Benutzers zugeordnet ist und möglicherweise unterschiedlich ist.}

Auf einem US-englischen System ergibt sich Folgendes:

Name  DisplayName             OEMCP  ACP
----  -----------             -----  ---
en-US English (United States)   437 1252

OEMCPist die OEM-Codepage, ACPdie ANSI-Codepage.

Eine registrierungsbasierte Methode , die auch auf älteren Systemen bis Windows XP funktioniert :

# Get the code pages:
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Nls\CodePage | 
     Select-Object OEMCP, ACP

Auf einem US-englischen System ergibt sich Folgendes:

OEMCP ACP 
----- --- 
437   1252

Wenn Sie auch den [freundlichen] Namen und die LCID des Systemgebietsschemas erhalten möchten (beachten Sie jedoch, dass LCIDs veraltet sind):

[Globalization.CultureInfo]::GetCultureInfo([int] ('0x' + (
        Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Nls\Language' Default
      ).Default)
)

Auf einem US-englischen System ergibt sich Folgendes:

LCID             Name             DisplayName                                                                                                                                      
----             ----             -----------                                                                                                                                      
1033             en-US            English (United States)                                                                                                                          

Hintergrundinformationen :

Das Systemgebietsschema ist der Legacy-Name für die Sprache, die jetzt beschreibender als Nicht-Unicode-Programme bezeichnet wird (siehe NLS-Terminologie ). Wie die Namen andeuten, gilt Folgendes:

• Die Einstellung gilt nur für ältere Programme (Programme, die Unicode nicht unterstützen).

• Es gilt systemweit , unabhängig von den Ländereinstellungen eines bestimmten Benutzers , und es sind Administratorrechte erforderlich, um es zu ändern.

Es ist wichtig zu beachten, dass dies eine Legacy- Einstellung ist , da Codepages nicht mehr für Programme gelten, die Unicode intern verwenden und die Unicode-Versionen der Windows-API aufrufen.

Insbesondere werden die aktiven Codepages bestimmt , dh die standardmäßig verwendete Zeichenkodierung :

• Die ANSI-Codepage , die verwendet werden soll, wenn Nicht-Unicode-Programme die Nicht-Unicode-Versionen (ANSI) der Windows-API aufrufen, insbesondere die ANSI-Version der TextOutFunktion zum Übersetzen von Zeichenfolgen in und aus Unicode, die insbesondere bestimmt, wie die Zeichenfolgen des Programms in der GUI .

  • Unter Verwendung von Standardfunktionen, Sie können nicht diesen Code Seite ändern auf Nachfrage , so dass Sie nicht selektiv Nicht-Unicode - Programme mit einer anderen ANSI - Codepage ausgeführt werden können.
  • Arioch 'Der Hinweis auf das ältere Microsoft-Programm AppLocale, dass bis Windows 7 verwendet werden kann, um bei Bedarf ein einzelnes Programm mit einem auswählbaren Systemgebietsschema auszuführen . Es scheint jedoch nicht mehr zum Herunterladen verfügbar zu sein und scheint unter Windows 10 nicht mehr zu funktionieren .
  • Locale Emulator , eine Open-Source-Lösung von Drittanbietern, setzt anscheinend dort an, wo AppLocale aufgehört hat (ich habe es nicht ausprobiert) und wird für 32-Bit-Anwendungen unter Windows 10 unterstützt.

• Die OEM-Codepage , die standardmäßig in Konsolenfenstern aktiviert werden soll chcp.

  • Die aktive Codepage eines Konsolenfensters bestimmt, wie die Tastatureingabe und -ausgabe von Konsolenanwendungen interpretiert und angezeigt wird .
    • Beachten Sie, dass dies bedeutet, dass sogar die Ausgabe von Unicode- Konsolenanwendungen in die aktive Codepage übersetzt wird, was zu Informationsverlust führen kann. Die Verwendung einer Pseudocodeseite 65001, die die UTF-8-Codierung von Unicode darstellt, ist eine Lösung. Dies kann jedoch dazu führen, dass ältere Befehlszeilenprogramme Daten falsch interpretieren und sogar fehlschlagen. Weitere Informationen finden Sie in dieser StackOverflow-Antwort .
  • Im Gegensatz zu der ANSI - Codepage, Sie können die aktive [OEM] Codepage für ein bestimmtes Konsolenfenster auf Anfrage ändern ; Um beispielsweise zur OEM-Codepage zu wechseln 850, führen Sie sie chcp 850in cmd.exeund $OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = [text.encoding]::GetEncoding(850)in PowerShell aus.
• Außerdem werden die selten mehr verwendeten EBCDIC- und Mac- Codepages verwendet.

Trotz des Wortes locale in dem älteren Begriff verwendet , und die Wortsprache in der laufenden Funktionsperiode:

• Die einzigen Aspekte, die von der Einstellung gesteuert werden, sind die aktiven Codepages und die Standard- Bitmap-Schriftarten , nicht auch andere Elemente eines Gebietsschemas (die von den Gebietsschemaeinstellungen auf Benutzerebene gesteuert werden).

• Eine bestimmte Codepage wird normalerweise von vielen Gebietsschemas gemeinsam genutzt und umfasst mehrere Sprachen. Beispielsweise wird die weit verbreitete 1252Codepage von vielen westeuropäischen Sprachen verwendet, einschließlich Englisch.

Wenn Sie die Einstellung jedoch über die Systemsteuerung ändern, wählen Sie die Einstellung über ein bestimmtes Gebietsschema aus.

Eine Liste aller Windows-Codepages finden Sie unter https://docs.microsoft.com/en-us/windows/desktop/Intl/code-page-identifiers

Das Gebietsschema ist auch in msinfo32 zu sehen.

Die Windows-API, die die aktive Codepage zurückgibt, ist GetConsoleOutputCP () .