La implementación CRC-32 más común, también llamada CRC-32b. Utiliza la forma reflejada del polinomio 0x04C11DB7, es decir, 0xEDB88320. Tanto los bytes de entrada como los de salida se reflejan en bits (LSB primero), con el valor inicial y el XOR final establecidos en 0xFFFFFFFF.

Ampliamente utilizado por ZIP, gzip, imágenes PNG, tramas Ethernet (IEEE 802.3), PKCS#7 y muchos sistemas heredados. Esta es la variante de facto "CRC-32 predeterminada".

Propuesta por G. Castagnoli y colegas en 1993, esta variante utiliza el polinomio 0x1EDC6F41 (forma reflejada 0x82F63B78). A la misma distancia de Hamming, ofrece una detección de errores en ráfaga más potente que el polinomio ISO-HDLC.

La aceleración de hardware está disponible a través de las instrucciones Intel SSE4.2 y ARM CRC32. Se utiliza ampliamente en protocolos de transporte y almacenamiento modernos como iSCSI, NVMe, Btrfs y SCTP.

Utiliza el mismo polinomio 0x04C11DB7 que ISO-HDLC, pero ni la entrada ni la salida sonbit reflejado(MSB primero, big-endian). El valor inicial es 0xFFFFFFFF y el XOR final está deshabilitado (XorOut = 0x00000000).

Se utiliza principalmente para tablas PSI/SI en flujos de transporte MPEG-2 (PAT, PMT, NIT y tablas relacionadas), además de comprobaciones de integridad en sistemas de transmisión DVB y ATSC.

Sus parámetros son casi idénticos a MPEG-2 (polinomio 0x04C11DB7, sin reflexión, valor inicial 0xFFFFFFFF). La única diferencia es unaXOR final con 0xFFFFFFFF, que cambia cada bit. También se conoce como CRC-32/AAL5 o CRC-32/DECT-B.

Utilizado por el formato de archivo comprimido BZip2 y el campo de suma de comprobación final del protocolo ATM AAL5.

Trata la entrada como unUTF-8string, lo convierte a bytes y luego calcula CRC32. Este es el modo más común para texto sin formato, código fuente, JSON y contenido similar.

Nota: el mismo texto codificado con un juego de caracteres diferente, como GBK o UTF-16, produce un flujo de bytes diferente y, por lo tanto, un valor CRC32 diferente. Esta herramienta siempre utiliza UTF-8.

Trata la entrada como sin formatoliterales de bytes hexadecimales. Se ignoran los espacios y los saltos de línea. Cada dos caracteres hexadecimales se convierten en un byte (00–FF).

Útil cuando necesita comprobaciones CRC para datos binarios exactos, como marcos de red, fragmentos de imágenes de firmware o volcados de memoria. Puede pegar la salida de Wireshark o del volcado hexadecimal directamente.

Trata la entrada como unCadena codificada en Base64, lo decodifica en bytes sin formato y luego calcula CRC32. Útil para certificados PEM, cargas útiles JWT, URI de datos y otro contenido Base64.

Admite el alfabeto Base64 estándar (A-Z a-z 0-9 + /). El personaje de relleno=es opcional. Base64 seguro para URL (-_) no es compatible.

Muestra el valor como un número hexadecimal en mayúscula de 8 dígitos con el prefijo0x. Cada carácter representa 4 bits, para un total de 32 bits. Este es el formato estándar utilizado en la mayoría de las herramientas, código fuente y documentación.

En comparación con la salida decimal, el formato hexadecimal facilita la inspección de los límites de bytes y hace coincidir los volcados de memoria y los campos de protocolo de forma más natural.

Muestra la suma de verificación como unentero decimal de 32 bits sin signoen el rango 0–4,294,967,295 (2³²−1). Algunos lenguajes y herramientas comparan valores CRC en forma decimal y los campos de la base de datos suelen almacenar esta representación.

Nota: Los resultados de CRC32 deben tratarse como enteros sin signo. En tipos int con signo como Java o C#, los valores superiores a 0x7FFFFFFF pueden parecer negativos y deben convertirse a uint o a una representación sin signo más amplia.

Muestra la suma de comprobación como una cadena binaria de 32 bits con el prefijo0b. Cada carácter es 0 o 1, está alineado con el bit más significativo de la izquierda y se completa con ceros a la izquierda cuando es necesario.

Principalmente útil para comprender el algoritmo CRC interno, estudiar la división polinomial, enseñar y escenarios integrados que necesitan procesamiento de suma de comprobación a nivel de bits.

Muestra la suma de verificación como un número octal de 11 dígitos con el prefijo0o. Se necesitan como máximo 11 caracteres octales para 32 bits porque 3×11 = 33 > 32. Cada dígito octal representa 3 bits.

La salida octal es poco común en los flujos de trabajo CRC modernos, pero todavía aparece en algunas herramientas Unix, cadenas de herramientas de firmware integradas y especificaciones de protocolos de comunicación más antiguos.