CodeKitHub¿Qué es esta herramienta?
CRC son las siglas de Cyclic Redundancy Check (comprobación de redundancia cíclica), un código de detección de errores descrito por primera vez en el artículo de 1975 de W. Wesley Peterson y D.T. Brown, y formalizado más tarde en referencias como "A Painless Guide to CRC Error Detection Algorithms" de Ross Williams y los estándares ITU-T / ISO 3309. Un CRC trata un mensaje como un número binario grande y lo divide por un polinomio generador fijo; el resto de esa división es la suma de comprobación. Como la división polinómica es barata de calcular tanto en hardware como en software, los CRC se convirtieron en la comprobación de errores por defecto en los sistemas de almacenamiento y transmisión.
El CRC-32 —concretamente la variante con el polinomio 0xEDB88320, un valor inicial de 0xFFFFFFFF y un XOR final de 0xFFFFFFFF— está estandarizado en IEEE 802.3 (Ethernet) y se usa como suma de comprobación en los archivos ZIP y gzip, en las imágenes PNG y en innumerables protocolos de red y almacenamiento. Es, con diferencia, la variante de CRC más solicitada, por lo que es el algoritmo predeterminado en esta herramienta. CRC-16/CCITT-FALSE (polinomio 0x1021) y CRC-16/MODBUS (polinomio 0x8005, reflejado) son dos variantes de 16 bits ampliamente utilizadas en protocolos serie como Modbus RTU, XMODEM y diversos estándares de comunicación industrial y embebida.
Es importante entender qué NO es un CRC: no es un hash criptográfico. Los CRC son funciones lineales y rápidas sin ninguna resistencia a la manipulación deliberada; es sencillo construir un mensaje diferente que produzca el mismo valor de CRC. Son excelentes para detectar el tipo de errores de bit aleatorios causados por líneas de transmisión con ruido, fallos de disco o descargas truncadas, pero no ofrecen ninguna protección frente a un adversario que quiera manipular los datos sin ser detectado.
¿Por qué utilizarlo?
- Estás depurando un firmware para un dispositivo Modbus RTU y el maestro rechaza tus tramas por "CRC error" — pega los bytes exactos de la trama aquí, calcula el CRC-16/MODBUS esperado y compara byte a byte con lo que tu código genera.
- Un archivo ZIP descargado en un servidor lento reporta una entrada corrupta al descomprimir — recalcula el CRC-32 del archivo extraído y compáralo con el valor que figura en el encabezado local del ZIP para confirmar si el problema fue de transferencia o del archivo original.
- Estás escribiendo tu propia implementación de CRC-32 en C o Python para un proyecto embebido y necesitas un valor de referencia confiable — usa el vector de prueba estándar "123456789" (que siempre da 0xCBF43926) para verificar que tu código produce el resultado correcto antes de integrarlo.
- Un compañero de equipo te pasa un PNG que Photoshop marca como dañado, y quieres confirmar si es un problema real de CRC en el chunk o solo una advertencia falsa del software antes de perder tiempo re-descargando el archivo.
- Estás implementando XMODEM para transferir archivos por puerto serie y necesitas verificar que tu cálculo de CRC-16/CCITT-FALSE coincide exactamente con lo que espera el protocolo, byte por byte, sin reflexión de bits.
- Necesitas calcular un CRC sin instalar ninguna herramienta de línea de comandos en una máquina restringida — todo corre en el navegador, sin subir el archivo a ningún servidor externo.
Cómo utilizarlo
- Elige la pestaña "Texto" y pega o escribe tu contenido, o cambia a la pestaña "Archivo" y selecciona un archivo desde tu dispositivo.
- Selecciona el algoritmo CRC: CRC-32 (IEEE 802.3, el predeterminado y más común), CRC-16/CCITT-FALSE o CRC-16/MODBUS.
- La suma de comprobación se actualiza automáticamente, mostrada en hexadecimal, decimal y binario.
- Haz clic en "Copiar" junto a cualquier resultado para copiarlo a tu portapapeles.
Ejemplo
Entrada
123456789Resultado
0xCBF43926 (3421780262)Este es el vector de prueba estándar y publicado del CRC-32 (IEEE 802.3): el CRC-32 de la cadena ASCII "123456789" es siempre 0xCBF43926. Puedes verificar el resultado de esta herramienta frente a cualquier otra implementación correcta de CRC-32 usando exactamente esta cadena.
CRC frente a hashes criptográficos (MD5 / SHA)
Tanto los CRC como los hashes criptográficos reducen los datos a una huella digital de tamaño fijo, pero resuelven problemas distintos y no son intercambiables.
| Propiedad | CRC (p. ej., CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Propósito | Detectar corrupción accidental | Detectar manipulación intencionada / verificar integridad |
| Velocidad | Extremadamente rápido, hardware/software sencillo | Más lento, más cómputo por byte |
| Resistencia a colisiones | Ninguna: trivial de provocar a propósito | Diseñado para ser computacionalmente inviable (SHA-256) o roto en el caso de MD5 |
| Tamaño típico | 16 o 32 bits | 128 bits (MD5) o 256 bits (SHA-256) |
| Usos habituales | ZIP/gzip, PNG, Ethernet, Modbus, almacenamiento | Comprobaciones de integridad de archivos, firmas digitales, almacenamiento de contraseñas (con salting) |
Herramientas relacionadas
Si necesitas una suma de comprobación criptográfica en lugar de un CRC de detección de errores, estas herramientas se ajustan mejor.
→ Generador de Hash Multialgoritmo · Generador de MD5 · Generador de HMAC
Errores comunes al implementar CRC
La mayoría de los "mi CRC no coincide" no son errores de lógica, sino de parámetros mal elegidos. Estos son los que más aparecen al depurar una implementación propia.
- Usar el polinomio en su forma normal (0x04C11DB7) en vez de la forma reflejada (0xEDB88320) que requiere CRC-32 estándar cuando se procesa bit a bit desde el LSB.
- Olvidar el XOR final de 0xFFFFFFFF en CRC-32 — sin él, el resultado es el CRC "crudo" antes del paso de post-procesamiento que exige la especificación IEEE 802.3.
- Confundir CRC-16/CCITT-FALSE (sin reflexión, valor inicial 0xFFFF) con otras variantes CCITT que sí reflejan la entrada y salida, o que usan un valor inicial de 0x0000 — son cuatro algoritmos distintos que comparten el mismo polinomio 0x1021.
- Calcular el CRC sobre el texto en un editor con una codificación distinta a la esperada (UTF-8 con BOM en vez de ASCII puro, por ejemplo), lo cual cambia los bytes reales de entrada y por tanto el resultado.
Preguntas frecuentes
¿Para qué se usa un CRC?
Un CRC (comprobación de redundancia cíclica) es un código de detección de errores que se añade a un bloque de datos para que el receptor pueda recalcularlo y confirmar que los datos no se corrompieron accidentalmente durante el almacenamiento o la transmisión. Está integrado en estándares como el encapsulado Ethernet IEEE 802.3, los formatos de archivo ZIP y gzip, las imágenes PNG y muchos protocolos serie e industriales como Modbus.
¿Es CRC-32 lo mismo que MD5 o SHA-256?
No. CRC-32 es una suma de comprobación rápida y lineal para detección de errores, sin propiedades de seguridad; es trivial construir a propósito dos entradas distintas con el mismo valor de CRC-32. MD5 y SHA-256 son funciones hash criptográficas diseñadas para que ese tipo de colisión deliberada sea computacionalmente inviable. Usa CRC-32 para detectar corrupción accidental (un disco rayado, un paquete de red perdido); usa un hash criptográfico de nuestro [Generador de Hash](/hash-generator) o [Generador de MD5](/md5-generator) cuando necesites evidencia de manipulación o garantías de integridad frente a un adversario.
¿Qué variante de CRC-32 usa esta herramienta?
La variante IEEE 802.3 / ZIP / PNG: polinomio 0xEDB88320 (la forma reflejada en bits de 0x04C11DB7), valor inicial 0xFFFFFFFF, entrada y salida reflejadas, y un XOR final de 0xFFFFFFFF. Es la variante que usan Ethernet, ZIP, gzip y PNG, y la que produce 0xCBF43926 para la cadena ASCII "123456789", el vector de prueba estándar y publicado para verificar una implementación de CRC-32.
¿Cuál es la diferencia entre CRC-16/CCITT-FALSE y CRC-16/MODBUS?
Ambos son CRC de 16 bits, pero con polinomios y parámetros distintos. CRC-16/CCITT-FALSE usa el polinomio 0x1021 con un valor inicial de 0xFFFF y sin reflexión de bits; es común en protocolos como XMODEM y en varios estándares de telecomunicaciones. CRC-16/MODBUS usa el polinomio 0x8005 (reflejado como 0xA001), también con un valor inicial de 0xFFFF, pero con la entrada y la salida reflejadas; es la suma de comprobación que Modbus RTU añade a cada trama serie. Producen resultados distintos para la misma entrada, así que es importante elegir la variante que realmente especifica tu protocolo de destino.
¿Puedo calcular el CRC de un archivo, no solo de texto?
Sí. Cambia a la pestaña "Archivo" y elige un archivo desde tu dispositivo; la herramienta lee sus bytes en bruto de forma local en el navegador (a través de la File API) y calcula la suma de comprobación exactamente sobre esos bytes, igual que lo haría un lector de ZIP o de PNG.
¿Se suben mis datos a un servidor?
No. Tanto el cálculo del texto como el del archivo se ejecutan por completo del lado del cliente en JavaScript, usando un algoritmo CRC estándar basado en tablas. Nada de lo que escribas o subas sale jamás de tu navegador.
¿Por qué mi implementación de CRC-32 en Python da un resultado distinto al de esta calculadora?
Casi siempre es un problema de parámetros, no del algoritmo: revisa que uses el polinomio reflejado 0xEDB88320 (no la forma normal 0x04C11DB7), un valor inicial de 0xFFFFFFFF, entrada y salida reflejadas, y un XOR final de 0xFFFFFFFF. Un solo parámetro distinto —como omitir el XOR final— produce un resultado completamente diferente aunque el resto del algoritmo esté bien implementado.
¿Puedo usar esta herramienta para verificar la integridad de una trama Modbus RTU completa, incluyendo dirección y función?
Sí — pega los bytes en bruto de la trama (dirección de esclavo, código de función y datos, sin el CRC final) en la pestaña de texto o archivo, y compara el CRC-16/MODBUS calculado con los dos últimos bytes de la trama original, que Modbus envía en orden little-endian.
¿Qué pasa si dos archivos distintos producen el mismo CRC-32?
Es posible y esperado en un CRC de 32 bits, con una probabilidad de aproximadamente 1 en 4 mil millones para archivos aleatorios distintos. Como el CRC no está diseñado para resistir colisiones, no debe usarse como prueba de integridad frente a manipulación intencionada — para eso se necesita un hash criptográfico como SHA-256.
¿La calculadora soporta archivos muy grandes, como una imagen de disco?
El límite práctico depende de la memoria disponible en tu navegador, ya que el archivo completo se carga en memoria antes de calcularse el CRC. Funciona bien con archivos de varios megabytes, pero para imágenes de disco de varios gigabytes conviene usar una herramienta de línea de comandos como crc32 o python -c con zlib.