CRC-16 XMODEM-Pruefsumme

CRC-16/XMODEM ist eine zyklische Redundanzprüfung mit sechzehn Bit, die in klassischem Dateiübertragungs-Framing, eingebetteter Firmware und Protokollstacks eingesetzt wird, wenn ein kompaktes Integritätswort statt eines vollständigen kryptografischen Hashes genügt. Ingenieure, Studierende und Support-Teams benötigen oft dasselbe Lehrbuchergebnis für eine kurze Zeichenkette: das CCITT-Generatorpolynom 0x1021, Initialregister null (der XMODEM-Seed), keine Bit-Reflexion und finales XOR null—genau das Profil CRC-16/XMODEM, dessen Prüfwert für die ASCII-Ziffern eins bis neun hexadezimal 31C3 ist. Dieses CRC-16-XMODEM-Prüfsummenwerkzeug akzeptiert nichtleeren Text, kodiert ihn als UTF-8, führt jene deterministische Shift-und-XOR-Schleife aus und liefert die sechzehn-Bit-Prüfsumme als vier hexadezimale Kleinbuchstaben-Ziffern zusammen mit dem Dezimalwert und einer kurzen Zusammenfassung.

Was eine CRC-16 nach XMODEM berechnet

Eine zyklische Redundanzprüfung behandelt eine Nachricht wie ein Polynom und teilt sie durch ein festes Generatorpolynom; der Rest dieser Division ist die Prüfsumme. Bei CRC-16 ist der Rest 16 Bit breit und passt in vier Hexziffern. XMODEM nutzt das CCITT-Polynom 1021 hexadezimal, startet das Register bei null, spiegelt keine Bits und verzichtet auf eine abschließende Maske. Praktisch wird jedes Byte per Exklusiv-Oder in die oberen acht Bit eines 16-Bit-Registers eingerechnet und dann achtmal verschoben. Ihr Text wird vorher als UTF-8 kodiert, und Sie erhalten den Wert in Hex und dezimal.

Wofür sie taugt und welche Fehler häufig sind

Firmware-Entwickler und Studierende serieller Protokolle prüfen damit von Hand berechnete Reste, ohne in jeder Sprache eine Schiebeschleife zu schreiben. Der Referenzwert für 123456789 ist 31C3; weicht Ihre Umsetzung ab, lohnt ein Blick auf Startwert und Polynom. Am häufigsten wird XMODEM mit CCITT-FALSE verwechselt, das dasselbe Polynom, aber den Startwert FFFF nutzt. Eine leere Eingabe wird abgelehnt, damit eine fehlende Antwort nicht wie eine Prüfsumme null aussieht. Und weil eine CRC weder kollisionsresistent noch geschlüsselt ist, erkennt sie zufällige Beschädigung, beweist aber keine Echtheit.

Was CRC-16/XMODEM mit Polynom 0x1021 berechnet und warum das Hex-Wort zählt

Eine zyklische Redundanzprüfung behandelt eine Nachricht als Polynom über dem Galois-Körper mit zwei Elementen und teilt sie durch ein festes Generatorpolynom; der Rest wird zur Prüfsumme. Beim CRC-16 ist der Rest sechzehn Bit breit, sodass das gesamte Ergebnis in ein Wort passt und natürlich als vier hexadezimale Ziffern geschrieben wird. Der von XMODEM und vielen CCITT-Beispielen genutzte Generator ist 0x1021 und expandiert zu x hoch sechzehn plus x hoch zwölf plus x hoch fünf plus eins.

Entscheidend ist, dass das XMODEM-Profil das Register mit null statt mit allen Einsen initialisiert; genau diese Wahl trennt CRC-16/XMODEM von CRC-16/CCITT-FALSE, das dasselbe Poly, aber init 0xFFFF nutzt und daher andere Prüfwerte für dieselbe Nutzlast liefert. In Software erfolgt die Division, indem jedes Eingabe-Byte in die oberen acht Bits eines sechzehn-Bit-Registers exclusive-or-verknüpft und achtmal nach links geschoben wird, mit exclusive-or des Generators, sobald das High-Bit gesetzt ist.

Diese Landing nutzt stets jenen nicht reflektierten Algorithmus mit Initialwert null und finalem XOR null—das Profil, dessen dokumentierter Prüfwert für die neun-Byte-ASCII-Zeichenkette eins zwei drei vier fünf sechs sieben acht neun 31C3 ist. Die Antwort spiegelt außerdem die Dezimalzahl, die Polynom-Zeichenkette 0x1021, die Algorithmus-Bezeichnung CRC-16/XMODEM, die UTF-8-Byteanzahl und den Originaltext wider, damit Clients eine vollständige Audit-Zeile anzeigen können, ohne Metadaten neu abzuleiten.

Weil CRC-16 weder kollisionsresistent noch geschlüsselt ist, behandeln Sie es als Framing- oder Zufallsfehler-Prüfung, nicht als Authentizitätsnachweis; bevorzugen Sie SHA-Familien-Digests, wenn die Suchintention kryptografisches Hashing und nicht ein Zwei-Byte-CRC ist.

Firmware-Autoren und Studierende serieller Protokolle nutzen einen CRC-16-XMODEM-Prüfsummenrechner, um handberechnete Reste gegen das CCITT-Polynom mit Null-Seed zu prüfen, ohne in jeder Sprache eine Shift-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 einer echten Null-Prüfsumme unterscheiden. Content-Seiten, die für CRC-16 XMODEM, CRC16-XMODEM-Rechner oder CCITT-Poly-0x1021-Prüfsumme ranken, profitieren von einem Live-Tool, dessen kostenloser Pfad Byte für Byte mit dem bezahlten Automatisierungspfad auf demselben reinen Modul übereinstimmt.

Validierungsfehler verbrauchen nach Ablehnung nie Saldo. Kombinieren Sie mit CRC-8-, CRC-32- oder kryptografischen Hash-Landings nur, wenn die Suchintention über eine sechzehn-Bit-XMODEM-Framing-Prüfung hinausgeht—halten Sie diese Seite auf Null-Seed-Poly 0x1021 CRC-16/XMODEM fokussiert, damit die SEO-Intention scharf bleibt und nicht mit MODBUS-, IBM- oder CCITT-FALSE-Varianten kollidiert, die denselben Familiennamen teilen, aber nicht denselben Prüfvektor.