[Download da NFe pelo comando docZip.Items[i].XML retornando caractere desformatado por causa de acento]

entendo, porém aqui funcionou.

Este link que vc me mandou é de 2007. Naquela época não existiam os delphis mais novos com modificações de Strings.

[]s

 

dá uma olhada neste post, transcrevi aqui deste link (https://pt.stackoverflow.com/questions/51308/diferença-entre-ansistring-widestring-unicodestring-shortstring-e-string-e-com)

• AnsiString: string composta por caracteres ASCII. Cada Char possui exatamente 1 bytes. Um ponteiro para uma AnsiString (^AnsiString) equivale a char* em C;

• WideString: existe apenas por compatibilidade com o Windows. Cada Char possui 2 bytes, e deve ser utilizada em funções da Win32 com parâmetros LPWSTR, realizando um cast para PWChar;

• UnicodeString: string unicode. Por padrão UTF-16 (ou pelo menos era quando pesquisei pela última vez), mas pode assumir outras codificações, como UTF-8.

• ShortString: equivale a string antiga do Pascal, com sua limitação de de 255 caracteres.

• String: nas versões mais novas do Delphi (2007 em diante), equivale a UnicodeString. Antigamente equivalia a AnsiString.

Tanto AnsiString quanto UnicodeString são mais do que um simples array of Char, sendo que elas possuem informações de página de código e tamanho. Porém, para facilitar o cast destes tipos para PChar e suas variações, estas informações ficam nos endereços anteriores ao retornado pelo operador @.

Conversão

A conversão entre elas é feita automaticamente. Único cuidado que deve ser tomado, é que dados podem ser perdidos durante a conversão devido ao tipo não suportar alguma característica da string de origem.

Por exemplo, converter UnicodeString para AnsiString, pode haver perda devido aos caracteres Unicode poderem ocupar mais que 1 byte.

Conversão de AnsiString (ou UnicodeString) para ShortString, haverá perda de dados se a string de origem for maior que 255 (Length(origem) > 255).

 

[Download da NFe pelo comando docZip.Items[i].XML retornando caractere desformatado por causa de acento]

boa tarde Daniel

a descompressão está correta, porém as funções Unzip e Decompress trabalham com  AnsiString como parâmetro.

O xml veio correto se trocar tais funções por:

unit ACBrUtil;

function UnZipW(const ABinaryString: String): String; overload;
var
  strAux: TStringStream;
begin
  strAux := TStringStream.Create(ABinaryString);
  try
    strAux.Seek(0, soFromBeginning);
    Result := ACBrCompress.DeCompressW(strAux);
  finally
    strAux.Free;
  end;
end;

unit ACBrCompress;

function DeCompressW(AStream: TStream): String;
var
  outMemStream: TMemoryStream;
begin
  outMemStream := TMemoryStream.Create;
  try
    AStream.Position := 0;
    DeCompress(AStream, outMemStream);

    outMemStream.Position := 0;
    with TStringStream.Create('', TEncoding.UTF8) do
    try
      CopyFrom(outMemStream, outMemStream.Size);
      Result := DataString;
    finally
      Free;
    end;
  finally
    outMemStream.Free;
  end;
end;

--------------------------------

Na unit pcnRetDistDFeInt, troque a linha

FdocZip.Items.FInfZip := UnZip(StrDecod);

para

FdocZip.Items.FInfZip := UnZipW(StrDecod);

---------------------------------

Obs: É apenas uma sugestão de codificação.

 

 

 

 

 

 

 

 

[Download da NFe pelo comando docZip.Items[i].XML retornando caractere desformatado por causa de acento]

1 hora atrás, Daniel Simoes disse:

Acabo de enviar uma possível correção ao SVN...  Por favor atualize os fontes, e teste novamente...

olá Daniel

obrigado pelas respostas.

Como vc disse, entendo que "zipar", "deszipar" não altera o encoding do arquivo.

Porém, se eu subo o arquivo zip para um site que descompacta online, por exemplo: http://online.b1.org/online , o arquivo vem com a codificação correta.

Acabei de testar sua solução porém continua dando o mesmo erro. Estou anexando novamente o xml, resultante da sua alteração, para vc avaliar melhor.

Observe que o cabeçalho <?xml version="1.0" encoding="UTF-8"?> foi inserido desta vez, porém o arquivo continua com problema no nó:

<infCpl>*Conf. Arts. 465 a 469 do RICMS/SP, aprovado pelo Decreto 45.490/00*Não incidência do ICMS conf. Art.7 Inciso XIII do RICMS 45.490/00</infCpl>

 

obrigado pela ajuda.

 

 

000000000055725.xml

[Download da NFe pelo comando docZip.Items[i].XML retornando caractere desformatado por causa de acento]

Em 19/03/2018 at 12:25, Emerson Teixeira disse:

om dia ..

tentei usar função ConverteXMLtoNativeString, mas ainda não funcionou.

o estranho é que se eu abrir o xml pelo stringlist do delphi, funciona.

Ex: 

xml :TStringlist;

xml := TStringlist.create;

xml.LoadFromFile('Arquivo.xml', TEnconding.UTF8);

 

Se abrir o xml no i.e. mostra tudo certo, com acentos, mas ao abrir este mesmo arquivo pelo ACBrNFe1.NotasFiscais.LoadFromFile('Arquivo.xml'), fica com caracteres estranhos ex: APÓS SERVIÇO DE CALIBRAÇÃO  (APÓS SERVIÇO DE CALIBRAÇÃO)

 

att.

bom dia

este problema persiste, alguém conseguiu resolver este problema?

Fiz as seguintes constatações que talvez possam ajudar na resolução deste problema:

no método function TRetDistDFeInt.LerXml: boolean;, interceptei a string decodificada no padrão zip e a salvei em um arquivo.

Quando passa pela linha abaixo:

FdocZip.Items.FInfZip := UnZip(StrDecod);

o arquivo zip já está com problemas de encoding, porém se pego este arquivo e descompacto via 7-zip, por exemplo, o mesmo fica com a codificação correta.

Logo, concluo que o problema está na ferramenta de descompactação. Atualizei pelo site http://synapse.ararat.cz/doku.php/download porém o problema persiste. Meu próximo teste seria encontrar uma ferramenta no delphi que descompacte corretamente o xml do zip.

Os desenvolvedores do ACBR podem nos ajudar neste sentido?

Agradeço antecipadamente.

 

 

 

 

 

 

 

 

000000000055725.zip

000000000055725-ComErrodeCodificação.xml

000000000055725-Correto.xml