Die häufigste CRC-32-Implementierung, auch CRC-32b genannt. Es verwendet die reflektierte Form des Polynoms 0x04C11DB7, nämlich 0xEDB88320. Sowohl Eingabebytes als auch Ausgabe werden bitreflektiert (LSB zuerst), wobei der Anfangswert und das endgültige XOR beide auf 0xFFFFFFFF gesetzt sind.

Wird häufig von ZIP, gzip, PNG-Bildern, Ethernet-Frames (IEEE 802.3), PKCS#7 und vielen älteren Systemen verwendet. Dies ist de facto die „Standard-CRC-32“-Variante.

Diese Variante wurde 1993 von G. Castagnoli und Kollegen vorgeschlagen und verwendet das Polynom 0x1EDC6F41 (gespiegelte Form 0x82F63B78). Bei gleicher Hamming-Distanz bietet es eine stärkere Burst-Fehlererkennung als das ISO-HDLC-Polynom.

Hardwarebeschleunigung ist über Intel SSE4.2- und ARM CRC32-Anweisungen verfügbar. Es wird häufig in modernen Speicher- und Transportprotokollen wie iSCSI, NVMe, Btrfs und SCTP verwendet.

Verwendet dasselbe 0x04C11DB7-Polynom wie ISO-HDLC, aber weder Eingabe noch Ausgabebit-reflektiert(MSB zuerst, Big-Endian). Der Anfangswert ist 0xFFFFFFFF und das letzte XOR ist deaktiviert (XorOut = 0x00000000).

Wird hauptsächlich für PSI/SI-Tabellen in MPEG-2-Transportströmen (PAT, PMT, NIT und verwandte Tabellen) sowie für Integritätsprüfungen in DVB- und ATSC-Rundfunksystemen verwendet.

Seine Parameter sind nahezu identisch mit denen von MPEG-2 (Polynom 0x04C11DB7, keine Reflexion, Anfangswert 0xFFFFFFFF). Der einzige Unterschied ist afinal XOR mit 0xFFFFFFFF, was jedes Bit umdreht. Es ist auch als CRC-32/AAL5 oder CRC-32/DECT-B bekannt.

Wird vom BZip2-komprimierten Dateiformat und dem Trailer-Prüfsummenfeld des ATM-AAL5-Protokolls verwendet.

Behandelt die Eingabe alsUTF-8string, wandelt ihn in Bytes um und berechnet dann CRC32. Dies ist der gebräuchlichste Modus für einfachen Text, Quellcode, JSON und ähnliche Inhalte.

Hinweis: Derselbe Text, der mit einem anderen Zeichensatz wie GBK oder UTF-16 codiert ist, erzeugt einen anderen Bytestrom und daher einen anderen CRC32-Wert. Dieses Tool verwendet immer UTF-8.

Behandelt die Eingabe als unformatierthexadezimale Byteliterale. Leerzeichen und Zeilenumbrüche werden ignoriert. Alle zwei Hexadezimalzeichen werden zu einem Byte (00–FF).

Nützlich, wenn Sie CRC-Prüfungen für genaue Binärdaten wie Netzwerkframes, Firmware-Image-Fragmente oder Speicherabbilder benötigen. Sie können die Wireshark- oder Hex-Dump-Ausgabe direkt einfügen.

Behandelt die Eingabe alsBase64-codierte Zeichenfolge, dekodiert es in Rohbytes und berechnet dann CRC32. Nützlich für PEM-Zertifikate, JWT-Nutzlasten, Daten-URIs und andere Base64-Inhalte.

Unterstützt das Standard-Base64-Alphabet (A-Z a-z 0-9 + /). Das Füllzeichen=ist optional. URL-sicheres Base64 (-_) wird nicht unterstützt.

Zeigt den Wert als 8-stellige Hexadezimalzahl in Großbuchstaben mit dem Präfix an0x. Jedes Zeichen repräsentiert 4 Bits, also insgesamt 32 Bits. Dies ist das Standardformat, das in den meisten Tools, Quellcodes und Dokumentationen verwendet wird.

Im Vergleich zur dezimalen Ausgabe erleichtert die hexadezimale Ausgabe die Überprüfung von Bytegrenzen und gleicht Speicherauszüge und Protokollfelder natürlicher ab.

Zeigt die Prüfsumme als anunsigned 32-Bit-Dezimal-Ganzzahlim Bereich 0–4.294.967.295 (2³²−1). Einige Sprachen und Tools vergleichen CRC-Werte in Dezimalform und Datenbankfelder speichern diese Darstellung häufig.

Hinweis: CRC32-Ergebnisse sollten als vorzeichenlose Ganzzahlen behandelt werden. In vorzeichenbehafteten int-Typen wie Java oder C# können Werte über 0x7FFFFFFF negativ erscheinen und sollten in uint oder eine breitere vorzeichenlose Darstellung konvertiert werden.

Zeigt die Prüfsumme als 32-Bit-Binärzeichenfolge mit dem Präfix an0b. Jedes Zeichen ist 0 oder 1, ausgerichtet am höchstwertigen Bit auf der linken Seite und bei Bedarf mit führenden Nullen aufgefüllt.

Hauptsächlich nützlich zum Verständnis des internen CRC-Algorithmus, zum Studium der Polynomdivision, zum Unterrichten und für eingebettete Szenarien, die eine Prüfsummenverarbeitung auf Bitebene erfordern.

Zeigt die Prüfsumme als 11-stellige Oktalzahl mit dem Präfix an0o. Für 32 Bit werden höchstens 11 Oktalzeichen benötigt, da 3×11 = 33 > 32. Jede Oktalziffer repräsentiert 3 Bits.

Oktale Ausgabe ist in modernen CRC-Workflows ungewöhnlich, kommt aber immer noch in einigen Unix-Tools, eingebetteten Firmware-Toolchains und älteren Kommunikationsprotokollspezifikationen vor.