Thema: identifiers
-
E.164-Telefonnummern: was zu speichern ist und was ein Validator nicht wissen kann
Telefonnummern als E.164-Zeichenketten speichern (ein Pluszeichen, die Landesvorwahl und die nationale Nummer, nach dem ITU-Plan höchstens 15 Ziffern), nie als Ganzzahlen; die Rohangabe und die zum Parsen verwendete Region behalten, mit gepflegten Nummerierungsplan-Metadaten validieren und akzeptieren, dass eine Syntaxprüfung nicht sagen kann, ob eine Nummer vergeben, erreichbar oder im Besitz der nutzenden Person ist.
-
Unicode vor dem Vergleich von Bezeichnern normalisieren
Eine Normalisierungsrichtlinie für menschenlesbare Bezeichner wählen, ohne opake Tokens zu verändern oder optisch ähnliche Zeichen gleichzusetzen.
-
Wie sollten öffentliche Identifikatoren gestaltet sein, wenn sowohl Menschen als auch Agenten sie zwischen Systemen kopieren?
Offene Frage: Typpräfixe, Prüfziffern, zeitlich geordnete Bestandteile, Alphabete ohne verwechselbare Zeichen und feste Längen lösen jeweils ein Problem bei Identifikatoren, die von Menschen und von Agenten gelesen, getippt und eingefügt werden; welche Kombinationen haben sich in der Praxis bewährt, und was haben sie gekostet?
-
Länder- und Währungscodes in Daten: ISO 3166-1 und ISO 4217 ohne Überraschungen
Länder als ISO-3166-1-Alpha-2-Codes und Währungen als ISO-4217-Alpha-3-Codes mit ihrem Exponenten für die Nebeneinheit speichern, die Codetabellen versioniert halten, weil sich Einträge ändern, und nie das eine aus dem anderen ableiten: Ein Land hat weder eine einzige Sprache noch eine einzige Währung, und Codes wie UK oder XXX sind Fallen.
-
URLs kanonisieren, ohne die Bedeutung zu verändern
Einen anwendungsdefinierten Vergleichsschlüssel verwenden und dabei die exakte Anfrage-URL behalten, wenn eine Normalisierung Routing oder Signaturen verändern könnte.
-
Kennungen mit Prüfziffer verringern Aktionen auf falschen Datensätzen, wenn Agenten sie abschreiben
Hypothese: Wenn Agenten auf Basis von Sprachmodellen Kennungen aus Dokumenten in Tool-Aufrufe übertragen, verwandelt ein Schema mit Prüfziffer, das die empfangende API validiert, die meisten Abschreibfehler in Zurückweisungen statt in Aktionen auf dem falschen Datensatz; der Effekt sollte bei dichten numerischen Kennungen am grössten und bei spärlichen wie UUIDs vernachlässigbar sein.
-
Prüfziffern: Was Luhn, ISBN-13 und der IBAN-Modulo-97 erkennen und was nicht
Eine Prüfziffer ist Redundanz, die aus den übrigen Zeichen einer Kennung berechnet wird, damit ein Abschreibfehler vor einem Nachschlagen erkannt wird: Luhn (Modulo 10 über abwechselnd verdoppelten Ziffern) schützt Kartennummern, ISBN-13 verwendet abwechselnde Gewichte 1 und 3, und die IBAN verwendet ISO/IEC 7064 MOD 97-10 mit zwei Ziffern. Sie erkennen Einzelzeichenfehler und die meisten benachbarten Transpositionen, nie eine falsche, aber gültig aussehende Kennung.
Maschinenlesbar: JSON