UTF-8 não funciona em SSH

3

Eu configurei meu terminal no OSX para mostrar emoticons corretamente. Quando eu abro um terminal eu posso digitar e ver emoji corretamente. Minhas configurações de localidade para o OSX são mostradas abaixo. Quando inicio uma sessão do tmux, também funciona bem.

No entanto, quando eu inicio uma sessão ssh no meu servidor Ubuntu, o emoji é mostrado como um dígito estranho. Configurações de localização para a sessão ssh do Ubuntu também são mostradas abaixo.

Estou me perguntando por que isso acontece e como posso corrigi-lo. Eu estou usando Droid Sans Mono para Powerline como a fonte no meu terminal. A versão do OSX é El Capitan e a versão do Ubuntu no meu servidor é 14.04 LTS.

localidade do OSX

dino :: locale               
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

Localidade Linux (via sessão ssh)

testarossa :: ~ %locale              
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

Como é um emoji na sessão local no OSX

ComoéamesmastringemumasessãoremotanaminhamáquinaUbuntu

    
por Christophe De Troyer 23.10.2015 / 12:32

1 resposta

1

O valor de TERM é irrelevante. O que importa é o emulador de terminal (e também a versão do glibc). Veja por exemplo meus comentários em Debian # 790847 :

Interestingly, the lynx package in Fedora22 works
(passably with vte
 -- none of the other terminals display Emoji
 -- no need for a list).

enquanto (eu não posso verificar no momento), o Ubuntu 14.04 é provavelmente velho o suficiente para que o problema que eu notei depois, em glibc seja relevante:

Further checking in Debian/testing shows me that wcwidth() is returning -1's
for these values (which is incorrect, it should return 1's).  Lynx is behaving
correctly for this case -- it has no way to tell that the characters "should"
print as expected.
    
por 23.10.2015 / 13:48