Rejeição 402: XML de dados com codificação diferente de UTF-8

A rejeição 402, regra D03, trata da codificação da área de dados XML. O padrão fiscal exige UTF-8. Escrever UTF-8 na declaração não converte, sozinho, os bytes que o aplicativo efetivamente transmitiu.

Nesta página:

• Como conferir a codificação efetiva?
• Exemplo: acentos alterados na passagem pelo arquivo
• A conversão pode afetar a assinatura?
• 402, 243 e 225 exigem a mesma correção?

Como conferir a codificação efetiva?

Compare a declaração XML, os bytes produzidos pelo serializador e a leitura desses bytes como UTF-8. A configuração de gravação ou do cliente de comunicação pode converter o conteúdo depois da validação local. Mantenha identificada a etapa em que ocorre a diferença.

D03 é obrigatória. O MOC exige o padrão UTF-8 e orienta uma única declaração XML no documento. Quando o lote contém outros documentos, não se devem concatenar declarações internas como se cada nota fosse um arquivo independente.

Fontes: MOC Anexo I, regra D03.

Exemplo: acentos alterados na passagem pelo arquivo

Em um cenário hipotético, o gerador trabalha corretamente em memória, mas a rotina de gravação usa outra codificação. O texto com acentos chega com bytes incompatíveis com a declaração. Trocar somente o rótulo da declaração ou eliminar os acentos não preserva o conteúdo real.

Corrija a codificação no ponto de gravação ou transmissão responsável. Compare o texto de origem com o texto lido do arquivo final em UTF-8. Se os dados já foram corrompidos antes dessa etapa, recupere a origem legítima em vez de substituir caracteres por aproximação.

Fontes: MOC Anexo I, regra D03.

A conversão pode afetar a assinatura?

Sim, quando altera o conteúdo ou a representação relevante para sua verificação. A assinatura deve ser gerada e conferida sobre a mensagem final conforme o padrão. Não converta ou remende manualmente um arquivo já assinado para tentar resolver D03.

Faça o ajuste no fluxo de geração, regenere e valide sintaxe, XSD e assinatura. Um editor que abre o arquivo sem erro pode estar escolhendo automaticamente outra codificação; isso não prova que os bytes atendem ao contrato fiscal.

Fontes: MOC Anexo I, regra D03.

402, 243 e 225 exigem a mesma correção?

Não. A 402 identifica codificação; a 243, XML malformado; a 225, schema do lote de autorização. Problemas de codificação podem impedir outras verificações, mas cada camada tem evidência própria.

Resposta síncrona e tipo de evento são verificações distintas da codificação. Identifique qual etapa produziu o retorno recebido. Confirme o resultado fiscal de tentativas incertas antes de nova ação; a correção de UTF-8 não representa autorização.

Fontes: MOC Anexo I, regra D03.

Limite do exemplo e preservação dos dados

O diagnóstico depende dos bytes originais protegidos, que uma renderização textual não preserva integralmente. O exemplo descreve a conversão sem fabricar XML fiscal ou assinatura. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.

Fontes oficiais

• MOC 7.0 — Anexo I, versão 7.00. p. 72, regra D03, código 402; quadro completo e notas da seção.
• MOC 7.0 — Visão Geral, versão 7.00. pp. 49–51, declaração, namespace, otimização, UTF-8 e validação; pp. 53–55, assinatura XML.