Adressvalidierung und Normalisierung gelten in den meisten Projekten als eine Tätigkeit, und die Verwechslung kostet Teams echte Zeit. Die eine formatiert einen Wert um, damit zwei Schreibweisen derselben Adresse übereinstimmen; die andere versucht zu beantworten, ob die Adresse existiert und ob an sie zugestellt werden kann. Sie nutzen unterschiedliche Daten, scheitern auf unterschiedliche Weise und verdienen in einer Testsuite völlig unterschiedliche Zusicherungen.
Dieser Artikel trennt beides, erklärt, warum keine Stelle eine vollständige globale Adressliste führt, und beschreibt, was ein System nach dem einen oder dem anderen Schritt ehrlicherweise behaupten darf.
Was Normalisierung tatsächlich tut
Normalisierung ist ein Umschreiben. Sie nimmt, was ein Nutzer getippt hat, und erzeugt davon eine kanonische Fassung: einheitliche Groß- und Kleinschreibung, nach einer Konvention ausgeschriebene oder abgekürzte Straßenarten, vereinheitlichte Richtungswörter, ein einheitliches Trennzeichen, entfernte Leerzeichen und eine Postleitzahl in einer vereinbarten Form. Nichts davon wird überprüft. Eine Zeichenkette, die nie einem echten Ort entsprach, lässt sich genauso ordentlich normalisieren wie eine korrekte.
Ihr Wert liegt im Vergleich. Zwei Datensätze, die denselben Ort beschreiben, aber unterschiedlich erfasst wurden, werden nach der Normalisierung byteweise identisch, sodass Deduplizierung, Abgleich und Suche zu arbeiten beginnen. Sie stabilisiert außerdem die Speicherung: eine Form in der Datenbank bedeutet, dass nachgelagerte Konsumenten die Regeln nicht neu implementieren.
Normalisierung ist billig, deterministisch und überall sicher auszuführen. Diese Kombination ist der Grund, warum sie an die früheste Grenze gehört, die die Daten überqueren — den Formularhandler, das Importsktipt, den Einstiegspunkt der API —, und zwar nur einmal. Wiederholtes Normalisieren in verschiedenen Schichten ist der Weg, auf dem ein Wert zwischen zwei Schreibweisen hin und her pendelt.
Was versucht Validierung tatsächlich zu beweisen?
Validierung fragt, ob ein Wert akzeptabel ist, und die ehrliche Antwort hängt vollständig davon ab, wie viele Belege Sie haben. Drei verschiedene Fragen verstecken sich hinter dem einen Wort.
Die erste ist struktureller Art: Existieren die erforderlichen Felder, liegen die Zeichen im erlaubten Satz, ist die Länge plausibel. Dafür braucht es überhaupt keine Referenzdaten, und sie lässt sich überall beantworten.
Die zweite ist relational: Liegt die Postleitzahl in einem Bereich, den die angegebene Region verwendet, ist das Bundesstaatskürzel damit vereinbar, passt das Land zu seinem Unterteilungscode. Dafür braucht es Referenzdaten, aber keine Adressdatenbank, und sie erkennt einen großen Teil echter Tippfehler.
Die dritte ist existenziell: Steht an dieser Nummer in dieser Straße tatsächlich ein Gebäude. Dafür braucht es einen autoritativen lokalen Datensatz, und nur manche Länder veröffentlichen einen, der vollständig genug ist, um die Frage zu beantworten.
Die meisten Systeme behaupten die dritte und implementieren die zweite. Das ist nicht zwangsläufig falsch, sollte aber eine bewusste Entscheidung sein und kein Zufall, denn sie bestimmt, was die Fehlermeldung ehrlicherweise sagen darf.
| Frage | Was sie fragt | Was sie braucht |
|---|---|---|
| Strukturell | Ob die erforderlichen Felder existieren, die Zeichen im erlaubten Satz liegen und die Länge plausibel ist | Überhaupt keine Referenzdaten |
| Relational | Ob die Postleitzahl in einen Bereich der angegebenen Region fällt, das Bundesstaatskürzel dazu passt und das Land zu seinem Unterteilungscode | Referenzdaten, aber keine Adressdatenbank |
| Existenziell | Ob an dieser Nummer in dieser Straße tatsächlich ein Gebäude steht | Einen autoritativen lokalen Datensatz, den nur manche Länder veröffentlichen |
Gibt es so etwas wie eine globale Adressdatenbank?
Keine, die vollständig, autoritativ und aktuell wäre. Postbetreiber pflegen eigene Zustelldaten für eigene Gebiete, zu eigenen Bedingungen, und viele von ihnen veröffentlichen überhaupt keine Liste auf Adressebene. Wo nationale Datensätze existieren, decken sie ihr Land ab, in der Sprache und Struktur dieses Landes. Es gibt kein einziges Register, das ein Anbieter befragen könnte, um zu entscheiden, ob eine beliebige Adresse irgendwo auf der Welt existiert.
Was Anbieter tatsächlich tun, in wechselnden Kombinationen: Sie nutzen eigene aggregierte Referenzdaten, gleichen gegen Postleitzahl- und Verwaltungsgeografien ab, wenden Plausibilitätsregeln an und verwenden für manche Länder einen lizenzierten lokalen Datensatz. Jeder dieser Wege ist teilweise. Ein Dienst, der eine Adresse als gültig meldet, meldet meist, dass sie mit dem übereinstimmt, was der Dienst kennt, und ein Dienst, der sie als ungültig meldet, hat womöglich einfach keine Abdeckung.
Die praktische Schlussfolgerung ist, dass Adresse verifiziert keine Behauptung ist, die Ihr System global stützen kann. Strukturell gültig und mit den uns verfügbaren Referenzdaten vereinbar ist eine Behauptung, die es stützen kann, und genau diese gehört in die Dokumentation.
Warum die Reihenfolge zählt: erst normalisieren, dann prüfen
Führen Sie die Normalisierung zuerst aus. Referenzprüfungen sind gegen eine kanonische Form geschrieben, ein nicht normalisierter Wert wird sie also aus Gründen verfehlen, die nichts mit Korrektheit zu tun haben: eine Postleitzahl mit dem Trennzeichen an anderer Stelle, eine anders abgekürzte Straßenart, ein Unterschied in der Groß- und Kleinschreibung eines Regionsnamens.
Die umgekehrte Reihenfolge ist schlimmer als nutzlos. Läuft die Referenzprüfung zuerst und weist den Wert zurück, verlieren Sie die Gelegenheit, eine bloß unordentliche Zeichenkette zu reparieren, und der Nutzer sieht einen Fehler, auf den er nicht reagieren kann. Läuft sie zuerst und akzeptiert, brauchen Sie die Normalisierung danach trotzdem — nichts ist gewonnen.
Eine zweite Ordnungsregel gilt für die Fehlerbehandlung. Unterscheiden Sie Dies ließ sich nicht parsen von Das widerspricht den Referenzdaten von Das liegt außerhalb unserer Abdeckung. Die drei brauchen unterschiedliche Meldungen und unterschiedliche Folgeschritte, und sie zu einem einzigen Fehlschlag zu verschmelzen ist das, was Adressvalidierung für Nutzer willkürlich wirken lässt.
Für Entwickler: Regeln, Übersteuerungen und Fixtures
Versuchen Sie nicht, eine Adresse mit einem einzigen regulären Ausdruck zu prüfen. Die Variation steckt in den Teilen, für die ein regulärer Ausdruck am schlechtesten geeignet ist — Straßennamen, Einheitsangaben, nicht-lateinische Schriften —, und die Gewissheit steckt in den Teilen, die Sie gegen eine Liste prüfen können. Sparen Sie Muster für Längen- und Zeichenprüfungen auf und halten Sie die Referenzprüfungen in Daten.
Erlauben Sie immer eine manuelle Übersteuerung. Referenzdaten sind unvollständig und manchmal falsch, und eine wirklich korrekte Adresse, die Ihr Prüfer nicht erkennt, muss lebensfähig bleiben. Protokollieren Sie die Übersteuerung zusammen mit dem abgelehnten Wert, damit Sie erkennen können, ob der Prüfer besser wird oder Menschen nur ärgert.
Halten Sie Normalisierung und Validierung in Ihrem eigenen Code als getrennte Schritte mit getrennten Namen. Eine Funktion namens Adressprüfung, die ihre Eingabe manchmal umschreibt und manchmal ablehnt, ist genau die Sorte Ding, die Fehler unauffindbar macht. Dieselbe Trennung ermöglicht es, Normalisierung über historische Datensätze laufen zu lassen, während die Validierung als Eingangstor bleibt — eine Unterscheidung, die jeder kennt, der Adressdaten für Testfixtures aufbaut.
Prüfen Sie für eine Testsuite die beiden Verhaltensweisen unabhängig voneinander: dass eine gegebene unordentliche Eingabe zu einer erwarteten kanonischen Zeichenkette normalisiert wird und dass ein gegebenes inkonsistentes Feldpaar zurückgewiesen wird. Wenn sich die Referenzliste ändert, darf sich nur der zweite Satz Tests bewegen.
Nächste Schritte
Schreiben Sie in einem Satz auf, welche der drei Fragen Ihr System heute tatsächlich beantwortet, und prüfen Sie, ob Ihre Fehlermeldungen mehr behaupten. Legen Sie dann eine Fixture für eine korrekte Adresse an, die Ihr Prüfer zurückweist, und entscheiden Sie, was mit ihr geschehen soll. Der Adressgenerator erzeugt Werte, die von der Konstruktion her strukturell gültig sind, was ihn zu einer bequemen positiven Grundlinie neben den absichtlich fehlerhaften Beispielen macht, die Sie pflegen. Strukturell gültig ist auch alles, was sie sind: Diese Werte lassen sich an kein Ziel zustellen und belegen nichts über einen Wohnort. Ein Durchlauf durch eine leicht erkennbare Unstimmigkeit findet sich in den Testfällen für Checkout-Adressformulare.