Eu acidentalmente atualizei meu arquivo fish config para ler ~/.profile ,
que incluía uma linha dizendo locale=C .
Eu alterei isso para locale=C_UTF8 e tudo foi recuperado.
todoroki@todoroki-VJZ13B ~>printf "ä\n"
echo "ä"
ä
ä
ä
\udcc3\udca4: \u30b3\u30de\u30f3\u30c9\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093
de acordo com uma ferramenta de decodificação UTF-16 , \u30b3\u30de\u30f3\u30c9\u304c\u898b\u3064\u304b\u308a\u307e\u305b\u3093 is コマンドが見つかりません (= "comando não found "), que é a saída japonesa correta que eu espero.
No resultado printf e echo, o UTF-8 parece funcionar corretamente.
Isso acontece em todas as saídas da shell, como ls (caracteres japoneses em nomes de arquivos aparecem no formato hexadecimal UTF-16)
EDIT: ls output não foi utf-16, mas algo chamado "Octal Escape Sequence" (onde 月 se torna 640 )
ls em um diretório que contém 3 pastas chamadas C , あいう e 月 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 ''$'312314316'/
drwxr-xr-x 2 todoroki todoroki 4096 10月 11 09:05 ''$'640'/
(e isso é estranho porque 月 das datas de criação do arquivo são mostradas corretamente, enquanto o nome do diretório não é)
less vi nano se comporta de maneira mais estranha; um arquivo (a.txt, criado com o gedit) como abaixo
あ
い
う
ä
será exibido como
em less (reclama "a.txt" may be a binary file. See it anyway? ):
<E3><81><82>
<E3><81><84>
<E3><81><86>
<C3><A4>
em vi :
�~A~B
�~A~D
�~A~F
ä
e em nano :
^a^b
^a^d
^a^f
Não me lembro do que fiz, mas estava mostrando corretamente as letras japonesas há pelo menos dois dias (e por mais de seis meses).
Qual poderia ser o problema e a maneira de se recuperar disso?