encoding.bom
Byte Order Mark (BOM) no início do ficheiro
A AT rejeita ficheiros SAF-T que começam com um BOM UTF-8 ou UTF-16.
O que é um BOM
Um Byte Order Mark é uma assinatura de 2 ou 3 bytes no início absoluto de um ficheiro de texto, que sinaliza qual a codificação Unicode usada pelo ficheiro. Na maioria dos editores não é visível, e é isso que o torna difícil de encontrar:
| Codificação | Bytes do BOM | O que significa para um ficheiro SAF-T |
|---|---|---|
| UTF-8 | EF BB BF | Retire os 3 bytes; verifique também a declaração de codificação. |
| UTF-16 BE | FE FF | Todo o ficheiro está em UTF-16: tem de ser convertido, não basta cortar os bytes. |
| UTF-16 LE | FF FE | O mesmo que acima. Típico de ficheiros gravados por ferramentas Windows como "Unicode". |
Porque é que a AT rejeita BOMs
A AT espera ficheiros SAF-T (PT) em Windows-1252, que não tem BOM. O esquema e o parser de entrada da AT esperam que o primeiro byte do ficheiro seja o < da declaração XML, não uma assinatura Unicode.
Quando há um BOM, o XML pode abrir sem problemas num navegador ou no seu ERP, mas o ficheiro é rejeitado à entrada sem uma mensagem de erro útil. Consulte o que significam as mensagens de erro da AT para ver as mensagens que pode encontrar.
Como deve ser o início do ficheiro
Um ficheiro SAF-T (PT) correto começa diretamente com a declaração XML:
<?xml version="1.0" encoding="Windows-1252"?>
<AuditFile xmlns="urn:OECD:StandardAuditFile-Tax:PT_1.04_01">Num editor hexadecimal, os primeiros bytes são 3C 3F 78 6D 6C (<?xml). Com um BOM UTF-8 são EF BB BF 3C 3F.
Como aparece um BOM
- Abrir a exportação no Bloco de Notas e gravá-la novamente como "UTF-8 com BOM" (o padrão em versões mais antigas do Windows) ou como "Unicode" (UTF-16).
- Alguns ERPs e ferramentas de relatórios acrescentam um BOM ao exportar XML compatível com Unicode.
- Converter o ficheiro com uma ferramenta que adiciona uma assinatura, ou juntar ficheiros com um script que a escreve.
Como verificar o seu ficheiro
Observe os três primeiros bytes:
# Linux / macOS
head -c 3 my.xml | xxd
# Windows PowerShell
Format-Hex my.xml | Select-Object -First 1Se vir EF BB BF, FF FE ou FE FF, o ficheiro tem um BOM. Em alternativa, carregue o ficheiro no SAFTCheck, que faz esta verificação em cada carregamento.
Como corrigir
BOM UTF-8: retire os primeiros 3 bytes; o resto do ficheiro mantém-se igual.
# Linux / macOS
sed -i '1s/^\xEF\xBB\xBF//' my.xmlBOM UTF-16: retirar os bytes não chega, porque cada carácter do ficheiro ocupa 2 bytes. Converta todo o ficheiro para Windows-1252 e confirme depois que a declaração indica encoding="Windows-1252":
# Linux / macOS
iconv -f UTF-16 -t WINDOWS-1252 my.xml > my-fixed.xmlEm Windows sem ferramentas de linha de comandos: no Notepad++, use Codificação, depois "Converter para ANSI", e grave. Evite voltar a gravar com o Bloco de Notas do Windows, que é muitas vezes a origem do BOM.
A melhor correção a longo prazo está nas definições de exportação do ERP, para que o ficheiro do mês seguinte saia correto.
O que o SAFTCheck faz
O resultado aparece como encoding.bom com a localização "File offset 0" e o tipo de BOM (UTF-8, UTF-16 BE ou UTF-16 LE). "Corrigir automaticamente e descarregar" retira um BOM UTF-8 e converte ficheiros UTF-16 para Windows-1252, juntamente com quaisquer outras correções de codificação de que o ficheiro precise. O ficheiro corrigido é validado novamente antes de o descarregar.
Uma linha em branco ou espaços antes de <?xml provocam o mesmo tipo de rejeição silenciosa; a correção automática também os remove.
Relacionado
- Declaração de codificação XML (Windows-1252): o requisito mais geral de codificação.
- Como corrigir o erro de codificação UTF-8 do SAF-T em Portugal