Longitudinal Redundancy Check (LRC)
Die neun Bytes von 123456789 ergeben das Prüfbyte 31 hexadezimal, also 49 dezimal: Jedes Byte wird per exklusivem Oder (XOR) verknüpft, die einfachste Blockparität aus Lektionen zu seriellen Rahmen und Modbus ASCII. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Text
- 123456789
- Ergebnis
- 31
- Lrc
- 31
- Hex
- 31
- Dezimal
- 49
Ein Longitudinal Redundancy Check, oft abgekürzt LRC, ist ein Ein-Byte-Integritätsanhang, der durch exklusives ODER jedes Bytes einer Nachricht entsteht. Tutorials zu seriellen Frames, Einführungen in industrielle Protokolle und Classroom-Labs zu Modbus ASCII stellen den LRC als die einfachste Blockparität vor, die man von Hand berechnen kann: starten Sie bei null, XOR-en Sie das nächste Byte in den Akkumulator und nach dem letzten Byte halten Sie einen Prüfwert, der kippt, wenn irgendein Bit in irgendeinem Byte ungerade oft in dieser Bitebene kippt. Ingenieure, Studierende und Support-Teams brauchen dasselbe deterministische Hex-Byte für kurze Nutzdaten, ohne einen Protokollstack zu installieren oder CRC-Polynome zu diskutieren. Dieses LRC-Werkzeug akzeptiert nicht leeren Text, kodiert ihn als UTF-8, führt die reine XOR-Schleife aus und liefert das Prüfbyte als zwei hexadezimale Ziffern in Kleinbuchstaben zusammen mit dem Dezimalwert und einer kurzen Zusammenfassung.
Was der LRC berechnet und warum das XOR-Prüfbyte zählt
Der Longitudinal Redundancy Check behandelt eine Nachricht als Folge von Acht-Bit-Spalten und berechnet gerade Parität in jeder Spalte, indem aufeinanderfolgende Bytes per XOR in ein Acht-Bit-Register geschrieben werden. Nach dem letzten Byte ist dieses Register der LRC: ein einzelnes Prüfbyte, das üblicherweise als zwei Hexadezimalziffern geschrieben wird. Anders als bei einem zyklischen Redundanzcheck gibt es kein Generatorpolynom, keine Shift-Tabelle und keine Reflexionsoptionen zum Fehlkonfigurieren—nur sequentielles XOR.
Diese Einfachheit erklärt, warum LRC in Lektionen zu seriellen Blockframes und in vielen Beschreibungen von Modbus-ASCII-Prüffeldern vorkommt: Sie können eine Handrechnung an der Tafel in Sekunden prüfen. Diese Seite nutzt stets die reine XOR-Definition über die UTF-8-Bytes des eingereichten Textes, sodass Mehrbyte-Zeichen jedes Code-Unit-Byte genau so beisteuern, wie es ein Embedded-Gerät bei demselben UTF-8-Strom täte. Die Antwort wiederholt auch die Dezimalzahl, das Algorithmus-Label LRC-XOR, die UTF-8-Bytezahl und den Originaltext, damit Clients eine vollständige Audit-Zeile anzeigen können, ohne Metadaten neu abzuleiten.
Weil LRC weder kollisionsresistent noch geschlüsselt ist, behandeln Sie ihn als Framing- oder Korruptionsprüfung, nicht als Authentizitätsnachweis; bevorzugen Sie CRC- oder SHA-Familien-Digests, wenn die Suchintention über einen Ein-Byte-XOR-Trailer hinausgeht.
Wo ein LRC-Rechner sich lohnt und wie die Preisgestaltung greift
Firmware-Autoren und Studierende industrieller Protokolle nutzen einen Longitudinal-Redundancy-Check-Rechner, um handberechnete XOR-Trailer zu prüfen, ohne in jeder Sprache eine Schleife zu schreiben. Lehrplattformen und LMS-Plugins brauchen ein deterministisches Orakel, das leere Eingabe ablehnt statt null für die leere Nachricht zurückzugeben, damit Auto-Grader fehlende Antworten von einem echten Null-Prüfwert unterscheiden. Content-Seiten, die für Longitudinal Redundancy Check oder LRC-Rechner ranken, profitieren von einem Live-Tool, dessen kostenloser Pfad byte für byte mit dem bezahlten Automationspfad auf demselben reinen Modul übereinstimmt.
Validierungsfehler verbrauchen nach Ablehnung nie Guthaben. Kombinieren Sie CRC-8-, CRC-16- oder kryptografische Hash-Landings nur, wenn die Suchintention über eine Acht-Bit-XOR-Framing-Prüfung hinausgeht—halten Sie diese Seite auf LRC als XOR aller Bytes fokussiert, damit die SEO-Intention scharf bleibt.
Anwendungsfälle
Serielle Frames und Protokoll-Labs
Prüfen Sie, dass eine Nutzdaten-Zeichenkette unter sequentiellem XOR den erwarteten Ein-Byte-LRC-Trailer liefert, bevor Sie Gerätelogs oder Unit-Test-Vektoren vergleichen.
LRC-Demos im Unterricht
Lehrkräfte zeigen die klassische Ziffernketten-Prüfung und lassen Studierende andere kurze Strings ohne Protokollbibliothek neu berechnen.
Häufige Fragen
Welchen Algorithmus nutzt dieses LRC-Werkzeug?
Reines sequentielles XOR aller UTF-8-Bytes (LRC-XOR). Starten Sie bei null, XOR-en Sie jedes Byte und behalten Sie die niedrigen acht Bits. Das Ergebnis ist ein Prüfbyte in Kleinbuchstaben-Hex.
Was passiert, wenn der Text leer ist?
Ein nicht leerer String ist erforderlich; leere Eingabe gilt nicht als erfolgreicher Null-Prüfwert.
Ist LRC dasselbe wie CRC-8?
Nein. Hier ist LRC ein einfaches XOR aller Bytes. CRC-8 teilt durch ein Polynom mit Shift-und-XOR-Schritten. Nutzen Sie die CRC-8-Landing für Poly 0x07; diese Seite für XOR-LRC.
Wie berechne ich eine LRC von Hand?
Beginnen Sie bei null und verknüpfen Sie jedes Byte der Nachricht nacheinander per XOR mit dem laufenden Wert. Nach dem letzten Byte ist dieser Wert die LRC, meist als zwei Hexadezimalziffern geschrieben; für 123456789 ist sie 31.
Was passiert bei leerem Text?
Leerer Text wird abgelehnt, statt null zurückzugeben. So kann niemand eine fehlende Eingabe mit einer echten Prüfsumme von null verwechseln, was etwa automatischen Bewertungen im Unterricht hilft.
Werden Umlaute und Emojis richtig berücksichtigt?
Ja. Der Text wird vor der Berechnung als UTF-8 kodiert, und jedes Byte eines mehrbytigen Zeichens fließt ein, genau so, wie ein Gerät es beim Empfang desselben Datenstroms rechnen würde.
Beweist eine LRC, dass eine Nachricht nicht verändert wurde?
Nein. Eine LRC ist weder kollisionsresistent noch mit einem Schlüssel versehen: Sie erkennt zufällige Übertragungsfehler, aber keine absichtliche Fälschung. Für eine stärkere Prüfung kommen Verfahren aus der CRC- oder SHA-Familie in Frage.
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/enc/lrc \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"123456789"}'const res = await fetch("https://api.kit.forhosting.com/enc/lrc", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "123456789"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/lrc",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "123456789"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/lrc", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"123456789"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"123456789"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/lrc", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"text": "123456789"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.lrc",
"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
Leere Eingabe wird mit invalid_input abgelehnt, damit Aufrufer nie ein fehlendes Feld mit einem echten Null-Prüfwert verwechseln.
Eingabevertrag, Leerstring-Fehler und Form der JSON-Antwort
Die Zeichenkette wird vor der XOR-Schleife als UTF-8 kodiert. Fixieren Sie in der Continuous Integration sowohl einen Erfolgspfad als auch einen Leer-Eingabe-Fehler, damit versehentliche Algorithmusänderungen nicht unbemerkt ausgeliefert werden. Optionale Null-Felder werden weggelassen statt als null ausgegeben, passend zum deklarativen Renderer-Vertrag für saubere Webformulare. Senden Sie per POST einen JSON-Body mit einem einzigen Pflicht-Stringfeld namens text: jede nicht leere Zeichensequenz, die Sie mit einem LRC schützen möchten. Die Aliase input, value, s, data, message und payload werden für dasselbe Feld akzeptiert, damit SDK-Stubs und Formularposts flexibel bleiben. Fehlendes text, ein Nicht-String-Wert oder eine leere Zeichenkette scheitern mit invalid_input und einer klaren Meldung, dass ein nicht leerer String erforderlich ist; diese Fehler werden auf der vorausbezahlten API nicht berechnet. Bei Erfolg enthält der Body result, lrc und hex alle mit demselben zweistelligen hexadezimalen Prüfbyte in Kleinbuchstaben; decimal als Ganzzahl von null bis zweihundertfünfundfünfzig; algorithm fest auf LRC-XOR; input_bytes gleich der UTF-8-Länge; text als Echo der Eingabe; und message mit Zusammenfassung von Bytezahl und Hex-Ergebnis.
Wo ein LRC-Rechner sich lohnt und wie die Preisgestaltung greift
Nutzen Sie das kostenlose Browser-Tool für Einzelprüfungen; rufen Sie die vorausbezahlte KIT-API aus Backends, Serverless-Funktionen und SDKs auf, wenn Sie einen stabilen Vertrag unter Guthaben zu $0.002 pro erfolgreichem Item brauchen. Halten Sie Nutzdaten bei gewöhnlichen Textgrößen, die zu einem Worker-Isolate-Item-Aufruf passen; dieses Werkzeug ist für kurze Strings und Protokollschnipsel gedacht, nicht für mehrmegabyte-große Binärblobs.
Integrationsbeispiele
CI-Fixtures für Framing-Code
Pipelines fixieren deterministische LRC-Hex-Ausgaben und den Leer-Eingabe-Fehler, damit versehentliche Algorithmusänderungen schnell scheitern.
Technische Fragen
Wie berechne ich einen Longitudinal Redundancy Check für Text?
Senden Sie JSON mit einem nicht leeren Stringfeld text. Die API kodiert die Zeichenkette als UTF-8, XOR-t jedes Byte in ein Acht-Bit-Register und liefert das Prüfbyte als zwei Kleinbuchstaben-Hex-Ziffern in result, lrc und hex.
Ist der Longitudinal-Redundancy-Check-Rechner kostenlos?
Das Browser-Tool läuft kostenlos auf Ihrem Gerät. API-Aufrufe nutzen vorausbezahltes KIT-Guthaben zu $0.002 pro erfolgreichem Item; Validierungsfehler werden nicht berechnet.