Input is not proper UTF-8, indicate encoding ! Bytes: 0xE7 0xE3 0x6F 0x20

[xandebugmann]

Sim, troquei as units e refiz a instalação do ACBr, e no meu caso ainda continuou o problema.

[MGWareDev]

Com a correção do @Daniel Simoes, cotinuou o mesmo problema.

 

Com a correção do @Diogo Loff funcionou. 

 

Testamos em Capão da Canoa/RS e Santa Cruz do Sul/RS

[Diogo Loff]

Acabei de Testar em Produção

Criciúma/SC, Cocal do Sul/SC e Faxinal dos Guedes/SC a correção @Daniel Simoes não deu certo, mantive a que eu indiquei no forum.

A versão do Delphi que utilizo é a 10.3.3 Rio.

[Patrick Knopf]

Mesma situação aqui pra mim. Correção do @Diogo Loff deu certo. 

[EMBarbosa]

3 horas atrás, Diogo Loff disse:

Acabei de Testar em Produção

Criciúma/SC, Cocal do Sul/SC e Faxinal dos Guedes/SC a correção @Daniel Simoes não deu certo, mantive a que eu indiquei no forum.

A versão do Delphi que utilizo é a 10.3.3 Rio.

Muito obrigado pela rápida resposta.

Poderia testar com essas outras duas, por favor?

PadraoNacional.Provider.pasACBrXmlDocument.pas

[Diogo Loff]

Eu tive que parar de mexer nisto antes, agora a noite vou dar mais uma trabalhada, vejo se consigo testar e te reporto.

[Anderson Mendes]

Boa noite!

Hoje pela manhã eu respondi em outros tópicos, tanto no privado quanto no público, mas ambos foram fechados. Vou compartilhar com você pela última vez, caso alguém queira testar. Para mim, está tudo funcionando.

Se é a melhor solução, eu não sei. Mas precisamos de uma solução urgente, mesmo que paliativa, para depois fazermos melhorias. Antes tudo funcionava, porém o código foi comentado e nada foi adicionado para substituí-lo. Se houver algum efeito colateral, basta adicionar um IF para não impactar os demais.

Ressalto que não descomentei nada; apenas reescrevi o que já estava comentado, porém de outra forma, e foi isso que resolveu para mim e está funcionando!

1. Com o ACBr já instalado, apenas substitua a unit ""C:\ACBr\Fontes\ACBrDFe\ACBrXmlDocument.pas"
2. Recompile o projeto "C:\ACBr\Pacotes\Delphi\ACBrDFe\ACBr_DFeComum.dpk "
3. Reinstale o ACBr e pronto, ja pode testar.

ACBrXmlDocument.pas

[Diogo Loff]

@EMBarbosa não deu certo.

Recomendo avaliar a adequação que sugeri, onde na questão de recuperar o arquivo e alimentar o arquivo para salvar, não seja feito nenhum tipo de manipulação de String, manipular binario é sempre bronca.

@Anderson Mendes peguei o seu arquivo e comparei com o atual, no seu tem várias questões descomentas que consomem muita CPU, então peguei somente procedure TACBrXmlDocument.LoadFromXml(AXmlDocument: AnsiString); e vi que na sua a linha loadedDoc := xmlParseDoc(PAnsiChar(UTF8String(AXmlDocument))); esta desta forma. Na atual esta sem UTF8String então adicionei e testei, e também não funciona.

Os fontes meus são de 16/02/2026.

Eu bato na tecla que não se deve ficar manipulando Binario em String, mesmo que em Base64. Tem que pegar decodar ele e manter como esta, se não é loteria, pode ser que para um funcione para outro não.

Eu não sei se tem algum código que impede de funcionar em versões mais antigas de Delphi ou então de Lazarus. Se não tive, acho que a solução é certeira boto minha mão no fogo haha.

Que é
NFSeXml := Document.AsString['nfseXmlGZipB64']; // Carrega como esta

NFSeXmlFile := DeCompress(DecodeBase64(NFSeXml)); // Somente descomprime em outra variavel

// Testa se é UTF8 e faz o que tivez que fazer com a variavel string, pois pelo que vi no fonte é ela que é utilizada no geral para tratamentos
if IsUTF8String(NFSeXmlFile) then
    NFSeXml := UTF8ToAnsi(NFSeXmlFile)
else
    NFSeXml := NFSeXmlFile;

DocumentXml.LoadFromXml(NFSeXmlFile); // Só que este cara aqui que vai carregar o documento para salvar depois, mantem ele com a string do binario de forma original, sem mofificações, o erro inclusive do encoding ocorre aqui neste exato ponto, porque acaba alguma coisa modificando e gerando mal formação no arquivo.

Venho desde a sexta passada mexendo nisto e olha que já testei muita nota fiscal e tudo em ambiente de produção nestes dias, e desde que mexi nesta rotina, não tive mais nenhum problema de encoding, e todos os dados com caracteres especíais estão ficando corretos.

[Daniel Simoes]

AnsiSrting é um String Binário...

Nossa preocupação em editar uma Unit "core" do ACBr, é que pode interferir em outros DFes que estão funcionais

@Juliana Tamizou, precisamos de credenciais para testar em uma das cidades que apresenta o problema, para nosso próprio time reproduzir 

 

[Rodrigo Crovador]

@EMBarbosa @Daniel Simoes @Diogo Loff

Acredito que o problema tem ocorrido especificamente com o unit do provedor nacional. Especificamente no tratamento do retorno da consulta da NFSE por chave, o retorno está sendo convertido propositalmente logo após a descompressão, o que aparentemente "mata" o String binário do AnsiString e compromete o UTF8. 

        if NFSeXml <> '' then
          NFSeXml := DecodeToString(DeCompress(DecodeBase64(NFSeXml)), true);

Este é o único método dessa maneira. os demais não fazem a conversão (Emitir é um exemplo, a linha está comentada):

      if NFSeXml <> '' then
      begin
//        NFSeXml := DecodeToString(DeCompress(DecodeBase64(NFSeXml)), True);
        NFSeXml := DeCompress(DecodeBase64(NFSeXml));
        LerNFSe(NFSeXml);
      end;

Aqui tenho usado sem a conversão e tem funcionado sem problemas. O pessoal comenta que "estraga" os acentos, mas isso é apenas no DEBUG da IDE: as propriedades do compoenente carregam os valores devidamente codificados e os métodos "Salvar" também geram arquivos corretos. 

Se há um ponto que talvez necessite deste tratamento, seria no XML do respose (não apliquei na unit em anexo):

Response.XmlRetorno := DecodeToString(NFSeXml);

Poderiam validar isso?
 

PadraoNacional.Provider.pas

[Diogo Loff]

Sim @Rodrigo Crovador a conversão ali quebra o arquivo, não converter também pode ser uma solução mais simples. No que eu fiz é a mesma coisa só que para manter a conversão eu dupliquei a variavel que salva pro arquivo sem converter, mas é bem isto ai que você ta falando, e fica tudo certo mesmo, os arquivos não ficam errados, eu testei muitos aqui e nenhum XML ficou com caracteres trocados.

[EMBarbosa]

10 horas atrás, Diogo Loff disse:

if IsUTF8String(NFSeXmlFile) then

Essa função foi introduzida no Delphi XE2, se não me engano. Ou seja, não podemos utilizar já que, no nosso caso, precisamos manter a compatibilidade com versões anteriores do delphi (XE, 2010, 2009, 2007 e 7).

46 minutos atrás, Rodrigo Crovador disse:

Este é o único método dessa maneira. os demais não fazem a conversão (Emitir é um exemplo, a linha está comentada):

Sim... nós já detectamos isso. Inclusive, foi o comentário que eu fiz no tópico relacionado do Diogo Loff.

Estamos fazendo testes para validar a remoção do DecodeToString() antes de enviar ao SVN. Nosso amigo @Diego Folieneestá ajudando com respeito a isso. Acredito que ainda hoje vamos enviar uma alteração nesse respeito.

Vai ser preciso depois avaliar mais profundamente esse caso, mas aí vamos criar testes.

48 minutos atrás, Rodrigo Crovador disse:

Se há um ponto que talvez necessite deste tratamento, seria no XML do respose (não apliquei na unit em anexo):

Response.XmlRetorno := DecodeToString(NFSeXml);

Poderiam validar isso?

Essa parte eu não sei se entendi direito. Pode explicar melhor?

[Rodrigo Crovador]

4 minutos atrás, EMBarbosa disse:

Essa parte eu não sei se entendi direito. Pode explicar melhor?

Diferente do restante, esta propriedade do retorno não é tratada e permanece em UTF8, ou seja, o desenvolvedor tem que trata-la em sua aplicação:

Acho (bem no achismo mesmo) que esse foi o motivo de terem adicionado a decodificação em algum momento. Se for esse o caso, tratar apenas este ponto seria um caminho de atender ambos. Aqui no meu caso não utilizo, mas fica a quem precisar. 

 

[Anderson Mendes]

@Diogo Loff

Bom dia

Você precisa fazer exatamente como está descrito aqui.
Se tentar instalar somente o “DCLACBr_DFeComum.dpk”, ele não aplica as modificações. Não sei o motivo, mas perdi horas até descobrir isso.

1.     Atualize os fontes sem qualquer modificação e instale o ACBr.
2.     Substitua o trecho "loadedDoc := xmlParseDoc(PAnsiChar(AXmlDocument));" por "loadedDoc := xmlParseDoc(UTF8String(AXmlDocument));" na Unit ACBrXmlDocument.
3.     Abra o Delphi e Recompile o projeto "C:\ACBr\Pacotes\Delphi\ACBrDFe\ACBr_DFeComum.dpk" e fecha o delphi
4.     Reinstale o ACBr usando o próprio instalador "ACBrInstall_Trunk2.exe" e pronto, já estará funcionando.

 

Editado 18 Fevereiro por Anderson Mendes

[Diego Foliene]

Boa tarde a todos!

Foi enviado na Rev-44909 ajuste removendo a DecodeToString da unit do Padrão Nacional.

Por favor, atualizem seus fontes, reinstalem o ACBr com a opção "Apagar Arquivos Antigos" marcada no instalador e façam novos testes.

 

[Diego Foliene]

Olá pessoal!

Foi gerada nova compilação da LibNFSe e do ACBrMonitorPLUS que englobam essas alterações.

Caso utilize um dessas soluções, por favor, atualize para realizar novos testes.

[EMBarbosa]

5 horas atrás, Anderson Mendes disse:

Você precisa fazer exatamente como está descrito aqui.
Se tentar instalar somente o “DCLACBr_DFeComum.dpk”, ele não aplica as modificações. Não sei o motivo, mas perdi horas até descobrir isso.

Na verdade, pode não ser uma boa ideia rodar instalação de só alguns desses pacotes.

Talvez precise rodar a instalação de todos novamente e por isso sugerimos rodar o ACBrInstall.

A explicação do motivo é a opção "Deixar somente a LibXX", como o Daniel explicou:

Em 13/02/2026 at 16:40, Daniel Simoes disse:

Mas se ele instalou o ACBr, com a opção "Deixar somente a LibXX..."  então ele precisará rodar novamente o instalador...

Em 13/02/2026 at 16:51, Daniel Simoes disse:

Mas se instalou com essa opção desmarcada... então o Delphi conhece os "Paths" de todos os fontes do ACBr, e consegue recompila-los, sob demanda

 

 

[carlos_tedex]

Bom dia,

Fiz a atualização/instalação do componente hoje e tudo funcionou 100%

Provedor: SilTecnologia
Cidade: Vila Velha/ES

[FelipeMitt]

Resolveu, pessoal?

Tentei realizar uma consulta de NFSe por chave e deu esse erro Input is not proper UTF-8, indicate encoding ! Bytes: 0xE2 0x6E 0x64 0x69.

[mregiani]

@FelipeMitt, eu atualizei repositório, recompilei todos os pacotes marcando a opção de excluir arquivos antigos e deu tudo certo para o provedor nacional.

[EMBarbosa]

4 horas atrás, FelipeMitt disse:

Resolveu, pessoal?

Tentei realizar uma consulta de NFSe por chave e deu esse erro Input is not proper UTF-8, indicate encoding ! Bytes: 0xE2 0x6E 0x64 0x69.

É preciso seguir os passos citados:

Em 18/02/2026 at 14:52, Diego Foliene disse:

Por favor, atualizem seus fontes, reinstalem o ACBr com a opção "Apagar Arquivos Antigos" marcada no instalador e façam novos testes.

 

[Serialtec]

Bom dia, fiz os testes aqui e funcionou normalmente também.

[RRiquena]

Boa tarde. Fontes Atualizados hj. Componente reinstalado.

Os Xml(s) estão sendo salvos dessa forma: 

<xLocIncid>Tupã</xLocIncid>

<xTribNac>Lubrificação, limpeza, lustração, revisão, carga e recarga, conserto, restauração, blindagem, manutenção e conservação de máquinas, veículos, aparelhos, equipamentos, motores, elevadores ou de qualquer objeto (exceto peças e partes empregadas, que ficam sujeitas ao ICMS).</xTribNac>

<xNBS>Serviços de manutenção e reparação de veículos rodoviários motorizados</xNBS>

 

Editado 5 Março por RRiquena

[RRiquena]

Provedor: Simpliss

[ActioSistemas]

Bom dia, alguém na mesma situação com o problema de caracter persistente?

Embarcadero® Delphi 10 Seattle Version 23.0.20618.2753