encoding.bom
Byte Order Mark (BOM) all'inizio del file
L'AT rifiuta i file SAF-T che iniziano con un BOM UTF-8 o UTF-16.
Cos'è un BOM
Un Byte Order Mark è una firma di 2 o 3 byte all'inizio assoluto di un file di testo che indica quale codifica Unicode usa il file. Nella maggior parte degli editor non si vede, ed è questo che lo rende difficile da trovare:
| Codifica | Byte del BOM | Cosa significa per un file SAF-T |
|---|---|---|
| UTF-8 | EF BB BF | Rimuovi i 3 byte; controlla anche la dichiarazione di codifica. |
| UTF-16 BE | FE FF | L'intero file è in UTF-16: va convertito, non basta tagliare i byte. |
| UTF-16 LE | FF FE | Come sopra. Tipico dei file salvati come "Unicode" da strumenti Windows. |
Perché l'AT rifiuta i BOM
L'AT si aspetta i file SAF-T (PT) in Windows-1252, che non ha BOM. Lo schema e il parser d'ingresso dell'AT si aspettano che il primo byte del file sia il < della dichiarazione XML, non una firma Unicode.
Quando è presente un BOM, l'XML può comunque aprirsi senza problemi nel browser o nel tuo ERP, ma il file viene rifiutato in ingresso senza un errore utile. Vedi cosa significano i messaggi di errore dell'AT per i messaggi che potresti vedere.
Come dovrebbe iniziare il file
Un file SAF-T (PT) corretto inizia direttamente con la dichiarazione XML:
<?xml version="1.0" encoding="Windows-1252"?>
<AuditFile xmlns="urn:OECD:StandardAuditFile-Tax:PT_1.04_01">In un editor esadecimale, i primi byte sono 3C 3F 78 6D 6C (<?xml). Con un BOM UTF-8 sono EF BB BF 3C 3F.
Come ci finisce un BOM
- Aprire l'esportazione in Blocco note e salvarla di nuovo come "UTF-8 con BOM" (il default delle versioni Windows meno recenti) o come "Unicode" (UTF-16).
- Alcuni ERP e strumenti di reportistica antepongono un BOM quando esportano XML "Unicode-aware".
- Convertire il file con uno strumento che aggiunge una firma, oppure unire file con uno script che ne scrive una.
Come controllare il tuo file
Guarda i primi tre byte:
# Linux / macOS
head -c 3 my.xml | xxd
# Windows PowerShell
Format-Hex my.xml | Select-Object -First 1Se vedi EF BB BF, FF FE o FE FF, il file ha un BOM. In alternativa carica il file su SAFTCheck, che fa questo controllo a ogni caricamento.
Come correggere
BOM UTF-8: rimuovi i primi 3 byte; il resto del file resta invariato.
# Linux / macOS
sed -i '1s/^\xEF\xBB\xBF//' my.xmlBOM UTF-16: rimuovere i byte non basta, perché ogni carattere del file occupa 2 byte. Converti l'intero file in Windows-1252, poi assicurati che la dichiarazione riporti encoding="Windows-1252":
# Linux / macOS
iconv -f UTF-16 -t WINDOWS-1252 my.xml > my-fixed.xmlSu Windows senza strumenti da riga di comando: in Notepad++, usa Codifica, poi "Converti in ANSI", e salva. Evita di salvare di nuovo con il Blocco note di Windows, che spesso è proprio il modo in cui il BOM ci è finito.
La soluzione migliore a lungo termine è nelle impostazioni di esportazione dell'ERP, così il file del mese successivo esce già corretto.
Cosa fa SAFTCheck
L'anomalia compare come encoding.bom con la posizione "File offset 0" e il tipo di BOM (UTF-8, UTF-16 BE o UTF-16 LE). "Correggi automaticamente e scarica" rimuove un BOM UTF-8 e converte i file UTF-16 in Windows-1252, insieme a qualsiasi altra correzione di codifica di cui il file abbia bisogno. Il file corretto viene validato di nuovo prima che tu lo scarichi.
Una riga vuota o degli spazi prima di <?xml causano lo stesso tipo di rifiuto silenzioso; la correzione automatica rimuove anche quelli.
Correlato
- Dichiarazione di codifica XML (Windows-1252): il requisito di codifica più ampio.
- Come correggere l'errore di codifica UTF-8 del SAF-T in Portogallo