[ACBR-8790] NFSeX – Provedor Nacional: Correção de Acentuação e Charset UTF-8 (Mojibake) no Delphi 2009+ com Compatibilidade Lazarus

[Marcos Nielsen]

Descrição do problema

Foi identificado um problema recorrente na transmissão e recuperação de XML (e conteúdos textuais retornados, inclusive estruturas convertidas para XLS/relatórios) no NFSeX – Provedor Nacional, onde ocorre erro de acentuação e corrupção de caracteres.

<infNFSe Id="NFS41282032204580454000130000000000002626012373413140">
  <xLocEmi>Uni?o da Vit?ria</xLocEmi>
  <xLocPrestacao>Uni?o da Vit?ria</xLocPrestacao>
  <nNFSe>26</nNFSe>
 

<infNFSe Id="NFS41282032204580454000130000000000002626012373413140">
  <xLocEmi>Uni?o da Vit?ria</xLocEmi>
  <xLocPrestacao>Uni?o da Vit?ria</xLocPrestacao>
  <nNFSe>26</nNFSe>
  <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 sistemas de seguran?a</xNBS>
  <verAplic>SefinNacional_1.5.0</verAplic>
  <ambGer>2</ambGer>
  <tpEmis>1</tpEmis>
  <procEmi>1</procEmi>
  <cStat>100</cStat>
  <dhProc>2026-01-12T19:56:19-03:00</dhProc>
  <nDFSe>53116</nDFSe>
  <emit>

A causa principal está no fato de que, em diversos pontos do código do ACBr, existem conversões implícitas de tipos (string, AnsiString e UTF-8).
Esse comportamento não gera erro aparente no Lazarus/FPC, pois nesse ambiente o tipo string já é UTF-8 por padrão.

Entretanto, no Delphi 2009+ (Unicode), essas conversões implícitas passam a ser críticas, resultando em:

• UTF-8 interpretado como ANSI

• Dupla conversão de encoding

• Mojibake (acentuação quebrada)

• Perda de caracteres tanto no envio quanto no retorno do processamento

Observação importante

Esse problema já foi reportado diversas vezes pela comunidade.
Historicamente, a solução sugerida tem sido habilitar a opção de “remover acentos” nos textos enviados.

No entanto, essa não é uma solução correta.
A acentuação em UTF-8 é plenamente aceita, não possui qualquer restrição no layout e é inclusive utilizada internamente pelo servidor da NFSe Nacional.

Remover acentos apenas mascara o problema, elimina informação válida do texto e não resolve a causa real, que é o tratamento incorreto de charset no código.
Portanto, o problema precisa ser resolvido na origem, com a correção adequada dos fontes e do fluxo de encoding.

Esse cenário afeta diretamente:

• Envio do XML da NFSe

• Retorno das mensagens do webservice

• Textos livres (descrições, observações, mensagens de erro)

• Conteúdos recuperados e posteriormente exportados/visualizados (ex.: XML → XLS)

Diante disso, tornou-se necessária a correção dos fontes, eliminando conversões implícitas e garantindo tratamento explícito de UTF-8.

---

Adequação realizada

Foi realizada uma adequação no código da NFSe – Padrão Nacional, com foco em Delphi 2009+, corrigindo problemas de acentuação e encoding decorrentes do uso incorreto de AnsiString em fluxos que exigem UTF8String.

A correção é indispensável porque o servidor da NFSe Nacional exige que todo o conteúdo enviado esteja obrigatoriamente em UTF-8, incluindo:

• XML principal

• Mensagens de troca com o webservice

• Textos livres (descrições, observações, mensagens de erro, etc.)

Antes do ajuste, parte do código realizava conversões implícitas ou indevidas entre string, AnsiString e UTF-8, ocasionando mojibake (conteúdo UTF-8 interpretado como ANSI), com impacto direto na acentuação tanto no envio quanto no retorno do processamento.

---

O que foi corrigido

• Padronização do tratamento de dados textuais enviados ao webservice como UTF8String

• Eliminação de conversões implícitas que causavam dupla interpretação de encoding

• Correção de pontos críticos de:

  • Compressão e descompressão

  • Gravação e leitura de arquivos

  • Manipulação de XML

  • Comunicação HTTP

• Garantia de retorno correto dos caracteres acentuados após o processamento

• Correção dos dados recuperados, evitando erros de acentuação em exportações e visualizações (ex.: XML/XLS)

---

Compatibilidade

A solução mantém total compatibilidade com:

• Lazarus / FPC (onde string já é UTF-8)

• Delphi antigo (pré-Unicode)

• Delphi Unicode (2009+)

Foram utilizadas diretivas de compilação para assegurar o comportamento correto em cada ambiente, sem impacto regressivo.

---

Arquivos alterados

Os seguintes arquivos foram modificados para aplicar a correção de encoding e eliminar problemas de mojibake:

ACBrXmlDocument.pas

PadraoNacional.Provider.pas

ACBrNFSeXWebserviceBase.pas

ACBrDFeXsLibXml2.pas

ACBrDFe.pas

ACBrUtil.XMLHTML.pas

ACBrUtil.Strings.pas

ACBrUtil.FilesIO.pas

ACBrCompress.pas

---

Estou disponibilizando os arquivos corrigidos, juntamente com o resultado do processamento após a correção, para validação técnica e compartilhamento com a comunidade.

exemplo do funcionamento da correção

Logs.7z

[Marcos Nielsen]

Pedido à comunidade

Esse problema de acentuação / charset UTF-8 no NFSeX – Provedor Nacional já foi relatado diversas vezes e afeta principalmente ambientes Delphi 2009+.

Peço, por gentileza, que os usuários que enfrentam o mesmo erro:

• Testem as alterações propostas

• Confirmem a correção do envio e do retorno da NFSe com acentuação UTF-8 correta

• Marquem aqui nos comentários caso também tenham esse problema

A participação de vocês ajuda a demonstrar que o erro é recorrente e reforça a necessidade de commit da correção nos fontes, eliminando definitivamente paliativos como a opção de “remover acentos”.

Obrigado a todos pela colaboração.

[Desenv Prevedello]

Boa noite, 

  No meu caso até não tenho problemas em remover a acentuação ao Gerar o DPS. Porém, ao capturar o XML para armazenar no database através da property ACBrNFSeX.NotasFiscais.Items[0].XmlNfse está com problemas nas acentuações como por exemplo na tag xTribNac.

Obs.: O XML da NFSe salvo no diretório está com os caracteres corretos.

Obrigado a todos pela colaboração.

[Marcos Nielsen]

Na prática, o problema é bem mais amplo.
Ao consultar os XMLs gerados pelo ACBrNFSeX no Recebedor Nacional, continuam surgindo caracteres inválidos, mesmo com a opção remover acentos habilitada.

A transmissão utilizando codepage diferente de UTF-8 gera inconsistências no próprio provedor nacional, que passa a retornar a NFSe com erro.

Como consequência, o XML da nota fiscal apresenta diversos problemas de acentuação, impedindo a importação correta pelos sistemas de contabilidade. No final, esses erros acabam sendo atribuídos aos sistemas emissores.

É importante reforçar que esse comportamento está diretamente relacionado ao Delphi, que não utiliza string UTF-8 nativa, diferentemente do Lazarus, onde as strings já são UTF-8 por padrão. A falta de conversão explícita para UTF-8 no Delphi é a causa raiz do problema.
 

 

[Diego.Foliene]

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn.

Tarefa ACBR-8790

[giovani deitos]

to com este problema também

[PbNew_Sistemas]

Bom dia,

   Giovani, se o problema estiver ocorrendo no momento de armazenar o XML no banco de dados, é possível aplicar uma solução temporária semelhante à que utilizei. Antes de gravar o XML, faço a conversão para string, por exemplo:

_XmlNFSe := DecodeToString(ACBrNFSeX.NotasFiscais.Items[0].XmlNfse, True);

Assim não se faz necessário alterar o componente neste momento, até porque tem tópicos falando sobre esse assunto na questão de fazer o load. Tem até algumas sugestões, mas achei melhor fazer assim neste momento, para não comprometer outros modelos de nota.

[Marcos Nielsen]

Em 15/01/2026 at 10:40, Diego Foliene disse:

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn.

Tarefa ACBR-8790

Obrigado @Diego Foliene

Sei que essa alteração é complexa e impacta muito no ACRBr.

Ainda assim, caso seja útil para vocês, fico totalmente à disposição e me comprometo a ajudar no que for necessário durante a validação ou implementação.

Segue meu Discord para contato direto.

Marcos.Nielsen

[Daniel Simoes]

A proposta parece alterar Units demais do ACBr...

O ACBr já lida corretamente, com acentuação em UTF8, nos Documentos NFe/NFCe.. então creio que o problema esteja isolado nas Units do ACBrNFSeX

@Diego Foliene, como podemos, de forma simples, reproduzir o problema, usando o Demo do ACBr ?

 

[Rodrigo Crovador]

Tive um problema semelhante com um provedor que utiliza o padrão nacional. O que identifiquei na época é que a função Decompress da unit ACBrCompress retorna o conteúdo do XML em Ansi, o que pode comprometer a conversão para UTF8 posteriormente: 

function DeCompress(const ABinaryString: AnsiString): AnsiString;
var
  MS: TMemoryStream;
begin
  MS := TMemoryStream.Create;
  try
    WriteStrToStream(MS, ABinaryString);
    MS.Position := 0;
    Result := DeCompress(MS);
  finally
    MS.Free;
  end;
end;

A solução que adotei foi mudar o retorno desta função para WideString e adaptar as demais responsáveis pela conversão para WideString também. (DecodeToString e UTF8ToNativeString, ambas da ACBRUtils.Strings). Desta maneira não tive mais problemas com a conversão (Delphi 10.3). Não sei o impacto quanto as demais versões. Talvez atenda a situação com um impacto menor.

[Daniel Simoes]

AnsiString, é um "String Binário".. ele aceita caracteres de Controle como #0, #13, #10, etc

o WideString, é um UTF16, cada caracter, irá sempre ocupar 2 bytes

https://www.freepascal.org/daily/doc/prog/progsu162.html

O problema, pode ocorrer, quando você converte AnsiString para String...

Exemplo, se ler um Stream do BD, e jogar ele em uma String do Delphi... pode realmente dar problemas... 
mas funcionaria, ler de um Stream, e jogar para um AnsiString

[mregiani]

Eu estou com mesmo problema, carrego um XML clicando no botão "Imprimir DANFSe" no projeto ACBrNFSeX_Exemplo usando o componente ACBrNFSeXDANFSeFR (fast) com o arquivo DANNSEPADRAO.FR3

<?xml version="1.0" encoding="UTF-8"?>
<NFSe xmlns="http://www.sped.fazenda.gov.br/nfse" versao="1.01">
    <infNFSe Id="NFSxxxxxxxxxxxxxx">
        <xLocEmi>Votuporanga</xLocEmi>
        <xLocPrestacao>Votuporanga</xLocPrestacao>
        <nNFSe>207</nNFSe>
        <cLocIncid>3557105</cLocIncid>
        <xLocIncid>Votuporanga</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 outros maquinários e equipamentos não classificados em subposições anteriores</xNBS>
        <verAplic>SefinNacional_1.6.0</verAplic>
        <ambGer>2</ambGer>
        <tpEmis>1</tpEmis>
        <procEmi>1</procEmi>
        <cStat>100</cStat>
 

Do jeito que está o conteúdo do xTribNac vai para o DANFSE com acentuação errada.

[Daniel Simoes]

parece ser um problema diferente... mais relacionado as Units do Fast Report...

Poderia por favor, criar um novo tópico ?