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.
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.
Gravidade: Alta para documentos não textuais; baixa para documentos de texto
Alguns aplicativos, nano-8.3 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.3; ao JOE-4.6; e a todos os reprodutores de mídia, exceto o Audacious-4.4.2.
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.82.5, 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 formato .zip tem esse problema
porque não salva a codificação para os nomes dos arquivos
arquivados. Quando unzip (na verdade, um link
simbólico para bsdunzip proveniente de libarchive-3.7.7) o extrai, por padrão os
nomes são assumidos como codificados como CP850, a página de código
do Windows para idiomas da Europa Ocidental. Mas os nomes podem ser
realmente codificados de uma maneira diferente se contiverem
caracteres não latinos (por exemplo, CP936 para chinês
simplificado). Então, sem especificar-se manualmente a codificação,
esses caracteres não latinos serão transformados em sequências
ilegíveis pelo bsdunzip.
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.9p2). 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.