Postcodeformaten zijn een van de eerste dingen die een internationaal formulier verkeerd doet. Een veld dat een paar cijfers accepteert en het daarbij laat, wijst hele landen af, beschadigt andere geruisloos en laat gegevens door die geen enkele postoperator zou herkennen. De regels zijn niet ingewikkeld, maar ze zijn lokaal, en er is geen enkel patroon dat de hele wereld dekt.
Dit artikel loopt door de belangrijkste families van postcodes die in gebruik zijn, de plaatsen die er geen hebben, de terugkerende valkuilen rond voorloopnullen en lengte, en wat je in een formulier of database moet doen zodat de gegevens het contact met echte gebruikers overleven.
De vier families van postcodes
De meeste postcodes vallen in een van vier brede vormen. De grenzen zijn vaag — een land kan zijn systeem wijzigen en een code kan tot meer dan één familie behoren — maar de families zijn een nuttige manier om over validatie na te denken.
- Pure cijfers van een vaste lengte. Veel landen gebruiken een reeks cijfers, meestal vier tot zes. De lengte is binnen het land vast, wat een eenvoudige lengtecontrole haalbaar maakt.
- Cijfers met een vaste structuur. Noord-Amerikaanse codes splitsen in twee delen, en het tweede deel is in de praktijk optioneel, dus hetzelfde adres kan een korte of een lange versie hebben.
- Letters gemengd met cijfers. Canada, het Verenigd Koninkrijk, Nederland en Ierland zijn bekende voorbeelden. Sommige daarvan wisselen letters en cijfers af in een vast ritme; andere groeperen tekens in segmenten met een eigen betekenis.
- Gebiedscode plus bezorgpunt. Het Verenigd Koninkrijk en Nederland zijn de klassieke voorbeelden: het leidende segment duidt een district of plaats aan, het volgende segment vernauwt tot een straat of een kleine groep adressen.
Een vijfde categorie is even belangrijk: landen en gebieden zonder enig postcodesysteem. Daar om een postcode vragen is geen validatieprobleem dat je moet oplossen, maar een vraag die nooit gesteld had mogen worden.
Welke landen hebben geen postcodes?
Nogal wat, waaronder verschillende plaatsen waar mensen vaak post naartoe sturen. Waar geen postsysteem is, dwingt een formulier dat op een waarde staat de gebruiker er een te verzinnen — en de vrijwel universele verzinsel is een reeks nullen of een herhaling van één cijfer. Het resultaat is een database vol plaatsvervangende waarden die op data lijken en geen informatie bevatten.
Het praktische antwoord in twee delen. Maak het veld ten eerste optioneel in elk formulier dat meer dan één land bedient, want optionaliteit is de enige regel die overal klopt. Genereer ten tweede, als een downstream-systeem werkelijk een waarde eist, een duidelijke plaatsvervanger en label die als zodanig in de datasetnotities, in plaats van te doen alsof het een echte code is. De landpagina’s voor de markten die je bedient zijn een snelle manier om te zien welke conventies waar gelden.
Waarom voorloopnullen verdwijnen
Een postcode is een identificatie, geen getal. Identificaties worden vergeleken, samengevoegd, gesorteerd en gekopieerd — nooit opgeteld, nooit gemiddeld, nooit vergeleken met een groter-dan-teken. Toch is het heel gewoon om een postcodekolom als geheel getal te vinden, en die ene keuze vernietigt de voorloopnullen waarop veel nationale systemen vertrouwen.
De schade is stil. Een code die met nul begint, wordt een kortere code wanneer hij door een numerieke kolom, een spreadsheet, een JSON-getalveld of een systeem dat onbeduidende cijfers verwijdert gaat. Niets geeft een fout. De waarde houdt er simpelweg op de code te zijn die het was, en een latere postcodeopzoeking mislukt om redenen die niets te maken lijken te hebben met de import die ze veroorzaakte.
Dezelfde redenering geldt voor scheidingstekens. Sommige nationale formaten worden conventioneel met een spatie tussen segmenten geschreven, en gebruikers typen ze inconsistent. Bewaar de canonieke vorm zonder het scheidingsteken, of bewaar het scheidingsteken consistent, maar doe de normalisatie op de grens en raak het daarna niet meer aan.
Zijn postcodes en bestuurlijke gebieden hetzelfde?
Nee, en de verwarring veroorzaakt echte bugs. Een postcode beschrijft een bezorgroute, niet een overheidsgrens. Bezorggebieden en bestuurlijke gebieden overlappen, maar vallen niet samen: één postcode kan delen van twee plaatsen bestrijken, en één plaats kan meerdere codes omvatten. Codes worden opnieuw toegewezen wanneer routes veranderen, zonder dat iemand een provincie opnieuw intekent.
Dat betekent dat je niet met zekerheid een plaats of regio uit een postcode kunt afleiden. Je kunt een postcode gebruiken als zwak bewijs — hij valt meestal binnen een bekend bereik voor een regio, en een mismatch tussen een regio en een postcode is een sterk signaal dat minstens één van de twee verkeerd is getypt. Behandel het als een controle die de moeite waard is, niet als een gezaghebbende opzoeking.
Dit is ook waarom de op prefixen gebaseerde validatie die in sommige landen goed werkt, niet overdraagbaar is. Een prefixregel codeert een bezorggeografie, en de bezorggeografie van elk land is anders. Het bredere beeld wordt behandeld in de gids over adresvalidatie en -normalisatie.
Postcodes in echte formulieren
Een paar gewoonten houden een formulier eerlijk over landen heen.
- Maak het veld optioneel tenzij je zeker weet, voor een specifiek land, dat er een code bestaat en vereist is.
- Wijzig het label en de helptekst met het geselecteerde land, want de vorm van een geldige code is niet overdraagbaar.
- Accepteer bij invoer zowel de vorm met als zonder spatie, en normaliseer naar één ervan voor opslag.
- Leg wereldwijd geen vaste lengte op. Een vaste lengte is pas verdedigbaar zodra het land bekend is.
- Zet niet stilzwijgend om naar hoofdletters als een systeem ergens anders hoofdlettergevoelig is; kies één canonieke vorm en pas die consistent toe.
Een uitgewerkt voorbeeld van dezelfde cijferreeks die aan de regel van het ene land voldoet en voor het andere faalt, staat in de gids over de structuur van Amerikaanse adressen, waar de vijfcijferige en uitgebreide vormen worden beschreven.
Voor ontwikkelaars: kolommen, beperkingen en landwissels
Bewaar een postcode als tekst, op een royaal formaat, zonder enige numerieke conversie in het hele pad. Tussen acht en twaalf tekens is comfortabel voor elk systeem dat algemeen in gebruik is, en de extra ruimte kost niets vergeleken met een latere migratie. Verwijder omringende witruimte bij invoer, beslis of je interne spaties behoudt, en pas die beslissing op één plek in de code toe in plaats van bij elke verbruiker.
Houd de landcode altijd naast de postcode. Een postcode zonder zijn land is dubbelzinnig en er geldt geen enkele set validatieregels voor. Wanneer het land in een gebruikersinterface verandert, wis of hervalideer dan het postcodeveld in plaats van een waarde te laten staan die tegen de regels van het vorige land is gecontroleerd.
Wees ten slotte voorbereid op verandering. Formaten worden uitgebreid, nieuwe codes worden ingevoerd, en een systeem dat er vandaag vast uitziet kan morgen een variant krijgen. Een validatieregel moet streng genoeg zijn om duidelijke typefouten te vangen en ruim genoeg om een formaat toe te laten dat je niet had voorzien. Wanneer een code de validatie niet haalt, log dan de waarde die je hebt afgewezen — nooit het hele record — zodat je een slechte regel van een slechte invoer kunt onderscheiden.
Volgende stappen
Controleer één postcodekolom in je eigen schema en kijk of het tekst is, of het voorloopnullen tolereert en of de landcode meereist. Stel daarna een kleine fixtureset samen met een land met alleen cijfers, een land met letters en cijfers, een gesegmenteerde code en een land zonder enig postsysteem, en voer die door je formulier. De adresgenerator produceert codes in de lokale vorm van elk land dat hij dekt, wat die fixtureset snel samen te stellen maakt. Codes die voor een fixture worden geproduceerd zijn per constructie synthetisch: ze testen het formaat zonder naar een echt bezorggebied te verwijzen, en geen ervan zou op een pakket moeten belanden.