Closed caiofior closed 2 years ago
Il codice fiscale CNTPTR60C29H5L1W non è formalmente corretto. Credo che si tratta di uno dei tanti codici fiscali attribuiti arbitrariamente dall'agenzia delle entrate per risolvere i casi di omonimia, vedi https://it.m.wikipedia.org/wiki/Omocodia
Mi spiace, ma data la natura del codice fiscale la validazione della sola forma non è sicura al 100%, dovresti vedere se l'agenzia delle entrate espone qualche api per la validazione effettiva.
Il problema sta nel fatto che anche l'espressione regolare con cui si effettua il controllo, come il resto del codice della classe, dovrebbe prevedere che venga inserito un codice fiscale privo di formattazione standard frutto di una sostituzione per omocodia.
Con l'espressione attuale, il controllo fallirà sempre, poiché controlla unicamente la validità del formato standard.
Mettiamo il caso che venga sostituito il primo numero dell'anno di nascita (posizione 6 dell'array $CodiceFiscaleArray, posizione 7 nella stinga del codice fiscale), se nella regex si controlla che il settimo e l'ottavo carattere siano numerici ('/^[a-z]{6}[0-9]{2}[a-z][0-9]{2}[a-z][0-9]{3}[a-z]$/i'), il controllo fallirà...
Per il codice fornito dall'utente, ad esempio, il controllo fallisce perché controllando il codice comune, il controllo impone una lettera ([a-z]) e 3 numeri ([0-9]{3}), e H5L1 non rispetta tale formato (ma è la sostituzione per il codice comune di Roma H501).
Utilizzando infatti un'espressione regolare diversa, il controllo sul codice fiscale fornito dall'utente va a buon fine.
L'espressione che ho utilizzato è la seguente:
/^(?:[A-Z][AEIOU][AEIOUX]|[B-DF-HJ-NP-TV-Z]{2}[A-Z]){2}(?:[\dLMNP-V]{2}(?:[A-EHLMPR-T](?:[04LQ][1-9MNP-V]|[15MR][\dLMNP-V]|[26NS][0-8LMNP-U])|[DHPS][37PT][0L]|[ACELMRT][37PT][01LM]|[AC-EHLMPR-T][26NS][9V])|(?:[02468LNQSU][048LQU]|[13579MPRTV][26NS])B[26NS][9V])(?:[A-MZ][1-9MNP-V][\dLMNP-V]{2}|[A-M][0L](?:[1-9MNP-V][\dLMNP-V]|[0L][1-9MNP-V]))[A-Z]$/i
reperita qui: http://blog.marketto.it/2016/01/regex-validazione-codice-fiscale-con-omocodia/
Credo che con l'integrazione di #3 il problema sia stato risolto
Confermo... Grazie ancora @f-lombardo per il tuo contributo
@f-lombardo ho sistemato un po' il progetto, aggiunto alcuni test e coverage. C'è solo un caso che non riesco a coprire https://coveralls.io/builds/45850621/source?filename=src%2FCodiceFiscale.php#L406 in pratica un codice fiscale che non sia valido per la regex... riesci a tirarne fuori uno giusto per avere la coverage completa? grazie
Ciao Simone,
il caso di test mancante era 0NTPTR60C29H5L1S, che è una stringa con carattere di controllo valido, ma con una cifra al posto dei numeri.
Ti ho fatto una PR
Franco
@f-lombardo grazie mille!
Buongiorno Simone, il c.f. CNTPTR60C29H5L1W viene indicato da questa procedura come non valido mentre l'agenzia delle entrate lo da per buono. Ho la sensazione che il problema sia alle righe 214-215 dove viene fatto un controllo sulla posizione di lettere e numeri nel codice che purtroppo non funziona nel caso di un'omocodia Grazie