La validazione di un numero è la routine che decide se una stringa di caratteri può rappresentare un conto, un documento o un prodotto. Non è una sola prova ma tre, applicate in un ordine stabilito: ogni carattere è lecito, la stringa ha la dimensione giusta e la cifra finale concorda con l’aritmetica dei caratteri che la precedono.
Ogni livello intercetta un tipo diverso di errore e ciascuno risponde a una domanda molto più ristretta di quanto la maggior parte delle persone presuma. Questa guida percorre i tre livelli in ordine, spiega perché una prova superata non è un’affermazione sul mondo e mostra da dove nascono i quattro possibili giudizi di un validatore.
Che cos’è la validazione di un numero?
Nella sua forma più semplice, la validazione è un filtro che separa l’input che un sistema può elaborare da quello che non può. Il filtro è costruito con regole pubblicate anziché con segreti, ed è per questo che la stessa prova può essere eseguita in un browser, in un processo di importazione notturno e accanto a un’etichetta stampata senza che nessuno dei tre dissenta.
Il termine viene spesso esteso fino a coprire due attività non correlate. Una è strutturale: questa stringa obbedisce al formato che il suo schema definisce? L’altra è fattuale: questo numero è stato mai emesso, e a chi? Solo la prima appartiene a un validatore. La seconda richiede una consultazione del registro che ha emesso il valore, e una routine offline non può eseguirla.
Tenere separate le due cose è l’intero scopo dell’esercizio. Un modulo che segnala una struttura superata come un’identità approvata lascerà passare sciocchezze con sicurezza, e l’utente ci crederà.
Ogni numero e ogni stringa descritti in questo articolo sono un’illustrazione volutamente costruita, scritta solo per mostrare come si comportano i tre livelli. Nessuno di essi rappresenta un conto, un documento o un pacco reale, e una prova superata in un’illustrazione non è mai la prova che un simile record esista.
Tre livelli di filtraggio: set di caratteri, lunghezza e cifra di controllo
I livelli sono economici da eseguire e ciascuno è cieco ai fallimenti che gli altri intercettano.
| Livello | Cosa chiede | Cosa intercetta | Cosa non vede |
|---|---|---|---|
| Set di caratteri | Tutti i caratteri sono leciti qui? | Lettere digitate in un campo numerico, simboli estranei, segni di formattazione incollati da altrove | Una cifra errata che è essa stessa lecita |
| Lunghezza | La stringa ha la dimensione che lo schema consente? | Un carattere perso o ripetuto durante la digitazione | Una stringa della stessa lunghezza con due caratteri vicini scambiati |
| Cifra di controllo | La cifra finale deriva dal resto? | La maggior parte degli errori su un singolo carattere e molti scambi adiacenti | Qualsiasi valore che non è mai stato emesso |
L’ordine conta quanto il contenuto. Normalizza prima, poi controlla il set di caratteri, poi la lunghezza, e solo allora esegui l’aritmetica. Una routine che calcola una cifra di controllo prima di rimuovere gli spazi rifiuterà valori del tutto corretti, e lo farà con un messaggio che indirizza l’utente verso un problema che non esiste.
Perché superare il formato non rende reale un numero?
Una cifra di controllo è un riassunto aritmetico dei caratteri che la precedono. È calcolata a partire da quei soli caratteri, quindi dimostra una coerenza interna e nulla di più. Chiunque comprenda la regola pubblicata può produrre una stringa che la soddisfa, ed è esattamente ciò che fa di proposito un generatore.
Ciò che la prova non può vedere è il registro. Se un conto è aperto, se un documento è stato mai stampato, se un prodotto è stato mai confezionato — tutto questo vive in un database sotto un’autorità a cui il validatore non ha accesso. Un valore può soddisfare ogni livello offline e comunque non corrispondere a nulla; la guida sulle regole di validazione dei documenti di identità per paese analizza cosa significhi in particolare per gli schemi di identificazione.
Tratta un giudizio come un’affermazione sulla stringa, mai sul mondo. Questa impostazione mantiene onesti i messaggi di errore e impedisce ai revisori di leggere in una spunta verde più di quanto possa portare.
Un numero può appartenere a più schemi
Gli schemi si sovrappongono. Due sistemi di numerazione indipendenti possono concordare sul set di caratteri leciti, sulla lunghezza totale e persino sull’aritmetica del carattere finale, quindi la stessa stringa è un vero membro di entrambi. Nulla di ciò è un difetto; è ciò che accade quando progettisti separati ricorrono a convenzioni simili.
Un validatore che annuncia un unico paese indovinato nasconde l’ambiguità e inventa informazioni che non possiede. Un’interfaccia migliore elenca ogni schema che la stringa soddisfa davvero e lascia che il lettore decida quale registro consultare dopo. Lo stesso ragionamento vale al contrario quando nulla corrisponde: la risposta onesta è che nessuna regola implementata riconosce l’input, non che il valore sia falso. Un numero del tutto genuino può semplicemente cadere fuori dall’insieme di regole che uno strumento conosce; è l’intero argomento dei numeri senza cifre di controllo.
Normalizzazione: spazi, trattini e maiuscole
L’input reale arriva formattato per gli occhi umani. I numeri di conto sono stampati in gruppi, i valori d’identità portano punti e barre, e le etichette mescolano maiuscole e minuscole. Nulla di ciò fa parte del numero, e tutto deve sparire prima che avvenga qualsiasi confronto.
La normalizzazione elimina i separatori, comprime le sequenze di spazi e riduce le lettere a un’unica combinazione di maiuscole e minuscole. Il suo effetto è che due copie formattate in modo diverso di un unico valore diventano la stessa stringa, ed è ciò che rende significativi il rilevamento dei duplicati e i test di uguaglianza.
Due avvertenze meritano di essere tenute a mente. Normalizzare non è riparare, perché elimina la presentazione anziché gli errori, quindi non salverà mai un carattere digitato male. E non è nemmeno una misura di sicurezza: una routine che confronta stringhe normalizzate sta comunque confrontando input non attendibile.
Per gli sviluppatori: come organizzare una catena di validazione
Modella la catena come una sequenza di passi puri, ciascuno dei quali restituisce un risultato insieme a una motivazione, anziché come un unico booleano che ingoia ogni distinzione.
- Normalizza l’input grezzo e conserva la forma normalizzata accanto all’originale.
- Verifica il set di caratteri e rifiuta qualsiasi cosa ne stia fuori prima che venga eseguita qualsiasi aritmetica.
- Verifica la lunghezza rispetto allo schema scelto dal chiamante.
- Calcola il carattere di controllo e confrontalo.
- Restituisci un giudizio che separi una prova fallita da uno schema sconosciuto.
Conserva la motivazione, non solo l’esito. Un campo che dice soltanto che il valore non è valido costringe l’utente a indovinare, mentre uno che dice che il formato corrispondeva ma il carattere finale no gli dice cosa cambiare. Dove per il valore non esiste alcuna regola, dillo chiaramente invece di riutilizzare la formulazione del fallimento; la panoramica degli algoritmi per cifre di controllo mostra quanta varietà si cela dietro l’ultimo livello, e se il campo contiene un numero di carta le regole specifiche per le carte appartengono alla guida sull’algoritmo di Luhn e non a questa.
Infine, mantieni le regole come dati. Quando uno schema cambia la sua lunghezza o la sua aritmetica, un aggiornamento dovrebbe essere una modifica a una descrizione della regola, non una modifica alla logica che la legge.
Passi successivi
Prendi un campo numerico del tuo prodotto e annota quale dei tre livelli lo protegge attualmente. Poi incolla un valore che soddisfa il formato ma fallisce l’aritmetica nello strumento di validazione dei numeri e leggi il giudizio che restituisce; la differenza tra una prova fallita e uno schema non riconosciuto è la distinzione che molti moduli ancora confondono.