salve a tutti,
è un argomento già discusso che sembrava risolto ma a quanto pare recentemente ho iniziato a ricevere fatture che non riesco ad interpretare.
attualmente sto utilizzando una funzione per gestire le fatture ricevute in cades rimuovendo i caratteri non stampabili e filtrando i tag ma vedo che con le ultime fatture ricevute non si comporta correttamente. rimangono caratteri errati come * all’interno dei tag e il file non viene più interpretato.
avete qualche suggerimento in merito?
Come ti avevo già risposto in un altro thread un mese fa, non puoi limitarti a rimuovere la parte prima e dopo il file xml e i caratteri non stampabili nel mezzo. A seconda di come è codificato il file p7m, i header binari dei vari blocchi potrebbero, per sfiga, contenere caratteri validi.
In cosa stai programmando?
Se usi .NET o Java, ci sono librerie già pronte per gestire i file CMS/PKCS#7. Se stai usando PHP, ho visto che qualcuno ha semplicemente usato openssl per estrarre il file firmato:
openssl smime -verify -inform DER -in file_originale.p7m -noverify -out file_finale
Ciao, ricordavo la tua risposta ma ricercando tra i vari thread non sono riuscito a trovarla e per praticità ho preferito aprirne uno nuovo.
Uso PHP quindi dovrò optare per openssl
Grazie
In teoria potresti usare anche la funzione openssl_pkcs7_verify, ma da quello che leggo nei commenti qui:
http://php.net/manual/en/function.openssl-pkcs7-verify.php
per estrarre il contenuto del file .p7m, devi creare un file in formato S/MIME e il risultato te lo trovi comunque in un file.
scusate se mi intrometto : che tipo di mezzo di trasmissione stai usando? Sftp per caso?
i file di fatture firmate ti arrivano dentro il file FO.xxxxx.zip?
ciao Domenico,
il metodo che usiamo è SDIcoop tramite webservice.
lo scrivo qui perchè delle poche fatture ricevute al momento una è strana.
ho dovuto fare la decodifica del dato 2 volte.
In fase di invio tramite Webservice la fattura non va codificata in base64 perché ci pensa già il serverSoap ad eseguire l’operazione e se in fase di test provavo a codificarla nuovamente mi veniva bocciata dal SDI perchè illeggibile.
normalmente al ricevimento del xml eseguo un decode_base64() del file XML mentre ieri ho trovato una fattura che per riuscire ad accettarla e leggerla ho dovuto usare il decode 2 volte.
adesso sto aggiornando tutti i gestionali perchè altrimenti non riuscirebbero a interpretare l’xml quindi faccio presente la cosa nel caso ci siano altri che hanno operato come me.
grazie per la risposta Daniele.
Ormai non ho più parole 
dovrei iniziare i tests a giorni (canale SFTP) e vedremo cosa succederà…
Eccolo!
Daniele, pure io sono finito nello stesso tuo problema: doppio encoding del P7M.
Per ora l’incidenza è sporadica, ma presente. E i soggetti trasmittenti sono vari e pure importanti, ma credo che l’errore, a sensazione, venga introdotto durante il trasporto del file e non alla consegna. Guarda i metadati associati e verifica se in TentativiInvio c’è un valore positivo: la mia idea è che gli rimanga alzato un flag per cui rifaccia encoding base64 nella preparazione della request al tuo ws.
Abbiamo aperto con Sogei ieri sera un ticket ufficiale in merito, anche perché, fra l’altro, quella stessa bicodificata che arriva al tuo endpoint arriva pure nel cassetto fiscale del tuo cliente. E dato che, anche qualora tu la “respingessi” 3 volte di fila, nel cassetto ci si infilerebbe lo stesso, è un problema grave: penso a tutto il discorso che va dal semplice download alla contabilizzazione alla conservazione: di che? Posso dire al mio idraulico di fare il base64decode dopo averla scaricata? E dai.
Mi stupisce che a 20 giorni di distanza sussista ancora una anomalia del genere nella filiera. Tu hai aperto un ticket formale?
sinceramente non ho aperto nessun ticket perché ho ipotizzato che quel tipo di encoding sia dovuto agli invi tramite FTP.
con l’SdiCoop inoltri la fattura in xml (firmata o meno) il client soap provvede a fare l’encoding in automatico (almeno in PHP)
con l’FTP mi pare si possa mettere le fatture dentro una cartella firmata o firmare il documento e metterlo dentro una cartella non firmata.
probabilmente una delle due situazioni comporta un encoding aggiuntivo da parte dell’agenzia delle entrate
ad ogni modo io banalmente ho risolto eseguendo un controllo in lettura con la funzione nativa di php che permette sia di decodificare da base64 che verificare se la stringa è in base64.
Non credo che l’encoding avvenga per via del canale SDIFTP. Così a naso mi pare più un’operazione da soap…
Non vorrei tirarmela da solo, ma finora non ho mai ricevuto un documento encodato due volte base64. 
Hai risolto per il tuo business, e la soluzione è la sola applicabile. Ma il problema è che nel cassetto fiscale del cliente la fattura è sbagliata, se fa download è il base64. Cosa mandi in conservazione? Quella oggetto di tua fix o quella originale?
Dipende da quante fatture riceve la tua piattaforma e quanti utenti serve. L’incidenza è molto bassa, per fortuna, e nel molto bassa, laddove la quantità è piccola, può diventare zero.
Se può interessarti o spaventarti, ho anche un caso isolato di fattura con attachment che viene riencodata base64 e pure tagliata verso il finale.
ti rispondo con una frase da far rabbrividire.
Al momento c’è la conservazione dell’ADE poi manderemo in conservazione ulteriore i documenti con un conservatore ufficiale ma per quello c’è tempo dato che la data ultima è entro il 60 o 90 giorni dal termine dell’anno solare.
per quanto riguarda cosa mandare, io manderei quello che ho ricevuto per garantire che non è stato modificato nulla.
Figo! Non c’è mai limite al peggio! 
MI chiedo come sia possibile che SDI passi un file del genere tagliato visto che lo deve decodificare…
Di sicuro non è possibile su SDIFTP dove un trasferimento a metà non può succedere (altrimenti SDI non rinomina il file).
Mi chiedo una cosa. Non è che qualche SOAP in giro in caso di pacchetto incompleto fa lo zelante ed interpreta ciò che fino a quel punto ha ricevuto ignorando il controllo fra la content lenght dichiarata e quella reale ?
il file non è obbligatorio che sia in formato smime… il flag PKCS7_BINARY dovrebbe risolvere il problema…
edit: il formato SMIME è obbligatorio il flag binary fa solo aprire i file su windows in binary mode…
(guardato il codice)
non è un p7m ma è comunque un caso particolare.
questa notte il nostro sistema non è riuscito a ricevere una fattura.
ecco un pezzo della fattura che dai log non siamo riusciti a leggere per poterla indirizzare al cliente
se interpretato tramite browser gli spazi non ci sono e sembra corretto…
invece gli spazi ci sono e la funzione simplexml_load_string non riesce ad interpretare l’XML
Sei sicuro che siano spazi e non byte con valore 0? Il file potrebbe essere in UTF-16.
Ho provato a fare alcuni test con la verifica online delle fatture, e mi scarta le fatture in UTF-16 se non è presente la dichiarazione xml <?xml version="1.0" encoding="utf-16"?>, quindi se fosse effettivamente UTF-16, non so come abbia fatto a passare attraverso il SdI.
svista mia.
è in utf-16
Ma è arrivata da SDI ???
