a qualcuno risultano problemi nella validazione contro lo schema xsd per il campo PECDestinatario in ambiente *unix?
Una email con un trattino, per esempio:
name@domain-test.it
non è validata né con xmlstarlet, né con xmlint.
L’errore è
The value 'name@domain-test.it' is not accepted by the pattern '([!#-'*+/-9=?A-Z^-~-]+(\.[!#-'*+/-9=?A-Z^-~-]+)*|"(\[\]!#-[^-~ \t]|(\\[\t -~]))+")@([!#-'*+/-9=?A-Z^-~-]+(\.[!#-'*+/-9=?A-Z^-~-]+)*|\[[\t -Z^-~]*\])'
mentre se tolgo il trattino ( name@domaintest.it ) il comando valida correttamente.
La regular expression è valida in altri contesti (per esempio in alcuni validatori JavaScript online). Credo che manchi qualcosa (forse l’escape di qualche caratttere) che renda qualche istruzione non ambigua.
Sia xmllint che xmlstarlet usano libxml2 quindi credo che si tratti di un bug in libxml2.
In particolare sembra che gli dia fastidio il carattere ^ tra le parentesi quadre, che quando si trova all’inizio indica che sono validi tutti i caratteri tranne quelli specificati, mentre se si trova nel mezzo, non ha nessun significato speciale (corrisponde al carattere stesso).
Negli elenchi tra parentesi quadre compare la sequenza ^-~, che corrisponde ai caratteri Unicode (e ASCII) da 94 a 126. Se provi a modificare l’espressione regolare sostituendo ^ con il carattere successivo, ovvero _ (underscore) (tranne dove compare all’inizio delle parentesi quadre), vedrai che la validazione funziona.
Facendo esperimenti, anche una semplice espressione regolare come [A-Z^-~-]+ (che dovrebbe accettare una stringa del tipo Pippo-Pluto, non funziona se c’è il trattino. Se tuttavia la modifichi in [A-Z_-~-]+, funziona.
Detto questo, potrebbe anche essere che libxml2 funziona correttamente e tutti gli altri no. Le espressioni regolari negli schema xml seguono regole leggermente diverse da altri tipi di espressioni regolari. Per esempio i caratteri ^ e $ (al di fuori delle parentesi quadre) non hanno nessun significato speciale, perché tutte le espressioni regolari sono implicitamente ancorate all’inizio e alla fine della stringa. Bisognerebbe leggersi con attenzione lo standard.
Ciao a tutti anche io oggi sono incappato casualmente in questa problematica perchè ho una PEC con “-” trattino… voi come avete risolto? qualche anima pia che possa fornire il fix?
È molto probabile che il SdI non usi una delle librerie con il bug (se ne sarebbero sicuramente accorti) e quindi questo rischio non c’è. E anche se fosse, se il tuo xsd è più restrittivo, il peggio che può accadere è che sia tu a considerare non valida una fattura che è passata per il SdI.
In ogni caso io stavo solo cercando di evidenziare il bug in libxml2 e non consiglio di usare una versione modificata del xsd. Piuttosto è da aggiornare la libreria.
Anche io non sono d’accordo sul modificare il file xsd. Tuttavia potrebbe essere l’unico modo di risolvere quando non è possibile aggiornare la maledetta libreria.
Se ho capito bene, quello che suggerisci come possibile modifica al file xsd è questo:
Sì.
Francamente non so perché abbiano usato un’espressione regolare così complessa per validare l’indirizzo email. Secondo me la si poteva far molto più semplice (giusto per bloccare cose che palesemente non sono indirizzi email) perché il fatto che un indirizzo email soddisfi la struttura formale non vuol dire che esista veramente.
Se fai la modifica suggerita, finirai per rifiutare indirizzi email contenenti il carattere ‘^’ che il SdI invece ritiene validi. Personalmente non credo di aver mai visto un indirizzo email con ‘^’.