ForHosting KIT · Entwickler-Tools

CRC-8-Pruefsumme

Die neun Zeichen 123456789 ergeben den CRC-8-Wert f4, dezimal 244, den dokumentierten Prüfwert des SMBus-Profils mit Polynom 07. So prüfen Sie einen Busrahmen oder eine Lehrbuchaufgabe. Fügen Sie einen beliebigen Text ein und erhalten Sie seine Ein-Byte-Prüfsumme. Kostenlos in Ihrem Browser.

Kostenlos
Läuft in Ihrem Browser
Ohne Anmeldung
Ihre Daten bleiben auf Ihrem Gerät

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Rechenbeispiel

Wenn Sie eingeben

Text: 123456789

Erhalten Sie

Ergebnis: f4
Crc8: f4
Hex: f4
Dezimal: 244

CRC-8 ist eine zyklische Redundanzprüfung mit acht Bit, die in eingebetteten Bussen, einfachen Framing-Protokollen und Lehrmaterial eingesetzt wird, wenn ein kompaktes Integritätsbyte nötig ist statt eines vollständigen kryptografischen Hashs. Ingenieure, Studierende und Support-Teams benötigen oft dasselbe Lehrbuchergebnis für eine kurze Zeichenkette: das Standardpolynom 0x07 (x hoch acht plus x im Quadrat plus x plus eins), Initialregister null, ohne Bitspiegelung und mit finalem XOR null—genau das CRC-8/SMBus-Profil, dessen Prüfwert für die ASCII-Ziffern eins bis neun hexadezimal F4 ist. Dieses CRC-8-Prüfsummenwerkzeug akzeptiert nicht leeren Text, kodiert ihn als UTF-8, führt jene deterministische Verschiebe-und-XOR-Schleife aus und liefert das einzelne Prüfsummenbyte als zwei hexadezimale Ziffern in Kleinbuchstaben zusammen mit dem Dezimalwert und einer kurzen Zusammenfassung.

Was CRC-8 mit Polynom 0x07 berechnet und warum das Hex-Byte zählt

Eine zyklische Redundanzprüfung behandelt eine Nachricht als Polynom über dem Galoiskörper mit zwei Elementen und teilt sie durch ein festes Generatorpolynom; der Rest wird zur Prüfsumme. Bei CRC-8 ist der Rest nur acht Bit breit, sodass das gesamte Ergebnis in ein Byte passt und natürlich als zwei hexadezimale Ziffern geschrieben wird. Der Standardgenerator von SMBus, vielen ATM-HEC-Beispielen und den meisten Online-CRC-8-Demos ist 0x07, was x hoch acht plus x im Quadrat plus x plus eins entspricht.

In Software erfolgt die Division, indem jedes Eingabebyte per exklusivem ODER in ein Acht-Bit-Register geladen und achtmal nach links verschoben wird, mit exklusivem ODER des Generators, sobald das höchste Bit gesetzt ist. Diese Seite nutzt stets jenen nicht gespiegelten Algorithmus mit Initialwert null und finalem XOR null—das Profil, dessen dokumentierter Prüfwert für die neun Byte lange ASCII-Zeichenkette eins zwei drei vier fünf sechs sieben acht neun F4 ist.

Die Antwort wiederholt außerdem die Dezimalzahl, die Polynomzeichenkette 0x07, die Algorithmusbezeichnung CRC-8, die UTF-8-Bytezahl und den Originaltext, damit Clients eine vollständige Auditzeile anzeigen können, ohne Metadaten neu abzuleiten. Weil CRC-8 weder kollisionsresistent noch schlüsselgebunden ist, behandeln Sie es als Framing- oder Zufallsfehlerprüfung, nicht als Authentizitätsnachweis; bevorzugen Sie SHA-Familien-Digests, wenn die Suchintention kryptografisches Hashing statt eines Ein-Byte-CRC ist.

Wo sich eine Ein-Byte-Prüfung mit CRC-8 lohnt

Firmware-Autoren und Studierende von Busprotokollen nutzen einen CRC-8-Prüfsummenrechner, um handberechnete Reste gegen das SMBus-artige Polynom zu prüfen, ohne in jeder Sprache eine Verschiebeschleife 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-8-Prüfsumme oder CRC8-Rechner 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 Guthaben. Kombinieren Sie CRC-32- oder kryptografische Hash-Landings nur, wenn die Suchintention über eine Acht-Bit-Framing-Prüfung hinausgeht—halten Sie diese Seite auf Standardpoly-0x07-CRC-8 fokussiert, damit die SEO-Intention scharf bleibt.

Anwendungsfälle

SMBus- und Embedded-Protokollprüfungen

Prüfen Sie, dass eine Nutzlastzeichenkette unter Poly 0x07 den erwarteten Ein-Byte-CRC-8-Trailer erzeugt, bevor Sie Gerätelogs oder Unit-Test-Vektoren vergleichen.

CRC-Rest-Demos im Unterricht

Lehrkräfte zeigen den klassischen Wert 123456789 → F4 und lassen Studierende andere kurze Strings neu berechnen, ohne eine CRC-Bibliothek zu installieren.

Häufige Fragen

Welches CRC-8-Polynom verwendet dieses Werkzeug?

Das Standardpoly 0x07 (CRC-8/SMBus): init 0x00, ohne Spiegelung, xorout 0x00. Der dokumentierte Check für ASCII 123456789 ist F4.

Was passiert, wenn der Text leer ist?

Ein nicht leerer String ist erforderlich; leere Eingabe gilt nicht als erfolgreiche Null-Prüfsumme.

Ist CRC-8 ein kryptografischer Hash?

Nein. CRC-8 ist eine Acht-Bit-Integritätsprüfung für Framing und versehentliche Korruption. Nutzen Sie SHA-256 oder ähnliches, wenn Sie Kollisionsresistenz oder Authentifizierung brauchen.

Wo wird dieses CRC-8-Profil eingesetzt?

Das Polynom 07 mit Startwert null ist der Generator von SMBus, vieler ATM-Beispiele zur Kopfprüfung und der meisten CRC-8-Demos im Netz. Es passt zu eingebetteten Bussen, einfachen Rahmenprotokollen und Lehrmaterial.

Welche Werte kann eine CRC-8 annehmen?

Sie passt in ein einziges Byte: von 00 bis ff hexadezimal, also von 0 bis 255 dezimal. Das Werkzeug zeigt beide Formen, zwei kleine Hexziffern und die passende ganze Zahl.

Kann ich eine CRC-8 für leeren Text berechnen?

Nein. Leerer Text wird abgelehnt, statt eine Null zu liefern. So verwechselt eine automatische Bewertung eine fehlende Antwort nie mit einer echten Prüfsumme vom Wert null.

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

POSThttps://api.kit.forhosting.com/enc/crc8

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/crc8 \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"123456789"}'

const res = await fetch("https://api.kit.forhosting.com/enc/crc8", {
  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/crc8",
    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/crc8", 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/crc8", 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.crc8",
  "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

pro Anfrage$0.002

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 einer echten Null-Prüfsumme verwechseln. Der kostenlose Browserpfad und die vorausbezahlte API teilen ein reines Modul, sodass Kursfixtures und Produktionspipelines für dieselbe Zeichenkette immer dasselbe Hex-Byte erhalten.

Eingabevertrag, Fehler bei leerer Zeichenkette und JSON-Antwortform

Die Zeichenkette wird vor der CRC-Schleife als UTF-8 kodiert, sodass Mehrbyte-Zeichen jedes Code-Unit-Byte genau so beisteuern, wie es ein Embedded-Gerät bei demselben UTF-8-Strom täte. Verankern Sie sowohl einen Erfolgspfad als auch einen Fehler bei leerer Eingabe in der Continuous Integration, damit versehentliche poly- oder init-Änderungen nicht unbemerkt ausgeliefert werden. Optionale Nullfelder 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 prüfen 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, crc8 und hex alle mit derselben zweistelligen hexadezimalen Prüfsumme in Kleinbuchstaben; decimal als Ganzzahl von null bis zweihundertfünfundfünfzig; polynomial fest auf 0x07; algorithm fest auf CRC-8; input_bytes gleich der UTF-8-Länge; text als Echo der Eingabe; und message mit Zusammenfassung von Bytezahl und Hex-Ergebnis.

Wo eine CRC-8-Prüfsummen-API sich lohnt und wie die Preise funktionieren

Nutzen Sie das kostenlose Browser-Tool für einmalige Prüfungen; rufen Sie die vorausbezahlte KIT-API aus Backends, Serverless-Funktionen und SDKs auf, wenn Sie einen stabilen Vertrag mit Guthaben zu $0.002 pro erfolgreichem Item brauchen. Halten Sie Nutzlasten bei gewöhnlichen Textgrößen, die für einen Worker-Isolate-Item-Aufruf geeignet sind; dieses Werkzeug ist für kurze Strings und Protokollausschnitte, nicht für Multi-Megabyte-Binärblobs.

Integrationsbeispiele

CI-Fixtures für Framing-Code

Pipelines verankern deterministische CRC-8-Hex-Ausgaben und den Fehler bei leerer Eingabe, damit versehentliche poly- oder init-Änderungen sofort scheitern.

Technische Fragen

Wie berechne ich eine CRC-8-Prüfsumme eines Textes?

Senden Sie JSON mit einem nicht leeren Stringfeld text. Die API kodiert die Zeichenkette als UTF-8, führt CRC-8 mit Polynom 0x07 aus und liefert das Byte als zwei hexadezimale Kleinbuchstaben-Ziffern in result, crc8 und hex.

Ist der CRC-8-Prüfsummenrechner kostenlos?

Das Browser-Tool läuft kostenlos auf Ihrem Gerät. API-Aufrufe nutzen Prepaid-KIT-Guthaben zu $0.002 pro erfolgreichem Item; Validierungsfehler werden nicht berechnet.

Vollständige KIT-Dokumentation lesen →