Niezbyt często używam pl-znaków w konsoli łącząc się po SSH, ale jest parę miejsc, gdzie ich potrzebuję. Po dłuższym czasie zauważyłem, że na nowym komputerze mam problem z pl-znakami. Występował tylko przy połączeniu się z tego macOS przy pomocy SSH do Linuksa. Nic krytycznego, bo w zasadzie nie potrzebuję się tam łączyć z macOS, z innych Linuksów działało, ale byłoby miło, gdyby działało wszędzie. W końcu znalazłem chwilę i postanowiłem się zająć sprawą.
Krótko o środowisku: na workstacji macOS Ventura 13.4 z zsh 5.9 oraz iTerm2 3.4.19. Dla pamięci opis sprawdzania ustawień krok po kroku.
ustawienia iTerm
Upewniamy się, że iTerm korzysta z kodowania UTF-8. W tym celu należy wybrać
settings -> profiles -> terminal
Upewniamy się, że character encoding jest ustawione na UTF-8.
zmienne środowiskowe
Sprawdzamy ustawienia zmiennych środowiskowych na macOS. W tym celu należy wpisaćecho $LANG
i sprawdzić wartość zmiennej LANG. Powinna być jakaś z UTF-8, na przykład pl_PL.UTF-8.
Jeśli jest inaczej, można dopisać odpowiednią wartość w pliku .zshrc[1]export LANG=pl_PL.UTF-8
Jeśli wykonujemy zmianę, należy uruchomić nowy terminal, aby została zastosowana.
kodowanie w powłoce
Sprawdzamy na macOS, jakie kodowanie mamy ustawione w terminalu. Wpisujemy locale i weryfikujemy zawartość zmiennych LC_CTYPE oraz LANG. Powinny zawierać kodowanie UTF-8. Jeśli tak nie jest, można ustawić odpowiednie zmienne w sposób opisany w poprzedniem akapicie.
ustawienia systemu zdalnego
Należy sprawdzić, czy na serwerze zdalnym locale ustawione są na wersję z UTF-8. W tym celu wpisujemy locale. Jeśli tak nie jest, to w Debianie i Ubuntu polecenie dpkg-reconfigure locales umożliwi zarówno wygenerowanie odpowiednich locali, jak i ustawienie domyślnych.
Przy powyższych ustawieniach pl-znaki powinny wyświetlać się poprawnie.
Dla zupełnej transparentności: tym razem nie ma odnośników do stron, których używałem przy rozwiązywaniu problemu. Posiłkowałem się bowiem chatGPT z niewyszukanym promptem macos problem utf-8 iterm how to solve. Całkiem sprawnie sobie poradził.
[1] Jeżeli z jakiegoś powodu korzytamy z bash, nie zsh, to właściwym plikiem będzie .bash_profile
Rozumiem, że problemy z polskimi znakami od czasu do czasu jeszcze się pojawiają – vide temat powyżśzej notki – ale pamiętam doskonale zajadłe boje z ogonkami w latach dziewięćdziesiątych i pamiętam też, że jeszcze w okolicy 2004 r. dystrybucje Linuksa nie ogarniały do końca polskich znaków. Dzisiaj wszystko śmiga out-of-the-box. Becker, Collins i Davis, twórcy Unicode’a, to zaiste nieznani dobroczyńcy ludzkości.
Tak, z naszej bańki wygląda, że UTF-8 to rozwiązanie problemów z kodowaniem. Jednak tak nie jest, jak się szerzej popatrzy. Linka nie podam, przynajmniej nie od ręki.
Ale tak, u nas jest lepiej. Wtedy obiektywnie było trudniej, bo jeszcze jakieś echa 7bit us-ascii były, a standard Microsoftu walczył z ISO. Teraz już praktycznie wszyscy korzystają z UTF-8. I tylko czasem przypominam sobie na IRCu, że iso-8859-2 nadal jest używane. Inna sprawa, że część firm dalej nie pozwala na polskie znaki w polu imię czy nazwisko. Albo jawnie, albo kalecząc po fakcie.