Autor Tópico: Incompatibilidade gedit e bloco de notas  (Lida 6404 vezes)

Offline rd7l

  • Usuário Ubuntu
  • *
  • Mensagens: 48
    • Ver perfil
Incompatibilidade gedit e bloco de notas
« Online: 14 de Agosto de 2009, 04:09 »
Olá!

Quando salvo um texto no gedit (acrescentando a extensão .txt) e vou abrir no "Bloco de Notas" do Windows alguns problemas de formatação aparecem, como por exemplo um quadrado no lugar de cada enter que dei.

No gedit a codificação que uso é UTF-8 e no "Bloco de Notas" é ANSI. Seria este o problema? Como resolver já que no Ubuntu não consigo encontrar a codificação ANSI?

Obrigado!

Offline Xterminator

  • Usuário Ubuntu
  • *
  • Mensagens: 1.279
    • Ver perfil
Re: Incompatibilidade gedit e bloco de notas
« Resposta #1 Online: 14 de Agosto de 2009, 10:01 »
O problema aí é com o Bloco de Notas "ELE I XIS O", que não reconhece um arquivo texto codificado corretamente, até o Edit (editor de textos do DOS faz isto)
abra o arquivo no Wordpad e veja o que estou dizendo, ou vá em executar no windows coloque cmd e apos abrir o prompt, digite edit, abra o arquivo em questão e veja que não vale a pena usar o "L I X O" do bloco de notas, tá dado o recado ;-)
alternativamente, você pode escolher Salvar como no gEdit e escolher a codificação compatível com o seu Windows, provavelmente ISO-8859-1.
existem diferenças entre o formato de arquivo texto *nix,"dos/windows" a chamada quebra de linha, a maioria absoluta de editores de texto reconhece isto.
http://pt.wikipedia.org/wiki/Nova_linha
Citar
Problemas

As diferentes convenções para a quebra de linha muitas vezes fazem com que os arquivos de texto copiados duma plataforma para outra sejam mostrados de maneira incorreta. Por exemplo, arquivos criados no Unix ou Apple Macintosh serão vistos como uma longa e única linha no Windows. Analogamente, um arquivo do Windows visto no Unix terá seus CR mostrados como um ^M ao final de cada linha ou como um segundo pula linha.
O problema pode ser de difícil detecção. Por exemplo, um compilador poderá falhar com erros de sintaxe obscuros embora o arquivo fonte pareça normal. Os editores de textos mais recentes reconhecem todas as variações de quebra de linha do tipo CR e LF, permitindo ao usuário converter entre os diferentes padrões.
« Última modificação: 14 de Agosto de 2009, 10:10 por Xterminator »

Lunik

  • Visitante
Re: Incompatibilidade gedit e bloco de notas
« Resposta #2 Online: 14 de Agosto de 2009, 10:30 »
Eu não consideraria isso um erro ou incompatibilidade do notepad.
É apenas uma questão que unixes usam LF e o windows usa CR-LF.

Existe um editor de texto simples chamado Leafpad (um clone melhorado do notepad) onde você pode escolher o modo como quer salvar (LF, CRLF, CR). E no windows existem alguns que fazem isso também (acho que o notepad++ faz isso). Não acho que a codificação vai mudar algo.

(bem, talvez o pecado maior ser o fato do notepad ter problemas pra ler arquivos que usam LF, enquanto que o gedit consegue ler os dois sem problemas)

Offline travail

  • Usuário Ubuntu
  • *
  • Mensagens: 17
    • Ver perfil
Re: Incompatibilidade gedit e bloco de notas
« Resposta #3 Online: 02 de Setembro de 2009, 14:15 »
O problema aí é com o Bloco de Notas "ELE I XIS O", que não reconhece um arquivo texto codificado corretamente, até o Edit (editor de textos do DOS faz isto)
abra o arquivo no Wordpad e veja o que estou dizendo, ou vá em executar no windows coloque cmd e apos abrir o prompt, digite edit, abra o arquivo em questão e veja que não vale a pena usar o "L I X O" do bloco de notas, tá dado o recado ;-)
alternativamente, você pode escolher Salvar como no gEdit e escolher a codificação compatível com o seu Windows, provavelmente ISO-8859-1.
existem diferenças entre o formato de arquivo texto *nix,"dos/windows" a chamada quebra de linha, a maioria absoluta de editores de texto reconhece isto.
http://pt.wikipedia.org/wiki/Nova_linha
Citar
Problemas

As diferentes convenções para a quebra de linha muitas vezes fazem com que os arquivos de texto copiados duma plataforma para outra sejam mostrados de maneira incorreta. Por exemplo, arquivos criados no Unix ou Apple Macintosh serão vistos como uma longa e única linha no Windows. Analogamente, um arquivo do Windows visto no Unix terá seus CR mostrados como um ^M ao final de cada linha ou como um segundo pula linha.
O problema pode ser de difícil detecção. Por exemplo, um compilador poderá falhar com erros de sintaxe obscuros embora o arquivo fonte pareça normal. Os editores de textos mais recentes reconhecem todas as variações de quebra de linha do tipo CR e LF, permitindo ao usuário converter entre os diferentes padrões.
Caro colega Xterminator, também enfrentei esse mesmo problema, e após alguns testes, verifiquei que a correta codificação compatível com o lixopad do Windows seria: Ocidental (Windows - 1252).