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; a pseudo-file under
/sys that shows the active KVT number; and a series of CGA-style video buffer devices,
/dev/vcsa1 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.
- 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.
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".
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.