Die Nummernprüfung ist die Routine, die entscheidet, ob eine Zeichenkette für ein Konto, ein Dokument oder ein Produkt stehen darf. Sie ist nicht ein einzelner Test, sondern drei Tests in fester Reihenfolge: Ist jedes Zeichen zulässig, hat die Zeichenkette die richtige Länge, und stimmt das letzte Zeichen mit der Arithmetik der Zeichen davor überein.
Jede Ebene fängt eine andere Art von Fehler ab, und jede beantwortet eine viel engere Frage, als die meisten annehmen. Dieser Beitrag geht die drei Ebenen der Reihe nach durch, erklärt, warum eine bestandene Prüfung keine Aussage über die Welt ist, und zeigt, woher die vier möglichen Urteile eines Prüfers stammen.
Was ist Nummernprüfung?
Im einfachsten Fall ist Prüfung ein Filter, der Eingaben trennt, die ein System verarbeiten kann, von solchen, die es nicht kann. Der Filter besteht aus veröffentlichten Regeln und nicht aus Geheimnissen. Deshalb kann dieselbe Prüfung im Browser, in einem nächtlichen Importlauf und neben einem gedruckten Etikett laufen, ohne dass sich die drei widersprechen.
Das Wort wird oft überdehnt und deckt dann zwei verschiedene Tätigkeiten ab. Die eine ist strukturell: Folgt diese Zeichenkette dem Format, das ihr Schema festlegt? Die andere ist faktisch: Wurde diese Nummer jemals ausgegeben, und an wen? Nur die erste gehört zu einem Prüfer. Die zweite verlangt einen Abgleich mit dem Register, das den Wert ausgegeben hat, und eine Offline-Routine kann das nicht leisten.
Diese beiden Dinge auseinanderzuhalten ist der eigentliche Zweck der Übung. Ein Formular, das eine bestandene Struktur als bestätigte Identität meldet, lässt Unsinn mit Überzeugung durch, und die Nutzerin oder der Nutzer glaubt es.
Jede Nummer und jede Zeichenkette in diesem Beitrag ist eine bewusst konstruierte Illustration. Sie zeigt nur, wie sich die drei Ebenen verhalten. Keine davon steht für ein echtes Konto, ein echtes Dokument oder ein echtes Paket, und eine bestandene Prüfung in einer Illustration ist niemals ein Beleg dafür, dass ein solcher Datensatz existiert.
Drei Filterebenen: Zeichensatz, Länge und Prüfziffer
Die Ebenen sind billig auszuführen, und jede ist blind für die Fehler, die die anderen fangen.
| Ebene | Die Frage | Was sie fängt | Was sie übersieht |
|---|---|---|---|
| Zeichensatz | Sind alle Zeichen hier zulässig? | Buchstaben in einem Zahlenfeld, fremde Symbole, eingefügte Formatierungszeichen | Eine falsche Ziffer, die selbst zulässig ist |
| Länge | Hat die Zeichenkette die Größe, die das Schema erlaubt? | Ein beim Tippen verlorenes oder doppeltes Zeichen | Eine gleich lange Zeichenkette mit zwei vertauschten Nachbarn |
| Prüfziffer | Folgt die letzte Stelle aus dem Rest? | Die meisten Einzelzeichenfehler und viele Nachbarvertauschungen | Jeden Wert, der nie ausgegeben wurde |
Die Reihenfolge zählt so viel wie der Inhalt. Zuerst normalisieren, dann den Zeichensatz prüfen, dann die Länge, und erst danach rechnen. Eine Routine, die die Prüfziffer berechnet, bevor sie Leerzeichen entfernt, weist einwandfreie Werte zurück, und sie tut das mit einer Meldung, die auf ein Problem zeigt, das es nicht gibt.
Warum macht ein bestandenes Format eine Nummer nicht echt?
Eine Prüfziffer ist eine arithmetische Zusammenfassung der Zeichen vor ihr. Sie wird allein aus diesen Zeichen berechnet und belegt deshalb innere Stimmigkeit und nichts darüber hinaus. Wer die veröffentlichte Regel kennt, kann eine Zeichenkette erzeugen, die sie erfüllt; genau das tut ein Generator absichtlich.
Was die Prüfung nicht sehen kann, ist das Register. Ob ein Konto offen ist, ob ein Dokument je gedruckt wurde, ob ein Produkt je verpackt wurde — all das liegt in einer Datenbank bei einer Stelle, auf die der Prüfer keinen Zugriff hat. Ein Wert kann jede Offline-Ebene erfüllen und trotzdem zu gar nichts gehören; der Beitrag zu den Regeln für Ausweisnummern nach Land arbeitet durch, was das besonders für Identifikationsschemata bedeutet.
Behandeln Sie ein Urteil als Aussage über die Zeichenkette, nie über die Welt. Diese Haltung hält Fehlermeldungen ehrlich und hindert Prüfer daran, mehr in ein grünes Häkchen hineinzulesen, als es tragen kann.
Eine Nummer kann zu mehreren Schemata gehören
Schemata überschneiden sich. Zwei unabhängige Nummernsysteme können sich beim erlaubten Zeichensatz, bei der Gesamtlänge und sogar bei der Arithmetik des letzten Zeichens einig sein. Dann ist dieselbe Zeichenkette ein echter Bestandteil beider. Das ist kein Mangel, sondern das Ergebnis davon, dass getrennte Entwerfer zu ähnlichen Konventionen greifen.
Ein Prüfer, der ein einziges geratenes Land nennt, verdeckt diese Mehrdeutigkeit und erfindet eine Information, die er nicht hat. Eine bessere Oberfläche listet jedes Schema auf, das die Zeichenkette tatsächlich erfüllt, und überlässt es der Leserin, welches Register sie als Nächstes heranzieht. Dieselbe Überlegung gilt umgekehrt, wenn nichts passt: Die ehrliche Antwort ist, dass keine implementierte Regel die Eingabe kennt, nicht dass der Wert falsch wäre. Eine völlig echte Nummer kann schlicht außerhalb der Regeln liegen, die ein Werkzeug kennt; das ist das Thema von Nummern ohne Prüfziffer.
Normalisierung: Leerzeichen, Bindestriche und Groß- und Kleinschreibung
Echte Eingaben kommen für das menschliche Auge formatiert an. Kontonummern werden in Gruppen gedruckt, Identitätswerte tragen Punkte und Schrägstriche, und Etiketten mischen Groß- und Kleinschreibung. Nichts davon gehört zur Nummer, und alles davon muss verschwinden, bevor verglichen wird.
Normalisierung entfernt die Trennzeichen, fasst Folgen von Leerraum zusammen und vereinheitlicht die Schreibweise der Buchstaben. Ihr Effekt ist, dass zwei unterschiedlich formatierte Kopien desselben Werts dieselbe Zeichenkette werden. Erst dadurch werden Dublettenerkennung und Gleichheitstests überhaupt sinnvoll.
Zwei Warnungen sind nützlich. Normalisieren ist keine Reparatur, denn es entfernt Darstellung und nicht Fehler; ein vertipptes Zeichen rettet es nie. Und es ist auch keine Sicherheitsmaßnahme: Eine Routine, die normalisierte Zeichenketten vergleicht, vergleicht weiterhin nicht vertrauenswürdige Eingaben.
Für Entwickler: Wie ordnet man eine Prüfkette an?
Modellieren Sie die Kette als Folge reiner Schritte, von denen jeder ein Ergebnis samt Begründung zurückgibt, statt als einen Wahrheitswert, der jede Unterscheidung verschluckt.
- Normalisieren Sie die Roheingabe und bewahren Sie die normalisierte Form neben dem Original auf.
- Prüfen Sie den Zeichensatz und weisen Sie alles außerhalb davon zurück, bevor Arithmetik läuft.
- Prüfen Sie die Länge gegen das Schema, das die aufrufende Stelle gewählt hat.
- Berechnen Sie das Prüfzeichen und vergleichen Sie es.
- Geben Sie ein Urteil zurück, das eine fehlgeschlagene Prüfung von einem unbekannten Schema trennt.
Behalten Sie die Begründung, nicht nur das Ergebnis. Ein Feld, das lediglich meldet, der Wert sei ungültig, zwingt zum Raten; eines, das sagt, das Format passe, aber das letzte Zeichen nicht, sagt, was zu ändern ist. Wo für den Wert überhaupt keine Regel existiert, sagen Sie das offen, statt dieselbe Fehlerformulierung wiederzuverwenden. Die Übersicht der Prüfziffernverfahren zeigt, wie viel Vielfalt hinter der letzten Ebene steckt; und wenn das Feld eine Kartennummer trägt, gehören die kartenspezifischen Regeln zum Luhn-Verfahren und nicht hierher.
Schließlich: Halten Sie die Regeln als Daten. Wenn ein Schema seine Länge oder seine Arithmetik ändert, soll die Anpassung eine Änderung an einer Beschreibung der Regel sein und nicht an der Logik, die sie liest.
Nächste Schritte
Nehmen Sie ein numerisches Feld in Ihrem Produkt und notieren Sie, welche der drei Ebenen es derzeit absichert. Fügen Sie dann einen Wert ein, der das Format erfüllt, aber an der Arithmetik scheitert, im Werkzeug zur Nummernprüfung und lesen Sie das Urteil, das es zurückgibt. Der Unterschied zwischen einer fehlgeschlagenen Prüfung und einem unbekannten Schema ist genau die Unterscheidung, die viele Formulare noch verwischen.