Efeito do $ LANG no terminal

Question

Estou tentando aprender como a variável $LANG se comporta com o gnome-terminal (e sua opção de preferência de codificação de caracteres). Eu tenho usado iso8859-1 (latin1) como meu conjunto de caracteres principal e todos os meus nomes de arquivos são codificados como tal.

Para os testes a seguir, farei um ls -l de um diretório com caracteres acentuados em espanhol em seus nomes de arquivo:

Caso # 1:

• gnome-terminal configurado para ISO-8859-1
• LANG definido como "en_US-iso8859-1"
• Resultado: vejo todos os arquivos corretamente

Caso # 2:

• gnome-terminal configurado para UTF-8
• LANG definido como "en_US-iso8859-1"
• Resultado: vejo caracteres ilegíveis para todos os caracteres espanhóis. Isso é esperado, pois mudei a codificação de caracteres para o terminal

Caso # 3:

• gnome-terminal configurado para ISO-8859-1
• LANG definido como "en_US-UTF-8"
• Resultado: vejo caracteres ilegíveis para todos os caracteres espanhóis.

Por que é que neste último caso eu vejo personagens ilegíveis? A saída de ls não deve enviar os nomes dos arquivos diretamente para o gnome-terminal como eles são? E como o gnome-terminal está configurado para ISO-8859-1, eu esperava que eles parecessem corretos.

Por um momento eu pensei que, talvez, talvez o bash estivesse considerando minha variável $LANG e realizando alguma conversão. Então mudei meu terminal para UTF-8, mas ainda não consigo ver os caracteres corretamente. Eu até canalizei a saída de ls para xxd e, para minha surpresa, ainda vejo os arquivos codificados como estão: ISO-8859-1.

Para finalizar: Se minha listagem contiver caracteres ISO-8859-1 e meu emulador de terminal estiver configurado para a mesma codificação de caracteres: quem está fazendo a conversão quando LANG está definido de outra forma?

Obrigado por qualquer ajuda que você possa fornecer.

Craconia

    

Answer 1

Sua configuração para LANG deve corresponder à do terminal. Mais precisamente, sua configuração para LC_CTYPE (a codificação de caracteres) deve corresponder à codificação do terminal, as outras configurações de local não precisam corresponder. E a codificação do terminal é geralmente especificada por uma opção do emulador de terminal e não por uma variável de código de idioma. O LC_CTYPE combina duas indicações: diz aos aplicativos qual codificação usar no terminal (tanto para entrada quanto para saída) e informa aos aplicativos qual codificação usar com os arquivos. Nos casos 2 e 3, você disse a ls para exibir a saída em uma codificação que é diferente da do terminal, então a saída é distorcida.

Se você trabalhar com as codificações UTF-8 e Latin-1 em momentos diferentes, configure seu terminal para usar o UTF-8. Isso deve fazer com que defina LC_CTYPE para um valor indicando UTF-8; não substitua essa configuração. (Se o emulador de terminal não definir LC_CTYPE , substitua-o no arquivo de inicialização do shell ou durante toda a sessão.) Para trabalhar com dados do latin-1 em um terminal UTF-8, use luit (incluído no conjunto de utilitários X).

LC_CTYPE=en_US.iso88591 luit

(Você pode usar qualquer outra localidade com a mesma codificação, por exemplo, LC_CTYPE=es_ES.iso88591 luit .)

    

Answer 2

No caso # 2 e # 3 você está misturando duas codificações diferentes: UTF-8 e Latin-1. No caso # 1 você está usando o Latin-1 para ambos, então você não tem nenhum problema.

O comando ls (e todos os outros programas que se comportam bem) usam a configuração LANG para determinar a codificação .

Você pode misturar dois idiomas diferentes, mas não deve misturar duas codificações diferentes .

Assegure-se de que as variáveis de ambiente LC_ * também usem a mesma codificação que sua variável LANG.

Como regra geral, você deve configurar seu sistema atualmente para usar apenas UTF-8.

Se você precisar editar arquivos de dados antigos (por exemplo, propriedades do java), use um editor especializado (por exemplo, java ide) ou garanta a codificação com ferramentas como iconv ou 'recode ..

    

Answer 3

Isso pode estar fora da sua necessidade, mas ...

Acontece que no RHEL5, e provavelmente antes, muitas das páginas do manual foram, de alguma forma, para alguma razão prevista, foram ascendidas. Ou seja, a página principal bruta foi convertida de seu conjunto de caracteres nativo para ASCII de 7 bits. Não importa o que você faça com o LC e o LANG, a página de manual para latin1 produz uma página de manual que é efetivamente inútil. Todos os caracteres especiais (8 bits) foram substituídos por espaços reservados de 7 bits (geralmente ?? ). Eu acho isso hilário.

Mas a versão utf8 dessas páginas man pode existir no diretório específico do idioma. O truque é pedir por seu nome certo. Por exemplo, latin1 é na verdade iso_8859-1 . Se você fizer uma página man sobre ele e suas configurações de LANG estiverem corretas, você verá o que espera; A página man é encontrada no subdiretório específico do idioma ( en/man7/iso_8859-1.7 ). Mas se você perguntar por iso-8859-1 , por algum motivo, você obtém a versão ASCII.