Jakiej strony kodującej / kodowej używa cmd.exe?

Kiedy otwieram cmd.exe w systemie Windows, jakiego kodowania używa?

Jak mogę sprawdzić, jakiego kodowania obecnie używa? Czy to zależy od moich ustawień regionalnych, czy są jakieś zmienne środowiskowe do sprawdzenia?

Co się stanie, gdy wpiszesz plik z określonym kodowaniem? Czasami dostaję zniekształcone znaki (użyte nieprawidłowe kodowanie), a czasem to działa. Jednak nic nie ufam, dopóki nie wiem, co się dzieje. Czy ktoś może wyjaśnić?

Tak, to frustrujące - czasami typeinne programy drukują bełkot, a czasem nie.

Przede wszystkim znaki Unicode będą wyświetlane tylko wtedy, gdy bieżąca czcionka konsoli zawiera te znaki . Użyj więc czcionki TrueType, takiej jak Lucida Console, zamiast domyślnej czcionki rastrowej.

Ale jeśli czcionka konsoli nie zawiera znaku, który próbujesz wyświetlić, zamiast bełkotu zobaczysz znaki zapytania. Kiedy pojawia się bełkot, dzieje się coś więcej niż tylko ustawienia czcionek.

Gdy programy używają standardowych funkcji we / wy biblioteki C printf, takich jak , kodowanie wyjściowe programu musi być zgodne z kodowaniem wyjściowym konsoli , w przeciwnym razie otrzymasz bełkot. chcppokazuje i ustawia bieżącą stronę kodową. Wszystkie dane wyjściowe przy użyciu standardowych funkcji we / wy biblioteki C są traktowane tak, jakby znajdowały się na stronie kodowej wyświetlanej przez chcp.

Dopasowanie kodowania wyjściowego programu do kodowania wyjściowego konsoli można wykonać na dwa różne sposoby:

• Program może pobrać bieżącą stronę kodową konsoli za pomocą chcplub GetConsoleOutputCPi skonfigurować się tak, aby wyświetlać w tym kodowaniu, lub

• Ty lub program możesz ustawić bieżącą stronę kodową konsoli za pomocą chcplub, SetConsoleOutputCPaby dopasować domyślne kodowanie wyjściowe programu.

Jednak programy używające interfejsów API Win32 mogą zapisywać ciągi UTF-16LE bezpośrednio na konsoli za pomocą WriteConsoleW. Jest to jedyny sposób na uzyskanie prawidłowego wyniku bez ustawiania stron kodowych. I nawet podczas korzystania z tej funkcji, jeśli ciąg znaków nie znajduje się w kodowaniu UTF-16LE na początek, program Win32 musi przekazać poprawną stronę kodową MultiByteToWideChar. Również,WriteConsoleWNie zadziała jeśli wyjście programu zostanie przekierowane; w takim przypadku potrzebne jest więcej zabawy.

typedziała przez pewien czas, ponieważ sprawdza, czy na początku każdego pliku nie ma znaku kolejności bajtów UTF-16LE (BOM) , tj. bajtów 0xFF 0xFE. Jeśli znajdzie taki znak, wyświetla znaki Unicode w pliku przy użyciu WriteConsoleW niezależnie od bieżącej strony kodowej. Ale podczas typewczytywania dowolnego pliku bez BOM UTF-16LE lub używania znaków spoza ASCII z dowolną komendą, która się nie wywołuje WriteConsoleW, konieczne będzie ustawienie strony kodowej konsoli i kodowania wyjścia programu tak, aby były ze sobą zgodne.

Jak możemy się tego dowiedzieć?

Oto plik testowy zawierający znaki Unicode:

ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好

Oto program Java do wydrukowania pliku testowego w wielu różnych kodowaniach Unicode. Może być w dowolnym języku programowania; wypisuje tylko znaki ASCII lub zakodowane bajty stdout.

import java.io.*;

public class Foo {

    private static final String BOM = "\ufeff";
    private static final String TEST_STRING
        = "ASCII     abcde xyz\n"
        + "German    äöü ÄÖÜ ß\n"
        + "Polish    ąęźżńł\n"
        + "Russian   абвгдеж эюя\n"
        + "CJK       你好\n";

    public static void main(String[] args)
        throws Exception
    {
        String[] encodings = new String[] {
            "UTF-8", "UTF-16LE", "UTF-16BE", "UTF-32LE", "UTF-32BE" };

        for (String encoding: encodings) {
            System.out.println("== " + encoding);

            for (boolean writeBom: new Boolean[] {false, true}) {
                System.out.println(writeBom ? "= bom" : "= no bom");

                String output = (writeBom ? BOM : "") + TEST_STRING;
                byte[] bytes = output.getBytes(encoding);
                System.out.write(bytes);
                FileOutputStream out = new FileOutputStream("uc-test-"
                    + encoding + (writeBom ? "-bom.txt" : "-nobom.txt"));
                out.write(bytes);
                out.close();
            }
        }
    }
}

Dane wyjściowe w domyślnej stronie kodowej? Całkowite śmieci!

Z:\andrew\projects\sx\1259084>chcp
Active code page: 850

Z:\andrew\projects\sx\1259084>java Foo
== UTF-8
= no bom
ASCII     abcde xyz
German    ├ñ├Â├╝ ├ä├û├£ ├ƒ
Polish    ąęźżńł
Russian   ð░ð▒ð▓ð│ð┤ðÁð ÐìÐÄÐÅ
CJK       õ¢áÕÑ¢
= bom
´╗┐ASCII     abcde xyz
German    ├ñ├Â├╝ ├ä├û├£ ├ƒ
Polish    ąęźżńł
Russian   ð░ð▒ð▓ð│ð┤ðÁð ÐìÐÄÐÅ
CJK       õ¢áÕÑ¢
== UTF-16LE
= no bom
A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h         ♣☺↓☺z☺|☺D☺B☺
 R u s s i a n       0♦1♦2♦3♦4♦5♦6♦  M♦N♦O♦
 C J K               `O}Y
 = bom
 ■A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h         ♣☺↓☺z☺|☺D☺B☺
 R u s s i a n       0♦1♦2♦3♦4♦5♦6♦  M♦N♦O♦
 C J K               `O}Y
 == UTF-16BE
= no bom
 A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h        ☺♣☺↓☺z☺|☺D☺B
 R u s s i a n      ♦0♦1♦2♦3♦4♦5♦6  ♦M♦N♦O
 C J K              O`Y}
= bom
■  A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h        ☺♣☺↓☺z☺|☺D☺B
 R u s s i a n      ♦0♦1♦2♦3♦4♦5♦6  ♦M♦N♦O
 C J K              O`Y}
== UTF-32LE
= no bom
A   S   C   I   I                       a   b   c   d   e       x   y   z
   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                   ♣☺  ↓☺  z☺  |☺  D☺  B☺
   R   u   s   s   i   a   n               0♦  1♦  2♦  3♦  4♦  5♦  6♦      M♦  N
♦  O♦
   C   J   K                               `O  }Y
   = bom
 ■  A   S   C   I   I                       a   b   c   d   e       x   y   z

   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                   ♣☺  ↓☺  z☺  |☺  D☺  B☺
   R   u   s   s   i   a   n               0♦  1♦  2♦  3♦  4♦  5♦  6♦      M♦  N
♦  O♦
   C   J   K                               `O  }Y
   == UTF-32BE
= no bom
   A   S   C   I   I                       a   b   c   d   e       x   y   z
   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                  ☺♣  ☺↓  ☺z  ☺|  ☺D  ☺B
   R   u   s   s   i   a   n              ♦0  ♦1  ♦2  ♦3  ♦4  ♦5  ♦6      ♦M  ♦N
  ♦O
   C   J   K                              O`  Y}
= bom
  ■    A   S   C   I   I                       a   b   c   d   e       x   y   z

   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                  ☺♣  ☺↓  ☺z  ☺|  ☺D  ☺B
   R   u   s   s   i   a   n              ♦0  ♦1  ♦2  ♦3  ♦4  ♦5  ♦6      ♦M  ♦N
  ♦O
   C   J   K                              O`  Y}

A co jeśli typepliki, które zostały zapisane? Zawierają dokładnie te same bajty, które zostały wydrukowane na konsoli.

Z:\andrew\projects\sx\1259084>type *.txt

uc-test-UTF-16BE-bom.txt


■  A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h        ☺♣☺↓☺z☺|☺D☺B
 R u s s i a n      ♦0♦1♦2♦3♦4♦5♦6  ♦M♦N♦O
 C J K              O`Y}

uc-test-UTF-16BE-nobom.txt


 A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h        ☺♣☺↓☺z☺|☺D☺B
 R u s s i a n      ♦0♦1♦2♦3♦4♦5♦6  ♦M♦N♦O
 C J K              O`Y}

uc-test-UTF-16LE-bom.txt


ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好

uc-test-UTF-16LE-nobom.txt


A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h         ♣☺↓☺z☺|☺D☺B☺
 R u s s i a n       0♦1♦2♦3♦4♦5♦6♦  M♦N♦O♦
 C J K               `O}Y

uc-test-UTF-32BE-bom.txt


  ■    A   S   C   I   I                       a   b   c   d   e       x   y   z

   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                  ☺♣  ☺↓  ☺z  ☺|  ☺D  ☺B
   R   u   s   s   i   a   n              ♦0  ♦1  ♦2  ♦3  ♦4  ♦5  ♦6      ♦M  ♦N
  ♦O
   C   J   K                              O`  Y}

uc-test-UTF-32BE-nobom.txt


   A   S   C   I   I                       a   b   c   d   e       x   y   z
   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                  ☺♣  ☺↓  ☺z  ☺|  ☺D  ☺B
   R   u   s   s   i   a   n              ♦0  ♦1  ♦2  ♦3  ♦4  ♦5  ♦6      ♦M  ♦N
  ♦O
   C   J   K                              O`  Y}

uc-test-UTF-32LE-bom.txt


 A S C I I           a b c d e   x y z
 G e r m a n         ä ö ü   Ä Ö Ü   ß
 P o l i s h         ą ę ź ż ń ł
 R u s s i a n       а б в г д е ж   э ю я
 C J K               你 好

uc-test-UTF-32LE-nobom.txt


A   S   C   I   I                       a   b   c   d   e       x   y   z
   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                   ♣☺  ↓☺  z☺  |☺  D☺  B☺
   R   u   s   s   i   a   n               0♦  1♦  2♦  3♦  4♦  5♦  6♦      M♦  N
♦  O♦
   C   J   K                               `O  }Y

uc-test-UTF-8-bom.txt


´╗┐ASCII     abcde xyz
German    ├ñ├Â├╝ ├ä├û├£ ├ƒ
Polish    ąęźżńł
Russian   ð░ð▒ð▓ð│ð┤ðÁð ÐìÐÄÐÅ
CJK       õ¢áÕÑ¢

uc-test-UTF-8-nobom.txt


ASCII     abcde xyz
German    ├ñ├Â├╝ ├ä├û├£ ├ƒ
Polish    ąęźżńł
Russian   ð░ð▒ð▓ð│ð┤ðÁð ÐìÐÄÐÅ
CJK       õ¢áÕÑ¢

Tylko rzeczą, która działa jest plik UTF-16LE, z BOM, drukowane do konsoli poprzez type.

Jeśli użyjemy czegoś innego niż typewydruk pliku, otrzymujemy śmieci:

Z:\andrew\projects\sx\1259084>copy uc-test-UTF-16LE-bom.txt CON
 ■A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h         ♣☺↓☺z☺|☺D☺B☺
 R u s s i a n       0♦1♦2♦3♦4♦5♦6♦  M♦N♦O♦
 C J K               `O}Y
         1 file(s) copied.

Z faktu, że copy CONnie wyświetla poprawnie Unicode, możemy wywnioskować, że typepolecenie ma logikę wykrywania BOM UTF-16LE na początku pliku i użyj specjalnych interfejsów API Windows, aby go wydrukować.

Możemy to zobaczyć, otwierając cmd.exew debuggerze, gdy wychodzi type plik:

Po typeotwiera plik, to sprawdza BOM z 0xFEFF-ie, bajty 0xFF 0xFEw ostrokońcej a jeśli istnieje taka BOM, typeustawia wewnętrzną fOutputUnicodeflagą. Ta flaga jest później sprawdzana, aby zdecydować, czy zadzwonić WriteConsoleW.

Ale to jedyny sposób, aby uzyskać typewyjściowy Unicode i tylko dla plików, które mają BOM i są w UTF-16LE. W przypadku wszystkich innych plików i programów, które nie mają specjalnego kodu do obsługi danych wyjściowych konsoli, pliki zostaną zinterpretowane zgodnie z bieżącą stroną kodową i prawdopodobnie będą wyświetlane jako bełkot.

Możesz emulować sposób, w jaki typewypisuje Unicode na konsolę w swoich własnych programach:

#include <stdio.h>
#define UNICODE
#include <windows.h>

static LPCSTR lpcsTest =
    "ASCII     abcde xyz\n"
    "German    äöü ÄÖÜ ß\n"
    "Polish    ąęźżńł\n"
    "Russian   абвгдеж эюя\n"
    "CJK       你好\n";

int main() {
    int n;
    wchar_t buf[1024];

    HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);

    n = MultiByteToWideChar(CP_UTF8, 0,
            lpcsTest, strlen(lpcsTest),
            buf, sizeof(buf));

    WriteConsole(hConsole, buf, n, &n, NULL);

    return 0;
}

Ten program działa do drukowania Unicode na konsoli Windows przy użyciu domyślnej strony kodowej.

W przypadku przykładowego programu Java możemy uzyskać trochę poprawnego wyniku, ustawiając stronę kodową ręcznie, chociaż dane wyjściowe psują się w dziwny sposób:

Z:\andrew\projects\sx\1259084>chcp 65001
Active code page: 65001

Z:\andrew\projects\sx\1259084>java Foo
== UTF-8
= no bom
ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好
ж эюя
CJK       你好
 你好
好
�
= bom
ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好
еж эюя
CJK       你好
  你好
好
�
== UTF-16LE
= no bom
A S C I I           a b c d e   x y z
…

Jednak program C, który ustawia stronę kodową Unicode UTF-8:

#include <stdio.h>
#include <windows.h>

int main() {
    int c, n;
    UINT oldCodePage;
    char buf[1024];

    oldCodePage = GetConsoleOutputCP();
    if (!SetConsoleOutputCP(65001)) {
        printf("error\n");
    }

    freopen("uc-test-UTF-8-nobom.txt", "rb", stdin);
    n = fread(buf, sizeof(buf[0]), sizeof(buf), stdin);
    fwrite(buf, sizeof(buf[0]), n, stdout);

    SetConsoleOutputCP(oldCodePage);

    return 0;
}

ma poprawny wynik:

Z:\andrew\projects\sx\1259084>.\test
ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好

Morał tej historii?

• type może drukować pliki UTF-16LE z BOM niezależnie od bieżącej strony kodowej
• Programy Win32 można zaprogramować do wyświetlania Unicode na konsoli za pomocą WriteConsoleW.
• Inne programy, które ustawiają stronę kodową i odpowiednio dostosowują kodowanie wyjściowe, mogą drukować Unicode na konsoli bez względu na to, jaka była strona kodowa podczas uruchamiania programu
• W przypadku wszystkiego innego będziesz musiał się zepsuć chcpi prawdopodobnie nadal będziesz mieć dziwne wyniki.

Rodzaj

chcp

aby zobaczyć swoją aktualną stronę kodową (jak już powiedział Dewfy).

Posługiwać się

nlsinfo

aby zobaczyć wszystkie zainstalowane strony kodowe i dowiedzieć się, co oznacza numer strony kodowej.

Aby móc korzystać, musisz mieć zainstalowany zestaw zasobów systemu Windows Server 2003 (działa w systemie Windows XP) nlsinfo.

Aby odpowiedzieć na drugie zapytanie, ponownie. jak działa kodowanie, Joel Spolsky napisał na ten temat świetny artykuł wprowadzający . Zdecydowanie polecam.

Command CHCP pokazuje bieżącą stronę kodową. Ma trzy cyfry: 8xx i różni się od Windows 12xx. Więc wpisując tekst tylko w języku angielskim, nie zobaczysz żadnej różnicy, ale rozszerzona strona kodowa (jak cyrylica) zostanie wydrukowana nieprawidłowo.

Długo byłem sfrustrowany problemami ze stroną kodową Windows oraz powodowanymi przez nie problemami z przenośnością i lokalizacją programów C. Poprzednie posty szczegółowo opisywały problemy, więc nie zamierzam niczego dodawać w tym zakresie.

Krótko mówiąc, w końcu napisałem własną warstwę biblioteki kompatybilności UTF-8 nad standardową biblioteką C Visual C ++. Zasadniczo ta biblioteka zapewnia, że ​​standardowy program C działa poprawnie, na dowolnej stronie kodowej, przy użyciu UTF-8 wewnętrznie.

Ta biblioteka o nazwie MsvcLibX jest dostępna jako open source na https://github.com/JFLarvoire/SysToolsLib . Główne cechy:

• Źródła C zakodowane w UTF-8, przy użyciu normalnych ciągów znaków char [] C i standardowych interfejsów API biblioteki C.
• Na dowolnej stronie kodowej wszystko jest przetwarzane wewnętrznie jako UTF-8 w twoim kodzie, w tym główna () procedura argv [], ze standardowym wejściem i wyjściem automatycznie konwertowane na właściwą stronę kodową.
• Wszystkie funkcje plików stdio.h obsługują ścieżki UTF-8> 260 znaków, w rzeczywistości do 64 KB.
• Te same źródła mogą się pomyślnie kompilować i łączyć w systemie Windows przy użyciu bibliotek Visual C ++ i MsvcLibX oraz Visual C ++ C, a w systemie Linux przy użyciu gcc i standardowej biblioteki C w systemie Linux, bez potrzeby blokowania #ifdef ... #endif.
• Dodaje dołączone pliki typowe w Linuksie, ale brakujące w Visual C ++. Np .: unistd.h
• Dodaje brakujące funkcje, takie jak funkcje I / O katalogu, zarządzanie dowiązaniami symbolicznymi itp., Wszystkie oczywiście z obsługą UTF-8 :-).

Więcej informacji w pliku MsvcLibX README na GitHub , w tym jak zbudować bibliotekę i używać jej we własnych programach.

Sekcja wydania w powyższym repozytorium GitHub zawiera kilka programów korzystających z tej biblioteki MsvcLibX, które pokażą jej możliwości. Przykład: Wypróbuj moje narzędzie which.exe z katalogami o nazwach innych niż ASCII w ścieżce PATH, wyszukując programy o nazwach innych niż ASCII i zmieniając strony kodowe.

Kolejnym przydatnym narzędziem jest program conv.exe. Ten program może łatwo konwertować strumień danych z dowolnej strony kodowej na dowolną inną. Domyślnie jest on wprowadzany na stronie kodowej Windows i wyprowadzany na bieżącej stronie kodowej konsoli. Umożliwia to prawidłowe przeglądanie danych generowanych przez aplikacje Windows GUI (np. Notatnik) w konsoli poleceń za pomocą prostego polecenia, takiego jak:type WINFILE.txt | conv

Ta biblioteka MsvcLibX w żadnym wypadku nie jest kompletna, a wkład w jej ulepszanie jest mile widziany!

W Javie użyłem kodowania „IBM850” do napisania pliku. To rozwiązało problem.