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:
Crítica: O aplicativo não realiza a função principal dele. A correção seria muito invasiva; é melhor procurar por uma substituição.
Alta: Parte da funcionalidade que o aplicativo fornece não é utilizável. Se essa funcionalidade for exigida, [então] é melhor procurar por uma substituição.
Baixa: O aplicativo funciona em todos os casos típicos de uso, porém carece de alguma funcionalidade normalmente fornecida pelos equivalentes dele.
Se existir uma solução alternativa conhecida para um pacote específico, ela aparecerá na página desse pacote. Para as informações mais recentes relativas a problemas relacionados à localidade para pacotes individuais, verifique as Observações de Editor no Wiki do BLFS.
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.29. 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.
Gravidade: Alta para documentos não textuais; baixa para documentos de texto
Alguns aplicativos, nano-7.2 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 Microsoft Windows tenha configurado padrões efetivos. Um exemplo desse problema são as etiquetas ID3v1 nos arquivos MP3 (veja-se a página Codificação ID3v1 da Wiki do BLFS para mais detalhes). 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-7.2; ao JOE-4.6; e a todos os reprodutores de mídia, exceto o Audacious-4.3.1.
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.
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.76.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.4p1). 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.
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.
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.