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?
):
<E3><81><82>
<E3><81><84>
<E3><81><86>
<C3><A4>
in vi
:
�~A~B
�~A~D
�~A~F
ä
and in nano
:
^a^b
^a^d
^a^f
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?
locale
settings?