L'implémentation CRC-32 la plus courante, également appelée CRC-32b. Il utilise la forme réfléchie du polynôme 0x04C11DB7, à savoir 0xEDB88320. Les octets d'entrée et la sortie sont réfléchis en bits (LSB en premier), avec la valeur initiale et le XOR final tous deux définis sur 0xFFFFFFFF.

Largement utilisé par ZIP, gzip, images PNG, trames Ethernet (IEEE 802.3), PKCS#7 et de nombreux systèmes existants. Il s'agit de la variante de facto "CRC-32 par défaut".

Proposée par G. Castagnoli et ses collègues en 1993, cette variante utilise le polynôme 0x1EDC6F41 (forme réfléchie 0x82F63B78). À la même distance de Hamming, il offre une détection des erreurs de rafale plus efficace que le polynôme ISO-HDLC.

L'accélération matérielle est disponible via les instructions Intel SSE4.2 et ARM CRC32. Il est largement utilisé dans les protocoles de stockage et de transport modernes tels que iSCSI, NVMe, Btrfs et SCTP.

Utilise le même polynôme 0x04C11DB7 que ISO-HDLC, mais ni l'entrée ni la sortie ne sontbit-reflected(MSB en premier, gros-boutiste). La valeur initiale est 0xFFFFFFFF et le XOR final est désactivé (XorOut = 0x00000000).

Principalement utilisé pour les tables PSI/SI dans les flux de transport MPEG-2 (PAT, PMT, NIT et tables associées), ainsi que pour les contrôles d'intégrité dans les systèmes de diffusion DVB et ATSC.

Ses paramètres sont quasiment identiques à MPEG-2 (polynôme 0x04C11DB7, pas de réflexion, valeur initiale 0xFFFFFFFF). La seule différence est unfinal XOR with 0xFFFFFFFF, qui bascule à chaque instant. Il est également connu sous le nom de CRC-32/AAL5 ou CRC-32/DECT-B.

Utilisé par le format de fichier compressé BZip2 et le champ de somme de contrôle de fin du protocole ATM AAL5.

Traite l'entrée comme unUTF-8string, le convertit en octets, puis calcule CRC32. Il s'agit du mode le plus courant pour le texte brut, le code source, le JSON et le contenu similaire.

Remarque : le même texte codé avec un jeu de caractères différent tel que GBK ou UTF-16 produit un flux d'octets différent et donc une valeur CRC32 différente. Cet outil utilise toujours UTF-8.

Treats the input as rawlittéraux d'octets hexadécimaux. Les espaces et les sauts de ligne sont ignorés. Tous les deux caractères hexadécimaux deviennent un octet (00–FF).

Utile lorsque vous avez besoin de vérifications CRC pour des données binaires exactes telles que des trames réseau, des fragments d'image de micrologiciel ou des vidages de mémoire. Vous pouvez coller directement la sortie Wireshark ou le vidage hexadécimal.

Traite l'entrée comme unBase64-encoded string, le décode en octets bruts, puis calcule CRC32. Utile pour les certificats PEM, les charges utiles JWT, les URI de données et autres contenus Base64.

Prend en charge l'alphabet standard Base64 (A-Z a-z 0-9 + /). Le caractère de remplissage=est facultatif. Base64 sécurisé pour les URL (-_) n’est pas pris en charge.

Affiche la valeur sous la forme d'un nombre hexadécimal majuscule à 8 chiffres préfixé par0x. Chaque caractère représente 4 bits, pour un total de 32 bits. Il s'agit du format standard utilisé dans la plupart des outils, du code source et de la documentation.

Par rapport à la sortie décimale, l'hexadécimal facilite l'inspection des limites d'octets et fait correspondre plus naturellement les vidages de mémoire et les champs de protocole.

Affiche la somme de contrôle sous forme deentier décimal non signé de 32 bitsdans la plage 0–4 294 967 295 (2³²−1). Certains langages et outils comparent les valeurs CRC sous forme décimale, et les champs de base de données stockent souvent cette représentation.

Remarque : les résultats CRC32 doivent être traités comme des entiers non signés. Dans les types int signés tels que Java ou C#, les valeurs supérieures à 0x7FFFFFFF peuvent apparaître négatives et doivent être converties en uint ou en une représentation non signée plus large.

Affiche la somme de contrôle sous forme de chaîne binaire de 32 bits préfixée par0b. Chaque caractère est 0 ou 1, aligné sur le bit le plus significatif à gauche et complété par des zéros non significatifs si nécessaire.

Principalement utile pour comprendre l'algorithme CRC interne, étudier la division polynomiale, l'enseignement et les scénarios intégrés qui nécessitent un traitement de somme de contrôle au niveau des bits. La sortie

Affiche la somme de contrôle sous la forme d'un nombre octal à 11 chiffres préfixé par0o. Au plus 11 caractères octaux sont nécessaires pour 32 bits car 3×11 = 33 > 32. Chaque chiffre octal représente 3 bits. Outil

Octal est rare dans les flux de travail CRC modernes, mais elle apparaît toujours dans certains outils Unix, chaînes d'outils de micrologiciels intégrés et anciennes spécifications de protocole de communication.