Luhn-Algorithmus prüfen
Sehen Sie sofort, ob eine Ziffernfolge die Luhn-Prüfung nach Modulo 10 besteht: 79927398713 besteht sie. Erkannt werden jede einzelne falsch getippte Ziffer und die meisten Vertauschungen benachbarter Ziffern, ohne zu behaupten, dass die Nummer existiert. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Der Prüfer für den Luhn-Algorithmus ermittelt, ob eine Ziffernfolge die verbreitete Modulo-10-Prüfsummenformel erfüllt. Übermitteln Sie die Ziffern genau wie vorliegend, einschließlich führender Nullen, und Sie erhalten ein klares gültig- oder ungültig-Ergebnis. Die Funktion prüft ausschließlich die Prüfsumme: Sie erkennt keinen Aussteller, bestätigt kein bestehendes Konto und kontaktiert keinen externen Dienst. Eingaben mit anderen Zeichen als Ziffern werden ausdrücklich abgelehnt und nicht stillschweigend bereinigt. Dadurch bleibt die Automatisierung vorhersehbar und Formatierungsfehler werden sichtbar, bevor sie ein anderes System erreichen.
Was ein Luhn-Ergebnis tatsächlich aussagt
Die Luhn-Prüfsumme ist eine kompakte Regel zur Fehlererkennung in Folgen dezimaler Ziffern. Von rechts aus lässt der Algorithmus die Prüfziffer unverändert, verdoppelt jede zweite Ziffer, zieht bei einem zweistelligen Verdopplungsergebnis neun ab und addiert anschließend alle Werte. Die Nummer ist gültig, wenn diese Summe durch zehn teilbar ist.
So werden jede versehentliche Änderung einer einzelnen Ziffer und viele häufige Vertauschungen benachbarter Ziffern erkannt. Das Verfahren hilft daher bei typischen Tipp- und Kopierfehlern. Ein gültiges Ergebnis beweist jedoch nicht, dass die Nummer ausgegeben wurde, jemandem gehört, aktiv ist oder für eine Transaktion verwendet werden kann.
Es besagt lediglich, dass die eingegebene Folge zur Luhn-Formel passt. Diese Abgrenzung ist in Oberflächen und Datenabläufen wichtig: Bezeichnen Sie das Ergebnis als Prüfsummengültigkeit, nicht als Identitäts- oder Kontobestätigung. Der Prüfer erhält die Textdarstellung einschließlich führender Nullen und wandelt sie nie in eine JavaScript-Zahl um.
Lange Kennungen bleiben damit trotz numerischer Genauigkeitsgrenzen vollständig erhalten.
Eingaben vorbereiten und Fehler richtig deuten
Senden Sie den Wert im Feld <code>number</code> als nicht leere Zeichenfolge, die ausschließlich die Zeichen null bis neun enthält. Leerzeichen, Bindestriche, Pluszeichen, Dezimalpunkte, Zeilenumbrüche und Buchstaben gelten als ungültige Eingabe. Dieses strenge Verhalten ist beabsichtigt.
Eine unbemerkte Entfernung von Satzzeichen kann einen vorgelagerten Formatfehler verdecken, die Bedeutung kopierter Daten verändern oder zwei Systeme scheinbar in Einklang bringen, obwohl sie unterschiedliche Texte erhalten haben. Falls Ihre Quelle gruppierte Werte darstellt, normalisieren Sie diese bewusst in Ihrem Ablauf, bevor Sie die Funktion aufrufen, und bewahren Sie für Prüfzwecke den Originalwert auf. Wandeln Sie die Folge vorher nicht in eine Ganzzahl um: Dabei können führende Nullen verschwinden und lange Werte gerundet werden.
Ein erfolgreicher Aufruf liefert stets ein Objekt mit dem booleschen Feld <code>valid</code>. <code>true</code> bedeutet, dass die Summe durch zehn teilbar ist; <code>false</code> kennzeichnet eine syntaktisch korrekte Eingabe mit unpassender Prüfsumme. Ein Eingabefehler unterscheidet sich von einem falschen Prüfergebnis und verlangt normalerweise Korrektur oder Prüfung.
Deterministische Prüfung in Anwendungen einsetzen
Verwenden Sie diesen Prüfer an den Stellen, an denen Ziffernfolgen in ein System gelangen: beim Absenden eines Formulars, beim Stapelimport, bei Migrationen, beim Erzeugen von Testdaten oder in Integrationstests. Führen Sie in interaktiven Formularen die Browser-Version nach Abschluss der Eingabe aus und erläutern Sie, dass die Prüfung wahrscheinliche Fehler erkennt, aber kein bestehendes Konto belegt. Behandeln Sie in einem Import Zeichenfehler als fehlerhaft formatierte Datensätze und falsche Ergebnisse als korrekt formatierte Datensätze mit abweichender Prüfsumme.
Die Trennung verbessert Berichte und erhält verwertbare Diagnosen. Der Algorithmus ist deterministisch, nutzt kein Netzwerk, liest keine Uhr und erzeugt keine Zufallswerte; dieselbe Eingabe ergibt immer dieselbe Ausgabe. Ausstellerspezifische Längen- oder Präfixregeln gibt es ebenfalls nicht: Jede nicht leere Ziffernfolge wird gleich berechnet.
Falls Ihre Domäne Länge, Präfix, Zuordnung oder Live-Status verlangt, wenden Sie diese Regeln gesondert an.
Anwendungsfälle
Eingabefehler erkennen
Prüfen Sie eine Folge beim Absenden und unterscheiden Sie eine falsche Prüfsumme von Buchstaben oder Satzzeichen in der Eingabe.
Stapelimporte validieren
Wenden Sie dieselbe deterministische Regel auf jeden eingehenden Datensatz an, bevor die weitere Verarbeitung beginnt.
Zuverlässige Testdaten erstellen
Bestätigen Sie ohne Netzwerkabhängigkeit ein einheitliches Verhalten gültiger und ungültiger Folgen in Integrationstests.
Häufige Fragen
Was bedeutet ein gültiges Ergebnis?
Die Ziffernfolge erfüllt die Luhn-Modulo-10-Prüfsumme. Ausgabe, Eigentum, Kontostatus oder Transaktionsfähigkeit werden nicht bestätigt.
Darf die Eingabe Leerzeichen oder Bindestriche enthalten?
Nein. Sie darf nur aus Ziffern bestehen. Normalisieren Sie formatierte Werte vor dem Senden ausdrücklich.
Bleiben führende Nullen erhalten?
Ja. Die Eingabe bleibt eine Zeichenfolge und wird nie in einen numerischen Typ umgewandelt.
Verlangt der Prüfer eine bestimmte Länge?
Nein. Er bewertet jede nicht leere Ziffernfolge. Domänenspezifische Längenregeln müssen Sie separat anwenden.
Wie wird die Luhn-Prüfsumme berechnet?
Von rechts beginnend bleibt die letzte Ziffer unverändert, und jede zweite der übrigen Ziffern wird verdoppelt. Ergibt das Verdoppeln eine zweistellige Zahl, ziehen Sie 9 ab. Dann wird alles addiert: Die Folge ist gültig, wenn die Summe durch 10 teilbar ist.
Verwandte Tools
Für Entwickler — API-Zugang
Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.
Endpunkt
Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.
Aufruf aus Ihrem Stack
curl -X POST https://api.kit.forhosting.com/math/luhn \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"number":"79927398713"}'const res = await fetch("https://api.kit.forhosting.com/math/luhn", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"number": "79927398713"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/math/luhn",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"number": "79927398713"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/math/luhn", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"number":"79927398713"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"number":"79927398713"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/math/luhn", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"number": "79927398713"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "math.luhn",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.
Preis
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
Fehler
| HTTP | Code | Bedeutung |
|---|---|---|
401 | unauthorized | Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer). |
402 | insufficient_balance | Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht. |
404 | unknown_type | Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog. |
429 | rate_limited | Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt. |
Technische Hinweise
Deterministische Prüfung in Anwendungen einsetzen
API-Aufrufe verwenden den veröffentlichten Grundpreis von $0.002.
Technische Fragen
Was kostet ein API-Aufruf?
Jede Anfrage verwendet den veröffentlichten Grundpreis von $0.002. Im Browser kann dieselbe deterministische Logik lokal laufen.