Un formato di indirizzo internazionale non è un formato unico. È una famiglia di convenzioni che non concordano su che cosa venga prima, su come si chiami una divisione e se il nome del destinatario stia sopra o sotto l’edificio. Chiunque costruisca un modulo, un’etichetta o una busta stampata incontra presto queste divergenze, e la soluzione più economica — un unico modello con un paio di righe facoltative — smette di funzionare appena si aggiunge un secondo paese alla lista.
Questo articolo tratta come gli indirizzi siano effettivamente ordinati nel mondo, quali campi variano, perché la scrittura conti e come modellare i dati affinché le decisioni di visualizzazione restino separate da quelle di memorizzazione.
Due direzioni nello scrivere un indirizzo
Gli indirizzi vengono scritti dalla più piccola unità verso l’esterno in alcuni luoghi e dalla più grande verso l’interno in altri, e le due abitudini producono ordini di righe speculari.
In gran parte dell’Asia orientale un indirizzo tradizionalmente va dalla grande unità alla piccola: prima paese o provincia, poi città o circoscrizione, poi distretto, poi via, poi numero civico, poi l’unità. Le convenzioni occidentali procedono nel senso opposto: numero civico e via, poi città, poi regione, poi codice postale, poi paese. Nessun ordine è più logico; ciascuno raggruppa le informazioni come se le aspettano il servizio postale locale e il lettore locale.
La posta internazionale aggiunge un’ulteriore convenzione. Poiché il paese di destinazione è ciò di cui i macchinari di smistamento hanno bisogno per primo, esso viene tradizionalmente collocato come riga finale, da solo, in maiuscolo o comunque in evidenza. È una convenzione di instradamento, non una regola di dati, ed è per questo che le buste stampate spesso non assomigliano affatto all’ordine in cui un modulo raccoglie i campi.
| Convenzione | Dove è l’abitudine | Ordine delle righe |
|---|---|---|
| Unità grande verso l’esterno | Gran parte dell’Asia orientale | Paese o provincia, poi città o circoscrizione, poi distretto, poi via, poi numero civico, poi l’unità |
| Unità piccola verso l’esterno | Convenzioni occidentali | Numero civico e via, poi città, poi regione, poi codice postale, poi paese |
| Convenzione di instradamento | Posta internazionale | Il paese di destinazione per ultimo, da solo, in maiuscolo o comunque in evidenza |
Un unico modello può gestire ogni paese?
Solo male. Un modello codifica in modo rigido un’ipotesi su quali campi esistano, quali stiano sulla stessa riga e in che ordine compaiano, e quelle ipotesi sono esattamente ciò che cambia tra i paesi.
Un unico modello fisso collocherà un numero civico davanti al nome della via in un paese che lo mette dopo, inserirà una virgola dove la convenzione locale prevede un carattere marcatore, oppure riserverà una riga per uno stato che l’indirizzo non usa mai. Considera che cosa accade nella pratica: alcuni paesi omettono abitualmente del tutto una divisione, localizzando un indirizzo tramite città e codice postale, quindi un campo regione obbligatorio costringe gli utenti a ripetere la città o a scegliere un’approssimazione. Altri usano un livello di divisione che non ha equivalente nel modello, e il nome finisce scaricato nel campo libero.
La soluzione è più piccola di quanto sembri: mantieni i dati completi e lascia che il livello di visualizzazione decida l’ordine delle righe. L’ordinamento appartiene alla presentazione, e nessun campo dovrebbe dipendere da esso.
Qual è la differenza tra uno stato, una provincia e una prefettura?
Sono tutti divisioni amministrative di primo livello, e la parola per indicarle varia da paese a paese — stato, provincia, prefettura, regione, cantone, governatorato, emirato, oblast’. L’etichetta conta per il lettore e per nulla per il modello dati, ed è per questo che chiamarli tutti “Stato” crea più problemi di quanti ne risolva.
I problemi sono concreti. Un utente in un paese che chiama la divisione in altro modo deve indovinare che cosa significhi il modulo. Uno script di assistenza che filtra i record per stato esclude i record la cui divisione vive sotto un altro nome nel sistema di origine. Una regola di validazione verificata rispetto a un elenco di stati statunitensi respinge quasi ogni indirizzo fuori dagli Stati Uniti.
Mantieni il campo generico nello schema e localizza l’etichetta al momento della resa. Memorizza il valore insieme al suo codice paese, poiché il nome di una divisione ha senso solo accanto al paese a cui appartiene; due paesi possono condividere il nome di una divisione e indicare luoghi diversi. La somiglianza di famiglia tra questi codici è descritta nella guida ai codici ISO di paese e suddivisione.
Scrittura, traslitterazione e il fallimento silenzioso dei campi solo latini
Molti indirizzi sono scritti in una scrittura diversa da quella latina. Alcuni paesi di destinazione richiedono la scrittura locale per la consegna interna e accettano una versione romanizzata per l’instradamento internazionale; altri si aspettano la forma romanizzata sulla posta in entrata. Nessuna delle due sistemazioni è universale.
Due cose vanno storte quando un sistema presuppone caratteri latini. La prima è il rifiuto netto: un insieme di caratteri che esclude le lettere non latine trasforma un indirizzo valido in un errore, e l’utente non può porvi rimedio perché l’indirizzo è corretto. La seconda è più silenziosa: un campo che accetta i caratteri ma li normalizza, li traslittera o li tronca, cosicché il valore memorizzato non corrisponde più a ciò che l’utente ha digitato e un confronto successivo fallisce.
I caratteri non sono l’unico pericolo. Alcune scritture sono prive di spazi tra i componenti dell’indirizzo, quindi un parser che divide sugli spazi bianchi trova un unico token enorme invece di sei campi. Altre usano un marcatore tra il nome della via e il numero dove le convenzioni latine usano uno spazio o una virgola. Neanche la lunghezza è uniforme: un indirizzo romanizzato è di solito più lungo dell’originale, quindi un campo dimensionato sulla scrittura locale può essere troppo piccolo per la sua stessa traslitterazione.
Gestire nomi di edifici, numeri di unità e distretti
Gli indirizzi reali portano unità che i modelli raramente prevedono: appartamenti, piani, blocchi, torri, numeri di ingresso, nomi di edifici, nomi di sotto-distretti e indicazioni sotto forma di punto di riferimento. L’elenco locale di questi identificatori varia tanto quanto i nomi delle divisioni.
Due regole li mantengono gestibili. Raccogli i dettagli dell’unità in un campo proprio invece di accodarli alla riga della via, così la via sopravvive per l’analisi e la geocodifica. E quando gli indirizzi di un paese includono comunemente un livello che il tuo modello non ha — un distretto sotto la città, un nome di edificio sopra la via — aggiungi un campo invece di concatenare. Un campo il cui significato è una cosa sola è economico; un campo che significa “qualsiasi altra cosa ci fosse” è dove la qualità dei dati va a morire.
Per gli sviluppatori: un campo, un significato
Il principio di progettazione che sopravvive al contatto con il maggior numero di paesi è il meno ingegnoso: assegna a ogni informazione dell’indirizzo il proprio campo con un unico significato, e non lasciare mai che il nome di un campo implichi un paese.
In pratica, ciò significa un campo per il codice paese, un campo divisione che non si chiami stato, campi separati per distretto, città, via, numero civico e dettagli dell’unità, un campo per il codice postale e una riga libera per le informazioni che non rientrano in nessuno di essi. Mantieni i campi facoltativi nello schema e imponi ciò che ti serve per paese al momento della validazione, dove il paese è noto.
Aggiungi una definizione di visualizzazione per paese, tenuta separata dai dati: l’ordine delle righe, quali campi sono uniti, se la divisione compare nel blocco dell’indirizzo e dove va il codice postale. Questa separazione ti consente di aggiungere un paese modificando una definizione invece di riaprire la logica del modulo. Significa anche che un bug nel layout non può corrompere i dati memorizzati.
Infine, fai attenzione alla concatenazione. Se costruisci un indirizzo su una sola riga per una chiamata API, rendi anche il separatore parte della definizione di visualizzazione, perché unire ovunque con una virgola produce un indirizzo che si legge correttamente solo nei paesi che usano le virgole.
Passi successivi
Scegli tre paesi che servi davvero e scrivi a mano come ciascuno ordina le stesse informazioni. Dove i tre divergono, hai trovato le giunture su cui il tuo modello si spezzerà. Poi genera un indirizzo per paese nel generatore di indirizzi e incolla ciascuno nel tuo modulo per vedere se il layout ha ancora senso; la guida ai dati di indirizzo nelle fixture di test spiega come mantenere riproducibili quei campioni. Tieni a mente che cosa sono quei campioni: valori generati con la forma di indirizzi reali, pensati per i test anziché per la consegna, e privi di qualsiasi indicazione su dove viva effettivamente qualcuno.