Ao baixar o xml via webservice na url https://sefin.nfse.gov.br/sefinnacional/nfse/{chave}, observei que o arquivo está sendo baixado com aplicação duplicada de codificação UTF-8.
Mais alguém com esse problema?
1 curtida
Também já peguei esse tipo de situação.
Em alguns casos o XML vem com double encoding (UTF-8 aplicado duas vezes) e, em outros, já recebi retorno com o conteúdo codificado duas vezes em Base64, sendo necessário fazer duas decodificações para chegar no XML válido.
1 curtida
Estou passando um aperto aqui. O arquivo baixado durante o envio da DPS (criação da NFS) veio com a codificação atrapalhada. Duplo utf8_encode, talvez. Pior, não passa na verificação de assinatura, já que o Digest não bate, basicamente é uma nota inválida.
Se eu baixar o XML do Portal do Contribuinte, tudo maravilhoso e funcional (utf-8 direitinho e tal).
Hoje eu uso uma rotina para entrar no Portal do Contribuinte e baixar o Danfe, já que a API do Danfe, mais uma vez, está fora do ar (erros 502 e 503 alternados). Talvez serei obrigado a usar o mesmo “recurso” para baixar o XML correto, já que a API está com defeito. O ideal seria o item “nfseXmlGZipB64” na resposta do método GET https://sefin.nfse.gov.br/SefinNacional/nfse/{ChaveDeAcesso} fornecer o xml correto, compactado com gzip e codificado em base 64. Infelizmente, o arquivo vem “corrompido”. Será que no método de gerar a NFS (POST https://sefin.nfse.gov.br/SefinNacional/nfse) o retorno também vem com esse problema?
Passei a tarde aqui e consegui corrigir o arquivo. Tecnicamente, converti de UTF-8 para HTML Entities e depois, converti de HTML Entities para Windows 1252. Dessa salada, saiu o arquivo em UTF-8 perfeito. Agora vou trabalhar para detectar exatamente quando acontece o bug e como detectar se tem o bug ou não, pois imagino que vão consertar isso.
2 curtidas
Pois é, o xml baixado do portal do contribuindo passa no validador (https://validar.iti.gov.br/). Tratar essa dupla codificação para que o xml baixado via webservice também passe no validador é um verdadeiro transtorno, sem falar que parece que estamos fazendo alguma coisa errada perante a lei, já que estamos modificando os dados recebidos para reenviar para os clientes.
Benilson, no caso, quem modificou o documento foi o sistema do Governo. Nisso você pode ficar bem tranquilo, porque tanto vocês quanto o Governo assinaram o documento. Da forma que o sistema (API/webservice) entrega o XML, nenhuma das assinaturas são válidas, pois o diagnóstico é que os Digests não batem, ou seja, o conteúdo do arquivo foi modificado após a(s) assinatura(s). Quando você corrige a dupla codificação utf-8, simplesmente os Digests voltam a bater, o que prova que agora sim você está com o documento original.
Quebrei muito a cabeça para entender como e por que a dupla codificação dificulta o retorno (alguns caracteres corrigem quando se usa rotinas nativas para descodificar, mas outras não voltam mais, em especial letras maiúsculas acentuadas, pois usam código unicode maiores). Consegui criar uma rotina em PHP que corrige qualquer string (ao menos em português) para codificação utf-8 correta. Achei na internet algumas soluções em python e várias em PHP que não funcionaram. Por via das dúvidas, vou passar minha rotina em todos os XML retornados até que o problema se resolva, já que ela não modifica o XML corretamente codificado (download do Portal).
Não específico deste tópico, mas os desenvolvedores acompanham este Fórum, ou é necessário informar bugs como esse a alguém?
Pessoal,
Infelizmente é uma é uma realidade… os arquivos XML recuperados da NFSe via API estão todos com “double-encoding”, posivelmente do lado da SEFAZ o pepeline deve estar rodando algo assim:
UTF-8 → ISO-8859-1 → UTF-8 → ASCII fallback → XML
O problema é que neste processo alguns caracteres especiais são corrompidos e… ai… já era, mesmo tratando o retorno identificando que o conteúdo do arquivo deve ser decodificado e codificado novamente para garantir que esteja em ‘UTF-8” válido… os caractes especiais que foram corrompidos no processo do lado da SEFAZ são perdidos.
Exemplo:
Retornado no XML da NFSe: Cobrança → Cobrança (corrigido!) porém M??S → não recupera… o Ê (originalmente era MÊS) do lado da SEFAZ foi substituido por ?? ai meu amigo… não tem o que fazer. (causa: ASCII, Ê não existe → vira ??)
1 curtida
Usa WINDOWS-1252 no lugar de ISO-8859-1, “somente” tive problema com o caractere “–”, colado do word até agora.
1 curtida
Seu código é em qual linguagem? Na base da tentativa e erro, em PHP fiz uma função recursiva que ajusta o texto duplo-codificado até acertá-lo (na verdade, ele “corrige” uma vez a mais, detecta o erro e devolve a penúltima correção). Tem dado certo aqui, uso sempre que baixo o XML via API (no envio ou na recuperação da nota). Se o arquivo já está correto UTF-8, não é alterado, portanto, mesmo quando o bug for resolvido, continuará funcionando.
A decodificação básica corrige os caracteres minúsculos acentuados, mas costuma dar problema com os maiúsculos, pois têm um Unicode maior. A saída que encontrei foi alterar o texto para codificação html, transformar em Windows-1252 e daí decodificar para utf-8. Mas precisei da recursividade, pois isso danificaria um arquivo corretamente codificado. Mas você pode verificar também se o texto aumentou de tamanho.
Em PHP, para corrigir o XML baixado via API do Portal (não sei se isso pode ser útil para tentar soluções similares em outras linguagens):
// Remove a dupla codificação
$correto = mb_convert_encoding(mb_convert_encoding($duplocodificado,'HTML-ENTITIES','UTF-8'),'Windows-1252','HTML-ENTITIES');
// Retorna o novo texto somente se ficou menor
return (strlen($correto) < strlen($duplocodificado) ? $correto : $duplocodificado);
1 curtida
Você está gerando o PDF a partir do XML? se sim está usando algum serviço, precisava gerar o PDF, estava usando o serviço para baixar o PDF diretamente, mas a API está muito intermitente queria ver se era possível baixar o XML e gerar o PDF a partir dele, também estou usando PHP…
Tem esses tópicos a respeito:
Erro API DANFSE - #2 de ClodoaldoMontiero → Link para uma api externa
Erro API DANFSE - #8 de marcos122 → Um bom motivo para não usar a api externa e fazer a própria
1 curtida