Início / unix / Perguntas / 449003
Accepted
Ole Tange
Asked: 2018-06-11 13:36:08 +0800 CST

Caracteres não-ascii não são mais exibidos no bash

  • 772

Atualizado: Este não é um problema do sistema de arquivos.

Eu costumava ser capaz de entrar:

$ echo kødpålæg

Mas agora bash/zsh mude isso para:

bash$ echo kddddddddplg
zsh$ echo k<c3><b8>dp<c3><a5>l<c3><a6>g

Eu posso executar cate inserir 'kødpålæg' sem problemas:

$ cat
kødpålæg
kødpålæg

Isso é tanto com este ambiente:

$ locale   
LANG=C
LANGUAGE=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

e neste:

$ locale 
LANG=da_DK.utf8
LANGUAGE=da_DK.utf8
LC_CTYPE="da_DK.utf8"
LC_NUMERIC="da_DK.utf8"
LC_TIME="da_DK.utf8"
LC_COLLATE="da_DK.utf8"
LC_MONETARY="da_DK.utf8"
LC_MESSAGES="da_DK.utf8"
LC_PAPER="da_DK.utf8"
LC_NAME="da_DK.utf8"
LC_ADDRESS="da_DK.utf8"
LC_TELEPHONE="da_DK.utf8"
LC_MEASUREMENT="da_DK.utf8"
LC_IDENTIFICATION="da_DK.utf8"
LC_ALL=da_DK.utf8

cshnão muda 'kødpålæg'.

Como posso recuperar o comportamento antigo, para que eu possa inserir 'kødpålæg'?

A execução de qualquer um deles fornece o comportamento antigo:

LC_ALL=en_GB.utf-8 luit
LC_ALL=da_DK.utf-8 luit
LC_ALL=en_GB.iso88591 luit
LC_ALL=da_DK.iso88591 luit

mas apenas para essa única sessão.

Este:

$ od -An -vtx1
ø

Dá:

 c3 b8 0a

Portanto, parece que a entrada do Konsole para o bash é UTF8.

$ konsole --version
QCoreApplication::arguments: Please instantiate the QApplication object first
Qt: 5.5.1
KDE Frameworks: 5.18.0
Konsole: 15.12.3

$ bash --version
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ zsh --version
zsh 5.1.1 (x86_64-ubuntu-linux-gnu)

$ dpkg -l csh
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name              Version       Architecture  Description
+++-=================-=============-=============-========================================
ii  csh               20110502-2.1u amd64         Shell with C-like syntax
bash locale

2 respostas

  1. Best Answer

    Eu diria que provavelmente seu terminal está configurado incorretamente e envia e exibe caracteres em algum conjunto de caracteres de byte único, provavelmente ISO8859-1 ou ISO8859-15, dados os caracteres de amostra que você mostra em vez do conjunto de caracteres da localidade.

    Normalmente, não há caractere ø, å, æna localidade C e a codificação ISO8859-1(5) desses caracteres (0xf8, 0xe5, 0xe6) não forma caracteres válidos em UTF-8. Editores de linha como readline ou zle precisam decodificá-los em caracteres, pois precisam saber quantos bytes compõem uma coluna de exibição para que possam posicionar o cursor corretamente.

    Além disso, na localidade C que na maioria dos sistemas usa ASCII, já que não há nenhum caractere em ASCII com o 8º bit definido, esse 8º bit seria entendido bashcomo significando Meta. 0xF8 seria entendido como significando Meta+x(0x78 (x) | 0x80), porque é isso que alguns terminais enviam Alt+xou Meta+x.

    Enquanto Mx não está vinculado a nada por padrão em bash, ßseria entendido como M-_ e inseriria a última palavra. Você pode desativar isso com:

    bind 'set convert-meta off'

    Shells como cshsão muito antigos para saber que os caracteres podem ser feitos de vários bytes ou ocupar qualquer coisa além de uma única largura de coluna, então eles não se incomodam.

    Para verificar essa teoria, execute:

    od -An -vtx1

    E insira esses caracteres seguidos por ^D^De veja qual codificação você vê. Se você vir 0xf8 para ø, isso significa que estou certo. Se você vir 0xc3 0xb8 em vez disso, que é a codificação UTF-8 ø, isso significa que estou errado.

    Ou altere a localidade para da_DK.iso88591(verifique locale -ao nome exato da localidade em seu sistema) e veja se isso funciona melhor.

    Agora, por que seu terminal pode enviar a codificação errada para esses caracteres, talvez tenha sido iniciado em uma localidade onde o conjunto de caracteres era iso8859-1. Talvez esteja configurado para ignorar a localidade e usar um conjunto de caracteres específico (procure por conjunto de caracteres ou codificação em sua configuração). Ou talvez você tenha sshentrado em outro sistema onde a localidade estava usando ISO8859-1(5) como seu conjunto de caracteres.

    Eu posso reproduzir esse comportamento se de um terminal UTF-8, eu executar:

    LC_ALL=en_GB.iso885915 luit

    E de dentro, luitaltere a localidade para Cou UTF-8 e insira caracteres não ASCII.

    • 4

  2. Seu catteste indica que a conexão do terminal está limpa em 8 bits. Portanto, parece um possível problema de localidade.

    Execute locale -apara verificar se a localidade escolhida "da_DK.utf8" existe; se não estiver listado e você estiver em um sistema que pertence à família Debian/Ubuntu, talvez seja necessário descomentá-lo /etc/locale.gene executá- lo locale-gencomo root.

    Além disso, algumas versões do shell não podem alternar as localidades dinamicamente, mas continuam usando a configuração de localidade que foi originalmente herdada de seu processo pai . Se for esse o caso, a execução LC_CTYPE=da_DK.UTF-8 bashrestauraria o comportamento desejado, apenas para aquela sessão específica. Se isso for verdade, alterar a localidade padrão do sistema para qualquer localidade UTF-8 suportada e, em seguida, reinicializar pode ajudar: alteraria a localidade dos processos responsáveis ​​​​por manipular seu login e iniciar seu shell.

    • 0

relate perguntas