Fui testar meu programa com textos com acentos e notei que quando compacto o texto, os caracteres com acento sao considerados como sendo 2 caracteres quaisquer. E depois quando com descompactar, o programa reconhece esses 2 caracteres como sendo 2 caracteres mesmo, e o texto fica diferente do atual.
Como posso corrigir este problema??
O que acontece é que o seu texto foi codificado no formato UTF-8. Neste formato, as letras acentuadas do alfabeto latino são representadas por dois bytes, sendo que o primeiro é sempre um prefixo, de número decimal 195 (C3 em hexadecimal). Verifique se não é o seu caso: no lugar de cada acento há dois caracteres, e o primeiro tem valor decimal 195.
Uma maneira de enteder o que se passa é usar o navegador Firefox para ver o arquivo, porque o Firefox suporta várias codificações de caracteres diferentes.
Por exemplo, no Linux usei o Gedit para criar um arquivo com as palavras:
isto é um teste
Ao abrí-lo no Firefox, aparece :
isto é um teste
No menu View do Firefox você encontra o comando Character Encoding, e dentro dele várias opções , entre elas Western (ISO-8859-1) e Unicode (UTF-8). Escolha Unicode (UTF-8) e repare que o texto aparece como era originalmente.
O que aconteceu? O Gedit salvou o arquivo na codificação UTF-8, mas o Firefox presumiu erradamente que arquivo estava no formato ISO-8859-1. Na tabela ISO-8859-1 [1] o caractere 195 ou C3 corresponde à letra A maiúscula com til, que é o que o Firefox exibiu.
Experimente abrir o seu arquivo original e o arquivo processado com o Firefox, e use View > Character Encoding para alternar entre ISO-8859-1 e UTF-8 para ver o que se passa.
Outra forma de investigar a questão é usar o utilitário xxd que eu mencionei em outro tópico, porque ele não esconde nada: simplesmente mostra todos os bytes do arquivo sem nenhum enfeite ou decodificação, em formato hexadecimal. Veja como o xxd mostra o arquivo de teste:
$ xxd teste.txt
0000000: 6973 746f 20c3 a920 756d 2074 6573 7465 isto .. um teste
0000010: 0a .
$
Os espaços em branco são código hexadecimal 20. Logo depois do primeiro 20 vem um C3 e um A9. Em UTF-8 a combinação C3A9 corresponde a letra "e" minúscula com acento agudo, mas em ISO-8859-1 a mesma combinação representa um "A" maíusculo com til, seguido de um símbolo de copyright. Confira na Wikipédia:
[1] http://en.wikipedia.org/wiki/ISO_8859-1
[2] http://en.wikipedia.org/wiki/UTF-8
O algoritmo LZ-77 é totalmente insensível a estas questões de codificação. Ele não enxerga caracteres acentuados ou não, mas apenas bytes.
Portanto, é possível que seu programa de compressão esteja funcionando corretamente, mas ao examinar o arquivo gerado você está usando um programa que presume uma codificação diferente daquela usada quando o arquivo foi criado. Experimente usar o xxd ou o Firefox.
--
Luciano
Uma maneira de enteder o que se passa é usar o navegador Firefox para ver o arquivo, porque o Firefox suporta várias codificações de caracteres diferentes.
Por exemplo, no Linux usei o Gedit para criar um arquivo com as palavras:
isto é um teste
Ao abrí-lo no Firefox, aparece :
isto é um teste
No menu View do Firefox você encontra o comando Character Encoding, e dentro dele várias opções , entre elas Western (ISO-8859-1) e Unicode (UTF-8). Escolha Unicode (UTF-8) e repare que o texto aparece como era originalmente.
O que aconteceu? O Gedit salvou o arquivo na codificação UTF-8, mas o Firefox presumiu erradamente que arquivo estava no formato ISO-8859-1. Na tabela ISO-8859-1 [1] o caractere 195 ou C3 corresponde à letra A maiúscula com til, que é o que o Firefox exibiu.
Experimente abrir o seu arquivo original e o arquivo processado com o Firefox, e use View > Character Encoding para alternar entre ISO-8859-1 e UTF-8 para ver o que se passa.
Outra forma de investigar a questão é usar o utilitário xxd que eu mencionei em outro tópico, porque ele não esconde nada: simplesmente mostra todos os bytes do arquivo sem nenhum enfeite ou decodificação, em formato hexadecimal. Veja como o xxd mostra o arquivo de teste:
$ xxd teste.txt
0000000: 6973 746f 20c3 a920 756d 2074 6573 7465 isto .. um teste
0000010: 0a .
$
Os espaços em branco são código hexadecimal 20. Logo depois do primeiro 20 vem um C3 e um A9. Em UTF-8 a combinação C3A9 corresponde a letra "e" minúscula com acento agudo, mas em ISO-8859-1 a mesma combinação representa um "A" maíusculo com til, seguido de um símbolo de copyright. Confira na Wikipédia:
[1] http://en.wikipedia.org/wiki/ISO_8859-1
[2] http://en.wikipedia.org/wiki/UTF-8
O algoritmo LZ-77 é totalmente insensível a estas questões de codificação. Ele não enxerga caracteres acentuados ou não, mas apenas bytes.
Portanto, é possível que seu programa de compressão esteja funcionando corretamente, mas ao examinar o arquivo gerado você está usando um programa que presume uma codificação diferente daquela usada quando o arquivo foi criado. Experimente usar o xxd ou o Firefox.
--
Luciano
Como o Luciano explicou, isso não deveria ser um problema. Embora o enunciado do EP use como exemplo um arquivo de texto, o algoritimo LZ77 não requer que os arquivos sejam de texto. Ou seja, se você fizer tudo certo, seu programa funcionará para arquivos quaisquer (de texto ou não). Assim sendo, o fato de um arquivo conter caracteres com acento é irrelevante. O importante é que o arquivo descomprimido seja idêntico ao original.
Quando digo que seu programa deve funcionar para arquivos quaisquer, quero dizer que deve ser possível você usá-lo para "comprimir" um arquivo que não é de texto (um arquivo executável, por exemplo) e para descomprimir o arquivo comprimido. A descompressão deve produzir um arquivo exatamente igual ao original. Acima coloquei aspas em "comprimir" porque para arquivos que não sejam de texto o LZ77 tenderá a gerar arquivos "comprimidos" maiores que os arquivos originais. (Claro que isso vai depender do conteúdo de cada arquivo e pode também acontecer para arquivos de texto.)
Quando digo que seu programa deve funcionar para arquivos quaisquer, quero dizer que deve ser possível você usá-lo para "comprimir" um arquivo que não é de texto (um arquivo executável, por exemplo) e para descomprimir o arquivo comprimido. A descompressão deve produzir um arquivo exatamente igual ao original. Acima coloquei aspas em "comprimir" porque para arquivos que não sejam de texto o LZ77 tenderá a gerar arquivos "comprimidos" maiores que os arquivos originais. (Claro que isso vai depender do conteúdo de cada arquivo e pode também acontecer para arquivos de texto.)