gedit não pode reconhecer a codificação de caracteres, mas gvim pode

4

Eu tenho muitos arquivos de texto simples que vêm de um ambiente Windows.
Muitos deles usam uma página de código padrão do Windows, que não é nem ASCII (7 bits) nem UTF-8.

O

gvim não tem problemas para abrir esses arquivos, mas o gedit falha em fazer isso.
gvim informa a codificação como latin1 .

Eu assumo que gvim está fazendo uma suposição "inteligente" sobre a página de código.
(Eu acredito que esta página de código ainda tem variantes internacionais).

Algumas perguntas surgem disso:

  • (1). Existe alguma maneira o gedit pode ser dito para recoginze esta página de código?
    ** NB. [Update] Para este ponto (1), veja minha resposta abaixo. ** Para os pontos (2) e (3). veja a resposta de Oli.

  • (2). Existe uma maneira de verificar o sistema de arquivos para identificar esses arquivos problemáticos?

  • (3). Existe uma ferramenta de conversão em lote para converter esses arquivos para UTF-8?

(.. este mayhem de texto do mundo antigo foi realmente a última gota que me levou ao Ubuntu ... UTF-8 por padrão Brilliant )

[UPDATE]
  ** NB: ** Agora considero a atualização seguinte como parcialmente irrelevante, porque os arquivos "problemáticos" não são o "problema" (veja minha resposta abaixo).
Eu deixei aqui, porque pode ser de algum uso geral para alguém.

Eu trabalhei de uma maneira rápida e pronta para identificar os arquivos do problema ...
O comando file não era adequado, porque identificou meu arquivo de exemplo como ASCII ... mas um arquivo ASCII é 100% compatível com UTF-8 ...

Como mencionei em um comentário abaixo, o teste para um byte primeiro inválido de um ponto de código UTF-8 é:

  • se o primeiro byte (de um ponto de código UTF-8) estiver entre 0x80 e 0xBF (reservado para bytes adicionais), ou maior que 0xF7 ("overlong form"), que é considerado um erro

Eu sei sed (um pouco, através de uma porta Win32), então eu consegui montar um padrão RegEx que encontra esses bytes ofensivos .

É uma linha feia, por isso, olhe para longe se expressões regulares assustar você :)

Eu realmente aprecio se alguém indicar como usar valores hex em uma expressão range [] . Acabei de usar o ou operador \ |

fqfn="/my/fully/qualified/filename"  
sed -n "/\x80\|\x81\|\x82\|\x83\|\x84\|\x85\|\x86\|\x87\|\x88\|\x89\|\x8A\|\x8B\|\x8C\|\x8D\|\x8E\|\x8F\|\x90\|\x91\|\x92\|\x93\|\x94\|\x95\|\x96\|\x97\|\x98\|\x99\|\x9A\|\x9B\|\x9C\|\x9D\|\x9E\|\x9F\|\xA0\|\xA1\|\xA2\|\xA3\|\xA4\|\xA5\|\xA6\|\xA7\|\xA8\|\xA9\|\xAA\|\xAB\|\xAC\|\xAD\|\xAE\|\xAF\|\xB0\|\xB1\|\xB2\|\xB3\|\xB4\|\xB5\|\xB6\|\xB7\|\xB8\|\xB9\|\xBA\|\xBB\|\xBC\|\xBD\|\xBE\|\xBF\|\xF8\|\xF9\|\xFA\|\xFB\|\xFC\|\xFD\|\xFE\|\xFF/p" "${fqfn}"  

Então, agora eu vou enxertar isso na solução de lote do Oli ... Obrigado Oli!

PS. Aqui está o byte UTF-8 inválido que ele encontrou no meu arquivo de amostra ...
"H.Bork, Gøte-borg." ... o "ø" = F8 hex ... que é um caractere UTF-8 inválido.

    
por Peter.O 29.10.2010 / 14:46

4 respostas

4

iconv é provavelmente o que você deseja usar. iconv -l mostrará as codificações disponíveis e você poderá usar alguns comandos para recodificar todas:

# all text files are in ./originals/
# new files will be written to ./newversions/

mkdir -p newversions
cd originals
for file in *.txt; do
    cat $file | iconv -f ASCII -t utf-8 > ../newversions/$file;
done

Se você quiser fazer isso com arquivos que não são codificados (porque eles estão em todo o lugar), é necessário trazer mais alguns comandos: find , file , awk e sed . Os dois últimos estão lá apenas para processar a saída do arquivo.

for file in find . -type f -exec file --mime {} \; | grep "ascii" | awk '{print }' | sed s/.$//; do
    ...

Eu não tenho idéia se isso realmente funciona, então eu certamente não iria executá-lo de nada, mas o diretório menos importante que você tem (faça uma pasta de teste com alguns arquivos ASCII conhecidos). A sintaxe do find pode impedir que ele esteja dentro de um loop for. Eu espero que alguém com mais experiência possa pular lá e resolvê-lo para fazer a coisa certa.

    
por Oli 29.10.2010 / 15:10
1

O Gedit só pode detectar o conjunto de caracteres correto se estiver listado em "Codificação de arquivo-aberto-caractere". Você pode alterar essa lista, mas lembre-se de que o pedido é importante.

    
por skarmoutsosv 24.02.2014 / 16:22
0

Eu estive pensando sobre isso um pouco mais ...

Sim, o "ø" = 0xF8 hex * foi definitivamente a razão pela qual o gedit não abriria o arquivo ...
Por quê? Porque não é um byte UTF-8 válido.
Por padrão, o gedit só abre arquivos UTF-8 ...

No entanto, o gedit possui um recurso de detecção automática de página de códigos, mas primeiro é necessário adicionar Adicionar páginas de códigos à sua lista de "possíveis".

A caixa de diálogo vermelha brilhante que aparece quando gedit não reconhece a página de códigos, tem um buttone nela que permite Adicionar outra página de código ...

Problema resolvido! ... quase ...

A questão atual agora levanta a cabeça novamente ... Qual página de código é?

Na minha situação, posso presumir que é a página de código padrão do Windows em inglês (para minha região ?, ou para a região de origem do arquivo? .. Eu mencionei "knarly":) ....

De qualquer forma, o gedit permitirá que você carregue um arquivo depois que você tiver adicionado a página de códigos à sua lista ...

Portanto, embora todos os comandos do Terminal sejam úteis e interessantes por si só, parece que essa linha de pensamento estava indo na direção errada.

Não há nada intrinsecamente errado nesses arquivos ...
A questão parece ser puramente sobre páginas de código.

gedit pode abrir o arquivo, assim como o gvim pode.
... mas a página de códigos relevante deve primeiro ser adicionada à sua lista de páginas de código.
por exemplo. através da caixa de diálogo File-Open ou da caixa de diálogo de aviso vermelha que encontrei.

    
por Peter.O 29.10.2010 / 19:32
0

Você pode usar qualquer uma das três linhas de comando:

gedit --encoding=utf-8 filename
gedit --encoding=iso-8859-15 filename
gedit --encoding=utf-16 filename
. . . . .
    
por flaja94 27.03.2018 / 18:36