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?
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.
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.
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?