Validazione e normalizzazione degli indirizzi vengono trattate come un’unica attività nella maggior parte dei progetti, e la confusione costa ai team tempo reale. Una delle due riformatta un valore affinché due grafie dello stesso indirizzo coincidano; l’altra cerca di rispondere se l’indirizzo esista e sia recapitabile. Usano dati diversi, falliscono in modi diversi e — in una suite di test — meritano asserzioni del tutto differenti.
Questo articolo separa le due, spiega perché nessuna autorità detiene un elenco globale completo di indirizzi e descrive che cosa un sistema può onestamente affermare dopo aver eseguito l’una o l’altra.
Che cosa fa effettivamente la normalizzazione
La normalizzazione è una riscrittura. Prende ciò che un utente ha digitato e ne produce una versione canonica: maiuscole/minuscole coerenti, tipi di via espansi o abbreviati secondo un’unica convenzione, parole direzionali standardizzate, un separatore coerente, spazi bianchi eliminati e un codice postale scritto in una forma concordata. Nulla viene verificato. Una stringa che non è mai corrisposta ad alcun luogo reale si normalizza altrettanto ordinatamente di una corretta.
Il suo valore è il confronto. Due record che descrivono lo stesso luogo ma sono stati digitati diversamente diventano identici byte per byte dopo la normalizzazione, così la deduplicazione, l’abbinamento e la ricerca iniziano a funzionare. Stabilizza anche la memorizzazione: una sola forma nel database significa che i consumatori a valle smettono di reimplementare le regole.
La normalizzazione è economica, deterministica e sicura da eseguire ovunque. Quella combinazione è il motivo per cui appartiene al confine più precoce che i dati attraversano — il gestore del modulo, lo script di importazione, il punto di ingresso dell’API — e una sola volta. Normalizzare ripetutamente in livelli diversi è il modo in cui un valore finisce per oscillare tra due grafie.
Che cosa cerca davvero di provare la validazione?
La validazione chiede se un valore sia accettabile, e la risposta onesta dipende interamente da quante prove hai. Tre domande diverse si nascondono dietro la singola parola.
La prima è strutturale: i campi obbligatori esistono, i caratteri sono nell’insieme consentito, la lunghezza è plausibile. Non richiede alcun dato di riferimento e può essere eseguita ovunque.
La seconda è relazionale: il codice postale rientra in un intervallo usato dalla regione dichiarata, il codice di stato è coerente con esso, il paese concorda con il suo codice di suddivisione. Richiede dati di riferimento ma non un database di indirizzi, e intercetta una larga parte dei veri errori di battitura.
La terza è esistenziale: esiste davvero un edificio a questo numero su questa via. Richiede un dataset locale autorevole, e solo alcuni paesi ne pubblicano uno abbastanza completo da rispondere.
La maggior parte dei sistemi rivendica la terza e implementa la seconda. Non è necessariamente sbagliato, ma dovrebbe essere una decisione consapevole anziché un incidente, perché determina che cosa il messaggio di errore può onestamente dire.
| Domanda | Che cosa chiede | Di che cosa ha bisogno |
|---|---|---|
| Strutturale | Se i campi obbligatori esistono, i caratteri sono nell’insieme consentito e la lunghezza è plausibile | Nessun dato di riferimento |
| Relazionale | Se il codice postale rientra in un intervallo usato dalla regione dichiarata, il codice di stato è coerente con esso e il paese concorda con il suo codice di suddivisione | Dati di riferimento, ma non un database di indirizzi |
| Esistenziale | Se esiste davvero un edificio a questo numero su questa via | Un dataset locale autorevole, che solo alcuni paesi pubblicano |
Esiste una cosa come un database globale degli indirizzi?
Non uno che sia completo, autorevole e aggiornato. Gli operatori postali mantengono i propri dati di consegna per i propri territori, secondo i propri termini, e molti non pubblicano affatto un elenco a livello di indirizzo. Dove esistono dataset nazionali, coprono quel paese, nella lingua e nella struttura di quel paese. Non esiste un registro unico che un fornitore possa consultare per decidere se un indirizzo arbitrario in qualsiasi parte del mondo esista.
Ciò che i fornitori fanno effettivamente, in varie combinazioni: usano i propri dati di riferimento aggregati, confrontano con codici postali e geografie amministrative, applicano regole di plausibilità e — per alcuni paesi — usano un dataset locale con licenza. Ognuno di questi è parziale. Un servizio che segnala un indirizzo come valido di solito segnala che esso appare coerente con ciò che il servizio conosce, e un servizio che lo segnala come non valido può semplicemente non avere copertura.
La conclusione pratica è che “indirizzo verificato” non è un’affermazione che il tuo sistema possa sostenere a livello globale. “Strutturalmente valido e coerente con i dati di riferimento a nostra disposizione” è un’affermazione che può sostenere, ed è quella che vale la pena mettere nella documentazione.
Perché l’ordine conta: normalizza, poi controlla
Esegui prima la normalizzazione. I controlli di riferimento sono scritti rispetto a una forma canonica, quindi un valore non normalizzato li fallirà per motivi che non hanno nulla a che fare con la correttezza: un codice postale con il separatore in un punto diverso, un tipo di via abbreviato diversamente, una differenza di maiuscole in un nome di regione.
L’ordine inverso è peggio che inutile. Se il controllo di riferimento viene eseguito per primo e respinge il valore, perdi la possibilità di correggere una stringa che era solo disordinata, e l’utente vede un errore su cui non può agire. Se viene eseguito per primo e accetta, hai comunque bisogno della normalizzazione dopo, quindi non si risparmia nulla.
Una seconda regola di ordinamento vale per la gestione degli errori. Distingui “questo non è stato interpretabile” da “questo è in conflitto con i dati di riferimento” e da “questo non è nella nostra copertura”. I tre richiedono messaggi diversi e azioni di seguito diverse, e ridurli a un unico fallimento è ciò che fa sembrare arbitraria la validazione degli indirizzi agli occhi degli utenti.
Per gli sviluppatori: regole, forzature e fixture
Non cercare di validare un indirizzo con un’unica espressione regolare. La variazione vive nelle parti in cui un’espressione regolare è peggiore — nomi di via, dettagli di unità, scritture non latine — e la certezza vive nelle parti che puoi controllare rispetto a un elenco. Riserva i pattern ai controlli di lunghezza e di caratteri, e tieni i controlli di riferimento nei dati.
Consenti sempre una forzatura manuale. I dati di riferimento sono incompleti e talvolta sbagliati, e un indirizzo genuinamente corretto che il tuo verificatore non riconosce deve restare utilizzabile. Registra la forzatura insieme al valore rifiutato, così puoi dire se il verificatore stia migliorando o semplicemente infastidendo le persone.
Mantieni normalizzazione e validazione come passaggi separati nel tuo codice, con nomi separati. Una funzione chiamata address-check che a volte riscrive il suo input e a volte lo rifiuta è il tipo di cosa che rende i bug non tracciabili. La stessa separazione è ciò che rende possibile eseguire la normalizzazione su record storici lasciando la validazione come cancello di ingresso, una distinzione familiare a chi costruisce dati di indirizzo per fixture di test.
Per una suite di test, verifica i due comportamenti in modo indipendente: che un dato input disordinato si normalizzi in una stringa canonica attesa, e che una data coppia incoerente di campi venga rifiutata. Quando l’elenco di riferimento cambia, solo il secondo insieme di test deve spostarsi.
Passi successivi
Scrivi in una frase quale delle tre domande il tuo sistema risponde effettivamente oggi, e controlla se i tuoi messaggi di errore rivendichino più di questo. Poi aggiungi una fixture per un indirizzo corretto che il tuo verificatore respinge, e decidi che cosa dovrebbe succedergli. Il generatore di indirizzi produce valori strutturalmente validi per costruzione, il che lo rende una comoda linea di base positiva accanto ai campioni volutamente rotti che conservi. Strutturalmente validi è tutto ciò che sono: quei valori non possono essere recapitati a una destinazione e non provano nulla sulla residenza. Per una spiegazione dettagliata di un’incongruenza facile da individuare, vedi i casi di test del modulo di indirizzo al checkout.