Formato xml errore

ecco l’errore.
“msg”: “File XML errato:\nFile XML errato:\n\nErrore 1872: The document has no document element. linea -1\n\n”

quindi il problema sorge a monte di questo xml dove risultano degli spazi vuoti (come da screen che ho allegato) in realtà se visualizzo il file xml vero è proprio questi spazi non si vedono.

La domanda non è molto chiara…
Cosa contiene lo screenshot? E come è stato generato il file xml?
Lo screenshot sembrerebbe contenere parte di un codice sorgente e non il contenuto del file xml. Se è codice sorgente, in quale linguaggio è scritto?
Non so in altri linguaggi, ma in python e C#, una stringa specificata in quel modo avrà un new line all’inizio del file (oltre che un new line doppio alla fine di ogni riga) e l’xml non sarà valido perché non deve esserci nulla prima della dichiarazione xml.
Quando dici che visualizzando il file xml gli spazi non si vedono, cosa intendi? Come lo hai visualizzato? Hai provato ad aprirlo con un editor esadecimale?

Grazie per la pazienza innanzitutto,

Il linguaggio con cui ho generato l’xml è php, più precisamente sto utilizzando laravel framework.

A monte del mio script php c’è un’ array che dopo varie manipolazioni alla fine di tutto viene convertito in un file xml.

Quando invio il mio file xml tramite rest api ottengo questo errore:

“msg”: “File XML errato:\nFile XML errato:\n\nErrore 1872: The document has no document element. linea -1\n\n”

Per cercare di capire più approfonditamente il problema prima della conclusione del mio script ho fatto un dd() del file per capirne qualcosa e come da screen che vi ho postato mi sono accorto che sopra la linea di dichiarazione <?xml version="1.0" encoding="UTF-8"?> c’erano degli spazi “”"

anche aprendo il mio file xml generato con editor esadecimale questo è quello che ne viene fuori:

E questo è il mio xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<p:FatturaElettronica xmlns:p=“http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2” xmlns:ds=“XML-Signature Syntax and Processing” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” versione=“FPR12”>



IT
11359591002

61
FPR12
6EWHWLT




IT
12345678507

01457910881

INNOVAT SRL

RF01


VIA LOVISO 12
90100
PALERMO
PA
IT


PA
120
100000.00
SU
LN


Geo@mail.com





IT
12345678515


Pegaso srl



VIA LOVISO 15
90100
PALERMO
PA
IT





IT
12345678507


TosNet S.r.l



TZ




TD01
EUR
2022-06-20
61

RT01
32.00
20.00
D


TC01
4.00
6.40
22.00
SI

203.01




1

GINT13
UTOP

aaaaaaaaa
1.00
SC
200.00

SC
20.00

160.00
22.00
SI


22.00
166.40
36.61
I



TP01

MP08
2022-06-25
203.01



</p:FatturaElettronica>

Spero di essermi espresso in maniera esaustiva. Grazie anticipatamente.

Allora, come puoi vedere il tuo file xml contiene 3 byte prima dell’inizio della dichiarazione xml. Questi costituiscono un BOM UTF-8, che è la probabile causa dell’errore. Il BOM però è anche l’unica eccezione alla regola che dice che non deve esserci nulla prima della dichiarazione xml. Anche se il BOM è superfluo (la codifica è comunque specificata nella dichiarazione xml), il file XML dovrebbe essere valido e il Sistema di Interscambio accetta questo tipo di file.
L’errore però non viene generato dal SdI, ma dalle API REST che stai usando. Anche se questo tipo di file xml è valido, ci sono in giro parser XML che li rifiutano. A questo punto hai due opzioni:

  1. Vedere come convincere le librerie che usi a non inserire il BOM quando generi il file XML.
  2. Contattare il fornitore delle API REST e fargli presente che il loro parser XML non rispetta lo standard e rifiuta file con BOM che invece dovrebbe accettare.

La prima opzione sarebbe preferibile, perché il BOM è del tutto superfluo, e anche se accettato dal SdI, c’è sempre il rischio che il software di chi riceve la fattura abbia lo stesso problema (anche se penso che i software si siamo ormai tutti adeguati, dato che la percentuale di fatture con BOM che passano per il SdI è sufficientemente elevata).

Veramente grazie per la risposta molto molto preziosa e che mi da una bella dritta nella giusta direzione per risolvere il problema.

Ultima cosa per essere preciso che mi ero dimenticato di dirvi e che nella documentazione che mi hanno fornito hanno specificato questa cosa:

Il file dovrà essere inviato tramite una variabile POST di nome file (con encoding base64)