2

How can I make the console in CentOS 7 support Chinese?
I used localectl command. Following is the result:

System Locale: LANG=zh_CN.UTF-8
VC Keymap: cn
X11 Layout: cn

The sets are for Chinese. But some folders and files have been displayed the "■■■■" when use ls command list folders and files.

2

What you are seeing

There's a terminal emulator program built into the Linux kernel. It doesn't manifest as a running process with open file handles. It's layered on top of the framebuffer and the input event subsystem, which it uses internal kernel interfaces to access. It presents itself to application-mode systems as a series of kernel virtual terminal devices, /dev/tty1 and so forth. That's what you are employing.

This terminal emulator, being a kernel-mode system, is subject to quite severe resource constraints. So, historically, it has never supported large character sets that need a lot of (kernel address space) memory. This is why it is "greeking" those characters.

The solution to this is obviously to move the terminal emulator out of kernel mode. This has been mooted for years. I wrote a white paper on it almost a decade ago.

Of course, the many X Window System terminal emulator programs that you've no doubt heard of already do. They are ordinary application-mode programs, that render their glyphs into X windows displayed by an X server, and they can handle large character sets. So you would have no problem with Chinese in those terminal emulators.

user-space virtual terminals

There are also, however, terminal emulator programs that do not use an X server for their I/O, but are layered on top of the (external) APIs for the framebuffer and the input event subsystem. The use the framebuffer and input event subsystems directly, just like the kernel built-in terminal emulator program, but they too are just ordinary applications-mode programs, outwith the kernel and so not subject to its constraints. With those, you can also display Chinese. Indeed, several of these user-space virtual terminal programs have that as a touted feature.

They include:

  • zhcon — a userspace virtual terminal geared towards handling CJK I/O. Its particular strength is in handling ISO 2022 non-UTF encodings; its particular weakness is UTF encodings.
  • fbterm — a userspace virtual terminal that has spawned several forks including jfbterm. It has a bunch of CJK input method plug-ins.
  • bogl-bterm — a userspace virtual terminal that has spawned forks such as niterm.
  • The console-terminal-emulator and console-fb-realizer tools in nosh — a userspace virtual terminal aimed at replicating Linux and FreeBSD/PC-BSD kernel virtual terminals. By design, it has no dependencies on X libraries. Also by design, it does UTF only; no ISO 2022. It is (at the time of writing this answer) still very weak on CJK input methods.
  • kmscon — a userspace virtual terminal that is closely linked to the logind server in systemd and its notions of "seats".

Fonts

You then need Chinese fonts. That's slightly complex.

Several of these user-space virtual terminal programs make use of X libraries for font handling, keyboard mapping, CJK input methods, and so forth. They are not X clients, but they have dependencies from X libraries. So you use X fonts with them.

The others make other arrangements.

  • bogl-bterm has its own idiosyncratic font formats. One converts BDF fonts to BOGL fonts with the bdftobogl tool.
  • The nosh console-fb-realizer tool uses the same "vt" fonts as the new FreeBSD 10.1 kernel virtual terminal subsystem does, and thus shares the FreeBSD font manipulation tool vtfontcvt for converting BDF fonts.

    I have done this myself with some CJK fonts and displayed some Chinese manual pages (from Debian) in a nosh user-space virtual terminal.

Further reading

1

The Linux console itself does not support displaying Chinese, but you can run some alternative console(such as kmscon) to display Chinese without starting X.

  • Yes, just to explain "why": it seems to be because of the default framebuffer which can't display more than 512 glyphs. – apaul Apr 14 '15 at 8:09
  • That is not the reason why. The framebuffer knows nothing of glyphs. – JdeBP Apr 14 '15 at 9:23
0

Use localectl command to set. Following is an example localectl status # to display locale settings localectl set-locale LANG=en_GB.utf8 # to set the Language localectl list-locales # to lists locales locale list-keymaps # list keyboard mappings locale set-keymap uk # sets the key map

  • Thank you for your replay. I used localectl command. Following is the result: System Locale: LANG=zh_CN.UTF-8 VC Keymap: cn X11 Layout: cn The sets are for Chinese. But some folders and files have been displayed the "■■■■" when use ls command list folders and files. – Vincent Wong Apr 14 '15 at 6:44
  • “C” uses the US-ASCII 7-bit character set, and treats bytes with the high bit set as invalid characters. That's why, e.g., the "ls" command substitutes them with question marks in that locale. So you can use the “C” locale only if you are sure that you will never need 8-bit characters. – shubham Apr 14 '15 at 7:34
  • It also displayed ■ when I used a word of 2-bit in Chinese. – Vincent Wong Apr 14 '15 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.