todoroki@todoroki-VJZ13B ~>printf "ä\n"
                           echo "ä"
\udcc3\udca4: \u30b3\u30de\u30f3\u30c9\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093

according to a UTF-16 decode tool, \u30b3\u30de\u30f3\u30c9\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093 is コマンドが見つかりません (= "command not found"), which is the correct Japanese output I expect.

From the printf and echo result, UTF-8 seems working correctly.

This happens in all shell outputs, such as ls (Japanese characters in filenames shows up in UTF-16 hex format)
EDIT: ls output was not utf-16, but something called "Octal Escape Sequence" (where becomes \346\234\210)

ls in a directory which contains 3 folders named C, あいう, and outputs:

todoroki@todoroki-VJZ13B ~/test> ls -l
total 12
drwxr-xr-x 3 todoroki todoroki 4096 10月  4 15:02  C/
drwxr-xr-x 2 todoroki todoroki 4096 10月 11 09:04 ''$'\343\201\202\343\201\204\343\201\206'/
drwxr-xr-x 2 todoroki todoroki 4096 10月 11 09:05 ''$'\346\234\210'/

(and this is weird because of the file creation dates are shown correctly, while the directory name one isn't)

less vi nano behaves more strange; a file (a.txt, created with gedit) like below


will show as

in less (it complains "a.txt" may be a binary file. See it anyway?):


in vi:


and in nano:


I don't remember what I had done, but it was correctly showing Japanese letters at least two days ago (and for more than 6 months).

What could be the problem and the way to recover from this?

  • 2
    Just a shot in the dark - did you change any locale settings?
    – RudiC
    Oct 11, 2018 at 9:11

1 Answer 1


I had accidentally updated my fish config file to read ~/.profile,
which included a line saying locale=C.

I changed this to locale=C_UTF8 and everything recovered.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .