Jak mogę ręcznie określić CodePage i ustawienia regionalne bieżącego systemu operacyjnego


13

Czy istnieje sposób, w jaki użytkownik może ręcznie sprawdzić bieżącą stronę kodową i ustawienia regionalne swojego systemu operacyjnego Windows? Czy istnieje ustawienie rejestru przechowujące te informacje?

Byłoby również przydatne, gdyby technika działała aż do Windows 2000.

Odpowiedzi:


16

chcp dostarczy ci aktywną stronę kodową.

systeminfo wyświetli między innymi ustawienia narodowe systemu i dane wejściowe.

Uwaga : To polecenie (systeminfo) nie jest dostępne w systemie Windows 2000, ale nadal można wysłać zapytanie do komputera z systemem Windows 2000, uruchamiając to polecenie na komputerze z systemem Windows XP lub Windows 2003 i ustawiając komputer zdalny na komputer z systemem Windows 2000. Jeśli bieżące logowanie użytkownika, które to wykonuje polecenie ma już uprawnienia na zdalnym komputerze (na przykład Administratorzy domeny), nie musisz używać / u i / p. ”
Od tutaj .


1
Pamiętaj, że chcpdostaniesz aktywną stronę kodową OEM . Jak mklement stwierdza w swojej odpowiedzi, Windows zawsze używa innej aktywnej strony kodowej, strony kodowej ANSI. Aby uzyskać więcej informacji, zobacz odpowiedź mklement .
kangalioo

6

Zauważ, że dany system ma dwie interesujące strony kodowe , określone przez starsze ustawienie o nazwie język dla programów nieobsługujących kodu Unicode , wcześniej znane jako ustawienia regionalne systemu (informacje dodatkowe w dolnej części):

  • OEM strona kodowa do użytku przez Legacy konsoli aplikacji
  • ANSI strona kodowa do użytku przez starszego typu GUI aplikacji.

Uwaga: istnieją jeszcze dwie strony kodowe, ale są one już rzadko używane i dlatego nie są tutaj omawiane: kod EBCDIC i strona kodowa Maca (wcześniejsza niż OS X) - patrz dokumentacja WinAPI .

Aktywna strona kodowa OEM jest najłatwiej uzyskać za pośrednictwem chcp, jak pokazano na pomocne odpowiedzi zapomniane średnik za - zakładając, że nie został wyraźnie zmieniło się w sesję chcp <codePageNum>.

Określenie aktywnej strony kodowej ANSI nie jest tak proste, ale PowerShell może pomóc, również w określeniu nazwy i języka ustawień regionalnych systemu:

W Windows 8+ / Windows Server 2012+ : Użyj polecenia Get-WinSystemLocalecmdlet:

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

Uwaga: Na przykład może być kuszące [cultureinfo]::CurrentCulture.TextInfo.ANSICodePage, ale nie musi to odzwierciedlać ogólnosystemowej aktywnej strony kodowej ANSI; zamiast tego jest to strona kodowa ANSI powiązana z ustawieniami narodowymi bieżącego użytkownika (kultura), które mogą być inne.

W systemie amerykańsko-angielskim powyższe wyniki:

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

OEMCPto strona kodowa OEM, strona ACPkodowa ANSI.

Metoda rejestru opartego że działa również na starszych systemach dół do systemu Windows XP :

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

W systemie amerykańsko-angielskim powyższe wyniki:

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

Jeśli chcesz również uzyskać nazwę [przyjazną] lokalizacji systemu i LCID (pamiętaj, że identyfikatory LCID są przestarzałe):

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

W systemie amerykańsko-angielskim powyższe wyniki:

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

Informacje podstawowe :

Ustawienia regionalne systemu to starsza nazwa tego, co obecnie jest bardziej opisowo nazywane językiem dla programów nieobsługujących kodu Unicode (patrz terminologia NLS ) i, jak sugerują nazwy:

  • To ustawienie dotyczy tylko starszych programów (programów, które nie obsługują Unicode).

  • Ma zastosowanie w całym systemie , niezależnie od ustawień regionalnych danego użytkownika , a do jego zmiany wymagane są uprawnienia administracyjne.

Ważne jest, aby pamiętać, że jest to spuścizna ustawienie , ponieważ strony kodowe nie stosuje się do programów, które używają Unicode wewnętrznie i wywołać unikodowych wersji Windows API.

W szczególności określa aktywne strony kodowe , tj. Domyślnie stosowane kodowanie znaków :

  • strona kodowa ANSI używać podczas programów non-Unicode nazywają non-Unicode (ANSI) wersje Windows API, zwłaszcza wersja ANSI z TextOutfunkcji do tłumaczenia łańcuchów do iz Unicode, która przede wszystkim określa jak struny w ramach programu renderowanie w GUI .

  • strona kodowa OEM , aby domyślnie aktywne w oknach konsoli , co znajduje odzwierciedlenie chcp.

    • Aktywna strona kodowa okna konsoli określa sposób interpretacji i wyświetlania danych wejściowych i wyjściowych z aplikacji konsolowych .
      • Zauważ, że oznacza to, że nawet dane wyjściowe z aplikacji konsolowych Unicode są tłumaczone na aktywną stronę kodową, co może spowodować utratę informacji; użycie pseudo strony kodowej 65001, która reprezentuje kodowanie UTF-8 w Unicode, jest rozwiązaniem, ale może powodować, że starsze programy wiersza poleceń błędnie interpretują dane, a nawet zawodzą - patrz odpowiedź StackOverflow w celu uzyskania szczegółowych informacji.
    • W odróżnieniu od strony kodowej ANSI, ty może zmienić aktywny [OEM] stronę kodową na żądanie dla danego okna konsoli ; na przykład, aby przejść do strony kodowej OEM 850, prowadzony chcp 850w cmd.exeoraz $OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = [text.encoding]::GetEncoding(850)w PowerShell.
  • dodatkowo rzadko używane strony kodowe EBCDIC i Mac .

Pomimo ustawienia regionalnego słowa używanego w starszym terminie i języka słowa w bieżącym terminie:

  • W zaledwie aspekty kontrolowane przez ustawienie to zestaw aktywnych stron kodowych i domyślne czcionki rastrowe , a nie również inne elementy (lokum, które są kontrolowane przez ustawienia regionalne na poziomie użytkownika).

  • Dana strona kodowa jest zwykle współdzielona przez wiele ustawień regionalnych i obejmuje wiele języków; np. powszechnie używana 1252strona kodowa jest używana przez wiele języków Europy Zachodniej, w tym angielski.

Jednak po zmianie ustawienia za pomocą Panelu sterowania wybierasz ustawienie za pomocą określonych ustawień regionalnych.

Aby uzyskać listę wszystkich stron kodowych systemu Windows, zobacz https://docs.microsoft.com/en-us/windows/desktop/Intl/code-page-identifiers


GetACP()funkcja - technet.microsoft.com/en-us/dd318070 - to ciekawe łącze, sekcja uwag wprost mówi, że wartość zwracana przez funkcję NIE reprezentuje domyślnego języka wejściowego użytkownika i języka GUI, ale coś zupełnie innego ...
Arioch

Rzeczywiście, @ Arioch'The - oto, co starałem się wyjaśnić w sekcji informacji w tle: ustawienia regionalne systemu (a) określają strony kodowe (ale żadnych innych ustawień narodowych) w całym systemie , (b) niezależnie od danego użytkownika widownia. Zwróć uwagę na to, jak połączona strona stwierdza (wyróżnienie dodane): „Zwraca bieżący identyfikator strony kodowej Windows ANSI (ACP) dla systemu operacyjnego ”. Jeśli chodzi o potencjalną wymianę trzeciej strony AppLocale: dodałem link do odpowiedzi.
Piątek

1
Ta uwaga / link GetACP jest moim zdaniem ważnym potwierdzeniem „słowa Bożego”, że domyślna konwersja MBCS na Unicode ma być niezależna od użytkownika i globalna dla systemu operacyjnego, a nie tylko szczegółowa implementacja w niektórych wersjach systemu Windows.
Arioch „The

1
Prawdopodobnie dziś zarówno pre-UNIX MAC, jak i EBCDIC w równym stopniu należą do niszy „tylko o znaczeniu historycznym”. Jestem jednak nieco przywiązany do tego MAC CP, ponieważ udało im się stworzyć kolejny wariant oznaczania nowych linii w plikach zwykłego tekstu, inny niż drzewa UNIX i DOS-Win-OS / 2. To była egzotyczna walizka narożna, którą zapamiętałem.
Arioch „The

1
Dzięki. Więcej linku do tematu - docs.microsoft.com/en-us/windows/desktop/Intl/... - a EBCDIC jest oznaczony jako „Windows 2000” - więc przed w2k prawdopodobnie nie istniał i przez wszystkie lata od tamtej pory nikt się nie przejmował zaktualizować źródła konwersji nagłówków, których użyłem:
D


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.