Perché la dichiarazione xml è consigliata ma non obbligatoria nei file xml. Questo a livello di standard xml, indipendentemente dal xsd.
comunque il codice l’ho modificato dovrebbe prendere in pancia anche il caso senza la dichiarazione xml…
ho verificato ma ad oggi non me ne era arrivata nenache una…
Comunque se a qualcuno può interessare, ieri ho chiamato Sogei per chiedere come mai non esiste una procedura uniformata per i file… del tipo sono xades ok solo così oppure sono cades ok solo pomì… il resto non li accettiamo, in modo da evitare di dover processare mille casistiche differenti…
Mi hanno risposto (ho la telefonata registrata per intenderci!), che volendo avrei potuto visualizzare i file in pdf perchè su fatture e corrispettivi c’è anche questa possibilità!
Ho risposto, ok grazie per l’informazione 
Per ora ho ricevuto:
fatture senza l’intestazione <?XML
fatture con l’intestazione interrotta dalla firma CADES
fatture p7m in base64
fatture p7m non p7m… hanno rinominato il file in p7m e il contenuto era un XML non firmato.
l’unica cosa che non capisco è come si facciano ad inoltrare fatture in base64.
Se durante i test inoltravo tramite l’sdicoop una fattura codificata in base64, il sistema mi ritornava che non era leggibile.
Ciao a tutti, scusate vado a riprendere questo post in quanto ricevo file p7m in base64, ma a differenza di quanto detto, se provo ad estrarli con openSSL ottengo l’errore:
Error reading S/MIME message
24160:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto\asn1\tasn_dec.c:1130:
24160:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto\asn1\tasn_dec.c:290:Type=PKCS7
Leggendo su questo e altri forum, mi sembra di capire che devo prima fare la decodifica base64, ma non ho idea di come farla. Potete aiutarmi? Grazie
Sì, se il file è codificato con base64, prima di poter usare openssl per estrarre il file xml dal file .p7m, devi fare la decodifica base64.
Hai sviluppato un tuo software per gestire le fatture o le stai elaborando “a mano”?
Nel primo caso, il linguaggio di programmazione che usi avrà sicuramente una funzione per la decodifica base64 nelle librerie standard.
Nel secondo caso, ci sono un infinità di tool per farlo. Sotto Linux c’è il comando base64:
base64 -d fattura_codificata_base64.xml.p7m > fattura_decodificata.xml.p7m
Il file così ottenuto poi lo passi a openssl per estrarre il file xml vero e proprio. Mettendo le due cose insieme (supponendo che il file IT1234567890_12345.xml.p7m sia codificato in base64):
base64 -d IT1234567890_12345.xml.p7m | openssl smime -verify -inform DER -noverify -out IT1234567890_12345.xml
1 Mi Piace
Grazie, in effetti stavo nel mio linguaggio di programmazione ho le classi di encode e decode, ma sto prendendo in considerazione di usare certutil da command line (ambiente Windows) che funziona perfettamente, grazie mille della risposta!
Puoi cortesemente dire qualcosa di più circa a rimozione dei BOM? Ho un file che decodificato base64 e salvato non viene decodificato da openssl. Se lo apro con notepad lo vedo in caratteri cinesi. I caratteri standard BOM che ho trovato descritti in wikipedia non compaiono in testata file e non trovo altra documentazione a riguardo. Se rimuovo i primi byte la visualzzazione diventa corretta ma openssl non lo decodifica ugualmente
potresti dire come inizia il file ?
a parte quelli citati su wikipedia non ci sono altri caratteri BOM.
Attenzione la pagina in italiano di wikipedia non riporta tutti i possibili bom
fai riferimento a quella inglese
io sono arrivato a questo
sed -e 's/\r//' < IT1234567890_12345.xml.p7m|base64 -d | openssl smime -verify -inform DER -noverify -out IT1234567890_12345.xml
dato che ho trovato dei file base64 “chunked” con terminatori di riga dos che mandavano in palla base64 -d
La versione di base64 che ho io (da coreutils-8.22-23.el7 in CentOS 7) ha anche l’opzione -i che permette di ignorare caratteri estranei (ma bisogna essere sicuri che il file sia effettivamente base64).
In alternativa è possibile usare anche openssl stesso (comando base64 -d, oppure enc -d -base64):
openssl base64 -d -in IT1234567890_12345.xml.p7m | openssl smime -verify -inform DER -noverify -out IT1234567890_12345.xml
Ciao,
io faccio cosi, quando devo importare una fattura chiamo una funzione che fa:
- verifica se l’estensione (to uppercase) finisce per .P7M
- Se falso importo il file XML, se vedo processo il P7M
- Prendo il contenuto firmato con Bouncycastle
- Siccome in P7m (CaDES) possono esserci solo le fatture (le notifiche da SDI sono sempre firmate in XaDES), trasformo il contenuto in Stringa
- Cerco la prima posizione del carattere
< - Se posizione superiore a 0 faccio un substring della posizione
- Ritorno il file fattura corretto…
Ad oggi ho importato qualche migliaio di fatture senza mai un problema…
e se ti arriva una fattura P7M che P7M non è ?
Capitata anche quella…
Ad oggi casi riscontrati:
fatture P7M base 64 encoded (chuncked, chuncked con LFCR, chunched CRLF, no chucks)
fatture P7M binary
fatture P7M che in realtà sono XML
fatture XML XADES (con o senza intestazione <?XML)
fatture XML (con o senza intestazione <?XML)
All’appello mi mancano solo fatture con i BOM…
Per ora mai successo, in verita’ uno dei primi invii fatti da me avevo scordato un controllo nella procedura e inviando un P7m con estensione xml SDI mi ha scartato la fattura…
Non ho mai provato a inviare un XML con estensione P7M tuttavia…
Mah!?!
Cmq al momento questo caso non lo gestisco, al massimo mi rimane la notifica in errore e la importo successivamente…
Pure io ho ricevuto un p7m con dentro il base64 del p7m… me lo ha mandato Aruba, perciò direi che ce ne sono in giro parecchie di fatture fatte così.
Alcune fatture di TIM (non tutte) contengono questo namespace nell’intestazione XML:
xmlns:pfx6=“http://www.tibco.com/ns/no_namespace_schema_location/NBS_FAT_WRITER/Schemas/XSD riepilogo_fattura_ordinaria_v1.2_mod.xsd”
e la funzione xml_load_string() di PHP genera un warning perchè trova lo spazio nell’URI del namespace.
In effetti un URI non può contenere spazi, quindi il file XML non è valido.
Però ci sono librerie XML che li accettano, per esempio .NET (ho appena verificato).
E, a quanto pare, anche la libreria usata da SOGEI (che penso usi Java), perché questi file vengono considerati validi dal SdI.
Io uso la simplexml_load_string e non mi sembra di ricevere warning di alcun tipo…
almeno su php7.2
Tantomeno mi da problemi l’utilizzo di XsltProcessor per la visualizzazione.
Stesso problema rilevato da me!
Al momento, trascurando il warning, non ci sono effetti collaterali.
Per quanto mi riguarda non ha senso arginare questo problema.
Intendevo proprio quella funzione li’, mi era scappato il ‘simple’ 
.
Comunque si’ a parte quel warning il file viene importato regolarmente.