Problemas Relacionados à Localidade

Esta página contém informações acerca de problemas e de consequências relacionados à localidade. Nos parágrafos seguintes você encontrará uma visão geral das coisas que podem surgir ao configurar o seu sistema para várias localidades. Muitos (mas, não todos) problemas existentes relacionados à localidade podem ser classificados e enquadrados sob um dos títulos abaixo. As avaliações de gravidade abaixo usam o seguinte critério:

Se existir uma solução alternativa conhecida para um pacote específico, ela aparecerá na página desse pacote.

A Codificação Necessária Não É uma Opção Válida no Aplicativo

Gravidade: Crítica

Alguns aplicativos exigem que o(a) usuário(a) especifique a codificação de caracteres para os dados de entrada gerada ou de saída gerada deles e apresentam somente uma escolha limitada de codificações. Esse é o caso para a opção -X no Enscript-1.6.6; para a opção -input-charset no Cdrtools-3.02a09 não remendado; e para os conjuntos de caracteres oferecidos para exibição no menu do Links-2.30. Se a codificação exigida não estiver na lista, [então] o aplicativo geralmente se torna completamente inutilizável. Para os aplicativos não interativos, possivelmente seja possível contornar isso convertendo-se o documento para um conjunto suportado de caracteres de entrada gerada antes de submetê-lo ao aplicativo.

Uma solução para esse tipo de problema é a de implementar o suporte necessário para a codificação ausente como um remendo para o aplicativo original ou encontrar um substituto.

O Aplicativo Assume a Codificação Baseada no Locale dos Documentos Externos

Gravidade: Alta para documentos não textuais; baixa para documentos de texto

Alguns aplicativos, nano-8.1 ou JOE-4.6, por exemplo, assumem que os documentos sempre estejam na codificação implícita pelo locale atual. Enquanto essa presunção possivelmente seja válida para os documentos criados pelo(a) usuário(a), ela não é segura para os externos. Quando essa presunção falha, os caracteres não ASCII são exibidos incorretamente e o documento possivelmente se torne ilegível.

Se o documento externo for inteiramente baseado em texto, [então] ele pode ser convertido para a codificação atual do locale usando-se o aplicativo iconv.

Para documentos que não sejam baseados em texto, isso não é possível. De fato, a presunção feita no aplicativo possivelmente seja completamente inválida para documentos onde o sistema operacional Windows da Microsoft tenha configurado padrões efetivos. Um exemplo desse problema são as etiquetas ID3v1 nos arquivos MP3. Para esses casos, a única solução é a de encontrar um aplicativo substituto que não tenha o problema (por exemplo, um que te permitirá especificar a codificação presumida do documento).

Entre os pacotes do BLFS, esse problema se aplica ao nano-8.1; ao JOE-4.6; e a todos os reprodutores de mídia, exceto o Audacious-4.4.

Outro problema nessa categoria é quando alguém não consegue ler os documentos que você enviou, pois o sistema operacional dessa pessoa está configurado para manusear diferentemente as codificações de caracteres. Isso pode acontecer frequentemente quando a outra pessoa estiver usando o Microsoft Windows, o qual fornece apenas uma codificação de caracteres para um dado país. Por exemplo, isso causa problemas com documentos do TeX codificados em UTF-8 criados no Linux. No Windows, a maioria dos aplicativos assumirá que esses documentos tenham sido criados usando a codificação padrão de oito (08) bits do Windows.

Em casos extremos, os problemas de compatibilidade de codificação do Windows possivelmente somente sejam resolvidos executando-se os aplicativos do Windows sob o Wine.

O Aplicativo Usa ou Cria os Nomes de Arquivo na Codificação Errada

Gravidade: Crítica

O padrão POSIX manda que a codificação do nome de arquivo seja a codificação implícita pela categoria de locale LC_CTYPE atual. Essa informação está bem ocultada na página que especifica o comportamento dos aplicativos Tar e Cpio. Alguns aplicativos obtém isso errado por padrão (ou, simplesmente, não tem informação suficiente para obter isso certo). O resultado é o de que eles criam nomes de arquivo que não são subsequentemente mostrados corretamente pelo ls; ou eles se recusam a aceitar nomes de arquivo que o ls mostra adequadamente. Para a biblioteca GLib-2.80.4, o problema pode ser corrigido configurando-se a variável de ambiente G_FILENAME_ENCODING para o valor especial "@locale". Os aplicativos baseados na Glib2 que não respeitarem essa variável de ambiente são defeituosos.

O Zip-3.0 e o UnZip-6.0 tem esse problema, pois eles rigidamente codificam a codificação esperada de nome de arquivo. O UnZip contém uma tabela rigidamente codificada de conversão entre as codificações CP850 (DOS) e ISO-8859-1 (UNIX) e usa essa tabela quando extrai arquivamentos criados sob o DOS ou sob o Microsoft Windows. Entretanto, essa presunção funciona somente para aqueles(as) nos Estados Unidos da América do Norte e não para qualquer um(a) usando um locale UTF-8. Os caracteres não ASCII serão desfigurados nos nomes de arquivos extraídos.

A regra geral para se evitar essa classe de problemas é a de se evitar instalar aplicativos quebrados. Se isso for impossível, [então] a ferramenta de linha de comando convmv pode ser usada para corrigir os nomes de arquivos criados por esses aplicativos quebrados; ou, intencionalmente, desfigurar os nomes de arquivos existentes para satisfazer as expectativas quebradas de tais aplicativos.

Em outros casos, um problema similar é causado importando-se nomes de arquivos a partir de um sistema usando um locale diferente com uma ferramenta que não é ciente do locale (por exemplo, o OpenSSH-9.8p1). Para a finalidade de se evitar desfigurar os caracteres não ASCII quando se transferir arquivos para um sistema com um locale diferente, quaisquer dos seguintes métodos podem ser usados:

  • Transfira de qualquer modo; corrija o dano com o convmv.

  • No lado do(a) remetente, crie um arquivamento tar com a chave --format=posix passada para o tar (isso será o padrão em uma versão futura do tar).

  • Envie os arquivos como anexos de mensagem de correio eletrônico. Os clientes de correio eletrônico especificam a codificação dos nomes de arquivos anexados.

  • Escreva os arquivos para um disco removível formatado com um sistema de arquivos FAT ou FAT32.

  • Transfira os arquivos usando o Samba.

  • Transfira os arquivos via FTP usando um servidor (atualmente, isso significa somente o wu-ftpd, que tem um mau histórico de segurança) e um cliente (por exemplo, o lftp) cientes da RFC2640.

Os últimos quatro métodos funcionam, pois os nomes de arquivos são convertidos automaticamente do locale do(a) remetente para UNICODE e armazenados ou enviados nessa forma. Eles são então convertidos transparentemente do UNICODE para a codificação do locale do(a) recipiente.

O Aplicativo Quebra Caracteres Multi Byte ou Não Conta Células de Caracteres Corretamente

Gravidade: Alta ou crítica

Muitos aplicativos foram escritos em uma era mais antiga onde locales multi Byte não eram comuns. Tais aplicativos assumem que o tipo de dados "char" do C, que é um Byte, pode ser usado para armazenar caracteres únicos. Além disso, eles assumem que qualquer sequência de caracteres é uma sequência de caracteres válida e que cada caractere ocupa uma célula única de caractere. Tais presunções quebram completamente em locales UTF-8. A manifestação visível é a de que o aplicativo trunca sequências de caracteres prematuramente (isto é, em oitenta (80) Bytes, em vez de oitenta (80) caracteres). Os aplicativos baseados em terminal não colocam o cursor corretamente na tela; não reagem à tecla "Backspace" apagando um caractere; e deixam caracteres inúteis ao atualizar a tela, geralmente transformando a tela em uma completa bagunça.

Corrigir esses tipos de problemas é uma tarefa tediosa, a partir de um ponto de vista do(a) programador(a), semelhante a todos os outros casos de retro adequar conceitos novos no projeto falho antigo. Nesse caso, deve-se reprojetar todas as estruturas de dados para a finalidade de acomodar ao fato de que um caractere completo possivelmente abranja um número variável de "char"s (ou alternar para wchar_t e converter conforme necessário). Também, para cada chamada à "strlen" e funções similares, descobrir se um número de Bytes; um número de caracteres; ou a largura da sequência de caracteres realmente foi declarada. Ocasionalmente, é mais rápido escrever um aplicativo com a mesma funcionalidade desde o zero.

Entre os pacotes do BLFS, esse problema se aplica ao xine-ui-0.99.14 e a todos os shells.

O Pacote Instala as Páginas de Manual em Codificação Incorreta ou Não Exibível

Gravidade: Baixa

O LFS espera que as páginas de manual estejam na codificação específica para o idioma (geralmente oito (08) bits), conforme especificado na página Man DB do LFS. Entretanto, alguns pacotes instalam as páginas de manual traduzidas na codificação UTF-8 (por exemplo, o Shadow já tratou); ou páginas de manual em idiomas que não estão na tabela. Nem todos os pacotes do BLFS foram auditados para conformidade com as exigências colocadas no LFS (a quase totalidade foi verificada e correções colocadas no livro para os pacotes conhecidos por instalar páginas de manual não conformes). Se você encontrar uma página de manual instalada por quaisquer dos pacotes do BLFS que obviamente esteja na codificação errada, [então], por favor, remova-a ou converta-a conforme necessário e informe isso para a equipe do BLFS como um defeito.

Você pode verificar facilmente o seu sistema para quaisquer páginas de manual não conformes, copiando o seguinte script curto de shell para algum local acessível,

#!/bin/sh
# Início checkman.sh
# Uso: find /usr/share/man -type f | xargs checkman.sh
for a in "$@"
do
    # echo "Verificando $a..."
    # Página de Manual ASCII puro (possivelmente exceto comentários) está OK
    grep -v '.\\"' "$a" | iconv -f US-ASCII -t US-ASCII >/dev/null 2>&1 \
        && continue
    # Página de Manual não UTF-8 está OK
    iconv -f UTF-8 -t UTF-8 "$a" >/dev/null 2>&1 || continue
    # Encontrada uma Página de Manual UTF-8, ruim.
    echo "Página de Manual UTF-8: $a" >&2
done
# Fim checkman.sh

e, então, emitindo o seguinte comando (modifique o comando abaixo se o script checkman.sh não estiver na sua variável de ambiente PATH):

find /usr/share/man -type f | xargs checkman.sh

Observe que, se você tiver páginas de manual instaladas em qualquer outro local que /usr/share/man (por exemplo, /usr/local/share/man), [então] você precisa modificar o comando acima para incluir esse local adicional.