Internationales Adressformat: Zeilenreihenfolge und Feldnamen

Ein internationales Adressformat ist nicht ein Format. Es ist eine Familie von Konventionen, die sich darüber uneinig sind, was zuerst kommt, wie eine Verwaltungseinheit heißt und ob der Name des Empfängers über oder unter dem Gebäude steht. Wer ein Formular, ein Etikett oder einen bedruckten Umschlag baut, trifft diese Uneinigkeiten schnell, und die billigste Lösung — eine Vorlage mit ein paar optionalen Zeilen — hört in dem Moment auf zu funktionieren, in dem ein zweites Land dazukommt.

Dieser Artikel behandelt, wie Adressen weltweit tatsächlich geordnet werden, welche Felder variieren, warum die Schrift zählt und wie Sie die Daten so modellieren, dass Darstellungsentscheidungen von Speicherentscheidungen getrennt bleiben.

Zwei Richtungen, eine Adresse zu schreiben

Adressen werden an manchen Orten von der kleinsten Einheit nach außen geschrieben und an anderen von der größten nach innen, und diese beiden Gewohnheiten erzeugen spiegelverkehrte Zeilenreihenfolgen.

In weiten Teilen Ostasiens verläuft eine Adresse traditionell von der großen zur kleinen Einheit: zuerst Land oder Provinz, dann Stadt oder Stadtbezirk, dann Unterbezirk, dann Straße, dann Hausnummer, dann die Einheit. Westliche Konventionen laufen andersherum: Hausnummer und Straße, dann Ort, dann Region, dann Postleitzahl, dann Land. Keine der beiden Reihenfolgen ist logischer; jede gruppiert die Information so, wie es der örtliche Postdienst und der örtliche Leser erwarten.

Internationale Post setzt eine weitere Konvention obendrauf. Weil das Bestimmungsland das ist, was Sortiermaschinen zuerst brauchen, steht es traditionell als letzte Zeile, allein, in Großbuchstaben oder anderweitig hervorgehoben. Das ist eine Leitwegkonvention und keine Datenregel, und deshalb sehen gedruckte Umschläge oft ganz anders aus als die Reihenfolge, in der ein Formular die Felder abfragt.

Kann eine Vorlage jedes Land abdecken?

Nur schlecht. Eine Vorlage schreibt die Annahme fest, welche Felder existieren, welche in derselben Zeile stehen und in welcher Reihenfolge sie erscheinen — und genau diese Annahmen ändern sich zwischen Ländern.

Eine einzelne feste Vorlage stellt eine Hausnummer vor den Straßennamen in einem Land, das sie danach setzt, sie fügt ein Komma ein, wo die lokale Konvention ein Kennzeichen verwendet, oder sie reserviert eine Zeile für ein Bundesland, das die Adresse nie benutzt. Betrachten Sie die Praxis: Manche Länder lassen eine Verwaltungseinheit ganz weg und verorten eine Adresse über Ort und Postleitzahl, sodass ein Pflichtfeld für die Region Nutzer dazu zwingt, den Ort zu wiederholen oder eine Näherung zu wählen. Andere verwenden eine Ebene, für die die Vorlage kein Gegenstück hat, und der Name landet in irgendeinem freien Feld.

Die Lösung ist kleiner, als sie klingt: Halten Sie die Daten vollständig und lassen Sie die Darstellungsschicht über die Zeilenreihenfolge entscheiden. Die Reihenfolge gehört zur Präsentation, und kein Feld sollte von ihr abhängen.

Was ist der Unterschied zwischen Staat, Provinz und Präfektur?

Es sind alles Verwaltungseinheiten erster Ebene, und ihr Wort unterscheidet sich von Land zu Land — Staat, Provinz, Präfektur, Region, Kanton, Gouvernement, Emirat, Oblast. Die Beschriftung ist für den Leser wichtig und für das Datenmodell bedeutungslos, weshalb es mehr Ärger schafft als löst, alle diese Ebenen Staat zu nennen.

Die Probleme sind konkret. Ein Nutzer in einem Land, das die Einheit anders nennt, muss raten, was das Formular meint. Ein Supportskript, das Datensätze nach Staat filtert, schließt Datensätze aus, deren Einheit im Quellsystem unter einem anderen Namen liegt. Eine Prüfregel gegen eine Liste von US-Bundesstaaten weist nahezu jede Adresse außerhalb der Vereinigten Staaten zurück.

Halten Sie das Feld im Schema generisch und übersetzen Sie nur die Beschriftung zur Darstellungszeit. Speichern Sie den Wert zusammen mit seinem Ländercode, denn ein Gebietsname ist nur zusammen mit dem zugehörigen Land aussagekräftig; zwei Länder können denselben Gebietsnamen führen und verschiedene Orte meinen. Die Verwandtschaft dieser Codes beschreibt der Leitfaden zu ISO-Ländercodes und Unterteilungscodes.

Schrift, Transliteration und das stille Scheitern reiner Lateinfelder

Viele Adressen sind in einer anderen Schrift als der lateinischen geschrieben. Manche Bestimmungsländer verlangen die lokale Schrift für die Zustellung im Inland und akzeptieren eine romanisierte Fassung für den internationalen Leitweg; andere erwarten die romanisierte Form bei eingehender Post. Keine der beiden Regelungen gilt allgemein.

Zwei Dinge gehen schief, wenn ein System lateinische Zeichen voraussetzt. Das erste ist die glatte Ablehnung: Ein Zeichensatz, der nicht-lateinische Buchstaben ausschließt, macht aus einer gültigen Adresse einen Fehler, und der Nutzer kann nichts dagegen tun, weil die Adresse korrekt ist. Das zweite ist leiser — ein Feld, das die Zeichen annimmt, sie aber normalisiert, transliteriert oder abschneidet, sodass der gespeicherte Wert nicht mehr dem entspricht, was der Nutzer getippt hat, und ein späterer Vergleich scheitert.

Zeichen sind nicht die einzige Gefahr. Manche Schriften werden ohne Leerzeichen zwischen den Adressbestandteilen geschrieben, sodass ein Parser, der an Leerzeichen trennt, ein einziges riesiges Token statt sechs Felder findet. Andere verwenden ein Kennzeichen zwischen Straßenname und Hausnummer, wo lateinische Konventionen ein Leerzeichen oder ein Komma setzen. Auch die Länge ist nicht einheitlich: Eine romanisierte Adresse ist meist länger als das Original, ein auf die lokale Schrift bemessenes Feld kann also für seine eigene Transliteration zu klein sein.

Umgang mit Gebäudenamen, Einheitsnummern und Bezirken

Echte Adressen tragen Einheiten, die Vorlagen selten vorsehen: Wohnungen, Etagen, Blöcke, Türme, Eingangsnummern, Gebäudenamen, Unterbezirksnamen und Richtungsangaben in Form eines Orientierungspunkts. Die lokale Liste dieser Bezeichner unterscheidet sich ebenso stark wie die Gebietsnamen.

Zwei Regeln halten sie beherrschbar. Erfassen Sie die Einheitsangaben in einem eigenen Feld, statt sie an die Straßenzeile anzuhängen, damit die Straße für Parsing und Geokodierung erhalten bleibt. Und wenn die Adressen eines Landes üblicherweise eine Ebene enthalten, die Ihre Vorlage nicht hat — einen Bezirk unterhalb der Stadt, einen Gebäudenamen oberhalb der Straße —, fügen Sie ein Feld hinzu, statt zu verketten. Ein Feld mit einer Bedeutung ist billig; ein Feld, das für alles Übrige steht, ist der Ort, an dem Datenqualität stirbt.

Für Entwickler: ein Feld, eine Bedeutung

Das Konstruktionsprinzip, das den Kontakt mit den meisten Ländern übersteht, ist das am wenigsten clevere: Geben Sie jeder Adressinformation ein eigenes Feld mit einer Bedeutung, und lassen Sie niemals den Namen eines Feldes ein Land implizieren.

Praktisch heißt das: ein Feld für den Ländercode, ein Feld für die Verwaltungseinheit, das nicht Staat heißt, getrennte Felder für Bezirk, Ort, Straße, Hausnummer und Einheitsangaben, ein Feld für die Postleitzahl und eine freie Zeile für Informationen, die in keines davon passen. Halten Sie die Felder im Schema optional und fordern Sie das, was Sie pro Land brauchen, zum Prüfzeitpunkt ein, wenn das Land bekannt ist.

Ergänzen Sie eine Darstellungsdefinition pro Land, getrennt von den Daten: die Reihenfolge der Zeilen, welche Felder verbunden werden, ob die Verwaltungseinheit im Adressblock erscheint und wo die Postleitzahl steht. Diese Trennung erlaubt es, ein Land durch die Bearbeitung einer einzigen Definition hinzuzufügen, statt die Formularlogik neu zu öffnen. Sie sorgt außerdem dafür, dass ein Fehler im Layout keine gespeicherten Daten beschädigen kann.

Seien Sie zuletzt vorsichtig mit Verkettung. Wenn Sie für einen API-Aufruf eine einzeilige Adresse bauen, machen Sie auch das Trennzeichen zum Teil der Darstellungsdefinition, denn eine durchgängige Verknüpfung mit Komma ergibt eine Adresse, die nur in den Ländern korrekt liest, die Kommas verwenden.

Nächste Schritte

Wählen Sie drei Länder, die Sie tatsächlich bedienen, und schreiben Sie von Hand auf, wie jedes dieselbe Information ordnet. Wo die drei sich widersprechen, haben Sie die Nahtstellen gefunden, an denen Ihre Vorlage brechen wird. Erzeugen Sie dann eine Adresse pro Land im Adressgenerator und fügen Sie jede in Ihr Formular ein, um zu sehen, ob das Layout noch Sinn ergibt; der Leitfaden zu Adressdaten in Testfixtures erklärt, wie Sie diese Beispiele reproduzierbar halten. Behalten Sie im Kopf, was diese Beispiele sind: erzeugte Werte in der Form echter Adressen, gedacht zum Testen und nicht zur Zustellung, und ohne jede Aussage darüber, wo jemand tatsächlich wohnt.