1

I'm using Windows 11 with "New Windows Terminal" (default and "main" application in Windows 11 for working with console, not old cmd.exe nor newer PowerShell.exe). It has UTF-8 support out of the box and could show non-latin characters, emodji and so on, if they are coming in UTF-8 codepage.

In that terminal I run default Ubuntu wsl profile. From that wsl Ubuntu command line I ssh to remote non-Windows servers.

If server uses UTF-8 codepage, all looks fine. But if server uses "classic" non-UTF codepage, I can't see non-latin characters in terminal. Left part of attached image shows the problem.

windows terminal on the left, putty on the right

For example I have an old FreeBSD server, which does not support UTF-8 in console out of the box (and there is no reason to implement it - this server is kind of heritage which works for decades).

If I use putty to ssh this server - I just set up right codepage in Window -> Translation -> Character set -> Remote character set menu (usually KOI8-R or Win1251 (Cyrillic) is right choice for servers set up to use Cyrillic).

How to set up the same behavior in "New Windows Terminal"? It has dozens of settings, but I can't find anything about codepage.

Or maybe I should use some special ssh (not terminal) settings on Windows-side to convert remote server output on the fly?

AntonioK
  • 472

1 Answers1

1

Use luit (or possibly screen) as an intermediate layer for codepage conversion.

For reference, the "old Windows Terminal" was generally called "Windows console" and later known as "Conhost". It is not part of Cmd/PowerShell.

For example I have an old FreeBSD server, which does not support UTF-8 in console out of the box

It doesn't need to – SSH does not involve the remote system's console in any way (the output doesn't go through syscons); all it needs is for the programs to output UTF-8 encoded data. A FreeBSD installation from 2008, for example, would already be UTF-8 capable in that sense.

How to set up the same behavior in "New Windows Terminal"? It has dozens of settings, but I can't find anything about codepage.

Windows Terminal doesn't seem to have such a setting, it relies on the underlying console system to perform translation (it still shares the core of this code with Conhost). Open a regular PowerShell or Cmd tab, then test what happens if you run chcp 878 before entering WSL from the same tab.

Codepages in Windows console are in general a bit weird, as the underlying system is based on UTF-16 but has two APIs, one to write "OEM codepage" text and another to write UTF-16 text. Traditionally, the "OEM codepage" was set to something like 437 or 775 (roughly the MS-DOS equivalent of whichever 'ANSI' codepage the system was set to), although Windows Terminal nowadays sets it to 65001 indicating that it wants UTF-8. In theory, if you do chcp 878, this would make the console work with KOI8-R.

So because Conhost worked either with UTF-16 or OEM codepages for so long, there is actually another translation layer within Win32-OpenSSH – the version of ssh.exe that comes with Windows always sets the console codepage to 65001 while it runs, and assumes that the output from the SSH server will be UTF-8. This does not affect the Linux ssh command that you have in WSL... but I have a strong suspicion that the wsl.exe command that you use to enter the whole Ubuntu environment might do the same – it might be always forcing the console to UTF-8, or even translating to UTF-16.

grawity
  • 501,077