Interpretação De Caracteres

[Ricardo Timm Bonsembiante]

Olá pessoal

 

Estou com o problema abaixo apresentado e gostaria da ajuda de vocês para resolvê-lo. O problema são os caracteres acentuados gerados no arquivo SAI.TXT que não estou sabendo como resolver. Vejo como saída uma tabela para que eu possa fazer a conversão ou alguma outra que não descobri.

Se abro com o NOTEPAD por exemplo em ambos os casos ele trata os caracteres acentuados da mesma forma, agora se leio o arquivo no meu programa não. Alguém pode me ajudar?

>type sai.txt
ERRO: Impressora Daruma não está em linha

---> Arquivo SAI.TXT gerado usando ACBRMonitor 0.9.24.3 ACBr 0.9.0a <---

>type x.txt
ERRO: Impressora Daruma MFD nÒo estß em linha

---> Arquivo SAI.TXT gerado usando ACBRMonitor 0.8.4b ACBr 0.8.7b <---

[]s,

SAI.TXT

x.TXT

[Daniel Simoes]

O SAI.TXT está em UTF8 (sem BOM)

 

enquanto o X.TXT está em ANSI

 

Usei o NotePad++ para descobrir...

 

você diz que o SAI.TXT foi gerado pelo ACBrMonitor e está sempre sendo gerado em UTF8 ?

[Ricardo Timm Bonsembiante]

Daniel

 

Exatamente, só que o SAI.TXT com a versão 0.9.24.3 e o X.TXT com a versão bem antiga 0.8.4b.

[Daniel Simoes]

O Lazarus usa por padrão o UTF8, o que é bom em alguns aspectos, pois evita a confusão de páginas de código...

 

Porém compreendo que é difícil para algumas linguagens abrir arquivos UTF8, ou converte-los para ANSI...

 

Vou adicionar um parâmetro no ACBrMonitor  que permita configurar os arquivos de entrada e saida para ANSI ou UTF8

 

Já tentou a comunicação por Sockets ? é muito mais rápida... há um exemplo em Cobol que é distribuído junto com o ACBrMonitor

[Ricardo Timm Bonsembiante]

Daniel

 

Te agradeço muito. Quanto a usar Sockets é o que quero fazer logo em seguida, pois aqui no meu ambiente de desenvolvimento tenho vários computadores que acessam a mesma impressora fiscal e tenho que ficar trocando o cabo cada vez que um usa. Tentei fazer com a troca de arquivos txt, mas teria que mudar bastante a lógica da minha automação. Foi nesse troca troca que percebi esse problema.

 

Obrigado, um abraço e um ótimo final de semana.

[Daniel Simoes]

Apliquei uma modificação no ACBrMonitor e ACBrMonitorConsole que devem permitir a conversão:

 

 

O Isaque deve compilar essa versão em breve, e subir para a área de Downloads do SAC

http://www.projetoacbr.com.br/forum/index.php?/files/category/1-utilit%C3%A1rios-acbrsac/

[Ricardo Timm Bonsembiante]

Daniel

 

Obrigado mesmo. Te devo mais essa.

 

Um abraço,

[Ricardo Timm Bonsembiante]

Daniel

 

Já tinha considerado como resolvido esse tópico, mas somente agora percebi que existe um probleminha nessa conversão. Veja bem: quando converte um carácter normal, não acentuado, sem problema "a" (61 em UTF-8) converte legal para ANSI. No caso dos caracteres acentuados e ç eles são double-byte (á = x"C3A1") e a conversão desloca (ou perde) uma posição na resposta:

 

ECF.CarregaFormasPagamento (UTF-8)

OK: 01   Dinheiro                      |02  VCredißrio                    |

 

Observe que a primeira forma de pagamento, que não possui acentuação, o tamanho da descrição da forma de pagamento é de 30 caracteres. Na segunda, que tem um carácter acentuado, são apenas 29. Como eu pego campos de tamanho fixo isso acarreta problema. Tem como resolver?

 

Aguardo retorno.

[Daniel Simoes]

Vc deve converter a SAIDA para ANSI... só assim o tamanho seria fixo

 

O ideal mesmo é evitar qualquer tipo de acentos no ECF...

[Ricardo Timm Bonsembiante]

Daniel

 

Eu marco o arquivo de saída, só que quando ele faz a conversão, converte 2 bytes em um, "puxando" o resto todo. Já avisei meus clientes para evitar ç e caracteres acentuados nas formas de pagamento e comprovantes não fiscais, mas esse, no caso, teria que fazer uma intervenção técnica para resolver. Se não tiver um jeito pelo ACBrMonitor, vou ter que ver como fazer pela AC.

 

Um abraço,

[Daniel Simoes]

O arquivo de Saída fica em ANSI, porém com 29 caracteres (ou menos) na descrição, certo ?

 

Acredito que o problema ocorra porque a conversão é feita apenas no Final, após montar todo o arquivo...

 

Preciso analisar com calma e verificar se há solução... 

 

Do lado da sua aplicação, vc poderia usar o caractere pipe, para identificar a quebra de linha... nesse caso, o tamanho da String não faria diferença...

[Ricardo Timm Bonsembiante]

Daniel

 

Fiz um paliativo na AC. Se encontrares uma solução melhor.

 

Grato e um abraço,