IMEI-Prüfziffer

Jedes Mobiltelefon und viele Zellmodule tragen eine fünfzehnstellige International Mobile Equipment Identity. Die ersten vierzehn Ziffern kennzeichnen Type Allocation Code und Seriennummer; die fünfzehnte ist eine Luhn-Prüfziffer, die Eintippfehler einer einzelnen Ziffer und die meisten benachbarten Vertauschungen abfängt, bevor eine Nummer gespeichert, auf eine Verpackung gedruckt oder an ein Betreiberportal gesendet wird.

Was in den fünfzehn Ziffern einer IMEI steckt

Jedes Mobiltelefon und viele Mobilfunkmodule tragen eine fünfzehnstellige IMEI, die International Mobile Equipment Identity. Sie folgt dem Nummernplan, der für Geräte mit GSM, UMTS, LTE und 5G gilt. Die ersten acht Ziffern bilden den Typzuteilungscode, kurz TAC. Die nächsten sechs Ziffern sind die Seriennummer des Herstellers innerhalb dieses Codes. Die fünfzehnte Ziffer ist die Prüfziffer. Sie wird nicht vergeben, sondern aus den ersten vierzehn Ziffern berechnet und fängt Tippfehler ab, bevor eine Nummer gespeichert, auf einen Karton gedruckt oder an ein Portal des Netzbetreibers geschickt wird.

So rechnet das Luhn-Verfahren, und typische Stolpersteine

Gehen Sie die vierzehn Ziffern von rechts nach links durch und verdoppeln Sie jede zweite, beginnend mit der Ziffer ganz rechts. Ist ein verdoppelter Wert größer als neun, ziehen Sie neun ab. Addieren Sie alle Werte; die Prüfziffer ist zehn minus den Rest der Summe geteilt durch zehn, und aus zehn wird null. Für 49015420323751 ergibt das 8. Typische Fehler sind, mit dem Verdoppeln auf der falschen Seite zu beginnen, die Prüfziffer selbst in die Rechnung einzubeziehen oder eine Nummer mit Leerzeichen oder Bindestrichen einzufügen. Solche Eingaben werden abgelehnt, statt still bereinigt zu werden.

So wird die IMEI-Luhn-Prüfziffer berechnet

Eine IMEI hat unter dem 3GPP-Nummerierungsplan für GSM-, UMTS-, LTE- und 5G-Geräte stets fünfzehn Dezimalziffern. Die ersten acht bilden den Type Allocation Code (TAC), die nächsten sechs eine Herstellerseriennummer innerhalb dieses TAC, und die fünfzehnte ist die Prüfziffer. Ist das Doppelte einer Ziffer größer als neun, subtrahieren Sie neun (gleichwertig: Zehner und Einer des Produkts addieren).

Addieren Sie alle vierzehn gewichteten Werte; die Prüfziffer ist (10 minus diese Summe modulo 10) modulo 10, sodass die vollständige fünfzehnstellige Zahl eine durch zehn teilbare Luhn-Summe hat. Die Validierung berechnet die erwartete Ziffer aus den ersten vierzehn Zeichen neu und vergleicht sie mit der fünfzehnten — dasselbe wie eine volle Luhn-Summe über alle fünfzehn Ziffern. Der Algorithmus ist deterministisch und lokal: kein TAC-Registeraufruf, keine Uhr, keine Zufallsquelle.

Eingabevertrag, Modi und Fehlerverhalten

Senden Sie ein number-Feld, das nur die Zeichen null bis neun enthält. Falsche Länge ist ein expliziter Fehler, der Modus und gesendete Länge nennt — vierzehn für compute, fünfzehn für validate — sodass Client-Formulare «vierzehn Ziffern nötig» anzeigen können, ohne zu raten. Leere Strings, fehlendes number und ungültige mode-Werte scheitern vor jeder Luhn-Summe und werden nicht abgerechnet.

Bevorzugen Sie compute, wenn Sie Gerätenummern für Etiketten und Datenbanken erzeugen oder vervollständigen; bevorzugen Sie validate, wenn Sie eine Abfrage, einen Tausch oder einen Import an eine volle IMEI von Benutzer, Partnerdatei oder Scanner knüpfen. Validierungsaufgaben, die schlechte Form ablehnen, werden nicht berechnet; eine wohlgeformte fünfzehnstellige Zeichenkette mit lediglich falscher Prüfziffer liefert valid false ohne Exception.