Rejeição 588: caracteres de edição entre as tags do XML
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A rejeição 588, regra D01e, verifica caracteres de edição no início, no fim ou entre as tags da mensagem. O objetivo técnico é enviar a serialização conforme o padrão fiscal, sem a formatação acrescentada apenas para facilitar a leitura humana.
Nesta página:
- Quais caracteres devem ser investigados?
- Exemplo: formatação aplicada depois da assinatura
- Por que compactar com substituição global é inadequado?
- Como diferenciar 588 de XML malformado e assinatura inválida?
Quais caracteres devem ser investigados?
O MOC Visão Geral cita quebras de linha, retorno de carro, tabulação e espaços entre tags entre os caracteres de formatação a evitar. Confira os bytes efetivos da mensagem, inclusive após a montagem do cliente de integração. Um visualizador pode ocultar ou acrescentar indentação e não mostrar como o arquivo foi transmitido.
D01e é facultativa. XML legível e bem formado ainda pode contrariar essa exigência de serialização. Também é importante distinguir espaços de formatação de espaços que fazem parte do conteúdo de um campo.
Fontes: MOC Anexo I, regra D01e.
Exemplo: formatação aplicada depois da assinatura
Considere um gerador que assina o documento e, em seguida, uma rotina de gravação aplica indentação para deixá-lo legível. A rotina pode acrescentar caracteres entre os elementos que não estavam na árvore assinada. Isso cria um problema de serialização e pode afetar a verificação da assinatura.
Compare a saída imediata da assinatura com o conteúdo entregue ao cliente de transmissão. Corrija a rotina que formata o arquivo e gere novamente o resultado pelo fluxo legítimo. Não faça uma remoção indiscriminada de espaços sobre o XML assinado.
Fontes: MOC Anexo I, regra D01e.
Por que compactar com substituição global é inadequado?
Uma substituição pode alcançar textos, atributos ou dados cuja grafia importa, além de não distinguir namespace e contexto. Corrigir formatação não autoriza remover campos, zeros explícitos ou informações fiscais reais.
Configure o serializador para emitir o formato previsto antes da assinatura e confira a cadeia posterior de processamento. Se houver arquivo para exibição humana, mantenha-o separado da mensagem que será transmitida. A validação deve usar os bytes finais do envio.
Fontes: MOC Anexo I, regra D01e.
Como diferenciar 588 de XML malformado e assinatura inválida?
A 243 trata de sintaxe malformada; a 588 pode ocorrer em XML que um parser aceita. A 297 trata de assinatura diferente do valor calculado. Uma mudança de formatação pode ter consequências em mais de uma camada, mas não é correto deduzir uma delas apenas da outra.
Valide sintaxe, XSD, formato e assinatura após reparar a geração. A autorização ainda depende do retorno fiscal; antes de repetir uma tentativa incerta, esclareça seu estado.
Fontes: MOC Anexo I, regra D01e.
Limite do exemplo e preservação dos dados
A análise depende dos bytes originais antes e depois da assinatura. Um trecho reformatado no artigo esconderia justamente a diferença examinada; o exemplo é textual. 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 D01e, código 588; 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.