character: ʵ (23454, #o55636, #x5b9e)
preferred charset: gb18030 (GB18030)
       code point: 0xCAB5
           syntax: w     which means: word
         category: C:Chinese (Han) characters of 2-byte character sets
c:Chinese
           |:While filling, we can break a line at this character.
      buffer code: #xE5 #xAE #x9E
        file code: #xCA #xB5 (encoded by coding system chinese-gb18030-unix)
          display: by this font (glyph code)
     -outline-      -normal-normal-normal-mono-13-*-*-*-c-*-gb2312.1980-0
(#x1172)

Emacs displays the font family name as:"\320\302\313\316\314\345"
those octal bytes represent for "ÐÂËÎÌå", in fact it isn't the font I tell
emacs to choose for Chinese characters.

By the way, in the elisp manual, all localized strings are showed as octal
bytes, Here's an example:

-- \272\257\312\375: funcall function &rest arguments
     `funcall' calls FUNCTION with ARGUMENTS, and returns whatever
     FUNCTION returns.

On Sat, Jun 7, 2008 at 5:23 AM, Jason Rumney <jasonr@gnu.org> wrote:

> Kevin Yu wrote:
> > If you input any Chinese into a new buffer, Ntemacs will use the same
> > font as ASCII characters (iso8859-1). Of course that font is not
> > suitable for Chinese, so I get only white spaces on the window.
> > describe-char shows that emacs has detected that it's a Chinese
> > character, but chosen a wrong font(wrong charset):
> > character: ʵ (23454, #o55636, #x5b9e)
> > preferred charset: gb18030 (GB18030)
> > code point: 0xCAB5
> > -outline-Monaco-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x03)
>
> Another font that maps unsupported glyphs to 0x03 instead of 0x00.
> DejaVu Sans Mono seems to do this too. Perhaps it is common amongst
> truetype fonts that were not designed for Windows.
>
> > if I open a existed file with Chinese characters, everything goes well.
>
> Can you show the output you get from C-u C-x = in that case? It seems
> strange that a different font would be used for the two cases. Perhaps
> comparing the two outputs will give some clues.
>
>