O que você está vendo
Existe um programa emulador de terminal embutido no kernel do Linux. Não se manifesta como um processo em execução com identificadores de arquivos abertos. É colocado sobre o framebuffer e o subsistema de eventos de entrada, que usa interfaces de kernel internas para acessar. Ele se apresenta para sistemas no modo aplicativo como uma série de dispositivos terminais virtuais do kernel, /dev/tty1
e assim por diante. É isso que você está empregando.
Este emulador de terminal, sendo um sistema em modo kernel, está sujeito a restrições de recursos bastante severas. Então, historicamente, ele nunca suportou grandes conjuntos de caracteres que precisam de muita memória (espaço de endereçamento do kernel). É por isso que está "mostrando" esses personagens.
A solução para isso é obviamente mover o emulador de terminal para fora do modo kernel. Isso tem sido debatido por anos. Eu escrevi um white paper sobre isso há quase uma década.
É claro, os muitos programas emulador de terminal do X Window System que você nunca ouviu falar de já fazer . Eles são programas comuns em modo aplicativo, que renderizam seus glifos em X windows exibidos por um servidor X, e eles podem manipular grandes conjuntos de caracteres. Então você não teria nenhum problema com o chinês nesses emuladores de terminal.
terminais virtuais de espaço do usuário
Existem também , no entanto, programas de emulador de terminal que não usam um servidor X para sua E / S, mas estão em camadas no topo das APIs (externas) para o framebuffer e o evento input subsistema. O uso dos subsistemas de evento framebuffer e input diretamente, assim como o programa emulador de terminal embutido no kernel, mas eles também são apenas programas comuns em modo de aplicação, fora do kernel e portanto não sujeitos a suas restrições. Com esses, você também pode exibir chinês. De fato, vários desses programas terminal virtual de espaço de usuário têm isso como um recurso elogiado.
Eles incluem:
- zhcon - um terminal virtual do espaço do usuário voltado para a manipulação de CJK I / O. Sua força especial está na manipulação de codificações ISO 2022 não-UTF; sua fraqueza particular é codificações UTF.
- fbterm - um terminal virtual do espaço de usuário que gerou vários garfos, incluindo jfbterm . Tem um monte de plug-ins do método de entrada CJK.
- bogl-bterm - um terminal virtual do espaço de usuário que gerou garfos como niterm .
- As ferramentas
console-terminal-emulator
econsole-fb-realizer
em nosh - um terminal virtual do espaço do usuário com o objetivo de replicar terminais virtuais Linux e FreeBSD / PC-BSD. Por design, não tem dependências em bibliotecas X. Também por design, ele faz apenas UTF; sem ISO 2022. É (no momento de escrever esta resposta) ainda muito fraca nos métodos de entrada de CJK. -
kmscon - um terminal virtual do espaço do usuário que está intimamente ligado ao
logind
no systemd e suas noções de "assentos".
Fontes
Você precisa de fontes chinesas. Isso é um pouco complexo.
Vários desses programas de terminal virtual do usuário fazem uso de bibliotecas X para manipulação de fontes, mapeamento de teclado, métodos de entrada CJK e assim por diante. Eles não são clientes X, mas possuem dependências de bibliotecas X. Então você usa fontes X com elas.
Os outros fazem outros arranjos.
-
bogl-bterm
tem seus próprios formatos de fonte idiossincráticos. Um converte fontes BDF em fontes BOGL com a ferramentabdftobogl
. - A ferramenta nosh
console-fb-realizer
usa as mesmas fontes "vt" que o novo FreeBSD 10.1 subsistema de terminal virtual do kernel , e assim compartilha a ferramenta de manipulação de fontes do FreeBSDvtfontcvt
para converter fontes BDF.Eu mesmo fiz isso com algumas fontes CJK e exibi algumas páginas de manual em chinês (do Debian) em um terminal virtual de espaço de usuário nosh.