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 '18 at 9:11

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.

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.