Calculadora CRC-16 XMODEM
Los nueve caracteres 123456789 dan el valor CRC-16/XMODEM 31c3, o 12739 en decimal, el resultado de control documentado del perfil CCITT con arranque en cero que usan la transferencia clásica de archivos y el firmware. Pegue cualquier texto para obtener su suma. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Texto
- 123456789
- Resultado
- 31c3
- Crc16
- 31c3
- Hex
- 31c3
- Decimal
- 12 739
CRC-16/XMODEM es un control de redundancia cíclica de dieciséis bits usado en el encuadre clásico de transferencia de ficheros, firmware embebido y pilas de protocolo que necesitan una palabra compacta de integridad en lugar de un hash criptográfico completo. Ingenieros, estudiantes y equipos de soporte suelen necesitar el mismo resultado de libro para una cadena corta: el polinomio generador CCITT 0x1021, registro inicial cero (la semilla XMODEM), sin reflexión de bits y XOR final cero—exactamente el perfil CRC-16/XMODEM cuyo valor de comprobación para los dígitos ASCII del uno al nueve es 31C3 en hexadecimal. Esta herramienta de checksum CRC-16 XMODEM acepta texto no vacío, lo codifica como UTF-8, ejecuta ese bucle determinista de desplazamiento y XOR y devuelve el checksum de dieciséis bits como cuatro dígitos hexadecimales en minúsculas junto con el valor decimal y un resumen breve.
Qué calcula el CRC-16/XMODEM con polinomio 0x1021 y por qué importa la palabra hex
Un control de redundancia cíclica trata el mensaje como un polinomio sobre el cuerpo de Galois de dos elementos y lo divide por un polinomio generador fijo, dejando un resto que se convierte en el checksum. En CRC-16 el resto tiene dieciséis bits de ancho, de modo que el resultado entero cabe en una palabra y se escribe de forma natural como cuatro dígitos hexadecimales.
El generador usado por XMODEM y muchos ejemplos al estilo CCITT es 0x1021, que se expande a x a la dieciséis más x a la doce más x a la cinco más uno. De forma crítica, el perfil XMODEM siembra el registro con cero en lugar de todos unos; esa única elección separa CRC-16/XMODEM de CRC-16/CCITT-FALSE, que usa el mismo poli pero init 0xFFFF y por tanto valores de comprobación distintos para la misma carga.
En software la división se realiza haciendo OR exclusivo de cada byte de entrada en los ocho bits altos de un registro de dieciséis bits y desplazando a la izquierda ocho veces, aplicando OR exclusivo con el generador cuando el bit alto está activo. Esta página usa siempre ese algoritmo no reflejado con valor inicial cero y XOR final cero, el perfil cuyo valor de comprobación documentado para la cadena ASCII de nueve bytes uno dos tres cuatro cinco seis siete ocho nueve es 31C3.
La respuesta también repite el entero decimal, la cadena de polinomio 0x1021, la etiqueta de algoritmo CRC-16/XMODEM, el recuento de bytes UTF-8 y el texto original para que los clientes muestren una línea de auditoría completa sin recalcular metadatos. Como CRC-16 no es resistente a colisiones ni lleva clave, trátelo como comprobación de trama o de corrupción accidental, no como prueba de autenticidad; prefiera digests de la familia SHA cuando la intención de búsqueda sea el hashing criptográfico y no un CRC de dos bytes.
Dónde resulta útil una suma CRC-16 XMODEM
Autores de firmware y estudiantes de protocolos serie usan una calculadora de checksum CRC-16 XMODEM para verificar restos calculados a mano frente al polinomio CCITT con semilla cero sin escribir un bucle de desplazamiento en cada lenguaje. Las plataformas educativas y los plugins LMS necesitan un oráculo determinista que rechace la entrada vacía en lugar de devolver cero para el mensaje vacío, de modo que los autoevaluadores distingan respuestas ausentes de un checksum real de cero.
Los sitios de contenido que compiten por CRC-16 XMODEM, calculadora CRC16 XMODEM o checksum poli CCITT 0x1021 se benefician de una herramienta en vivo cuya ruta gratuita coincide byte a byte con la automatización de pago sobre el mismo módulo puro. Los fallos de validación no consumen saldo tras el rechazo.
Combine con landings de CRC-8, CRC-32 o hash criptográfico solo cuando la intención de búsqueda vaya más allá de una comprobación de trama XMODEM de dieciséis bits—mantenga esta página centrada en CRC-16/XMODEM con poli 0x1021 y semilla cero para que la intención SEO siga nítida y no colisione con variantes MODBUS, IBM o CCITT-FALSE que comparten nombre de familia pero no el mismo vector de comprobación.
Qué puede hacer con ella
Comprobaciones XMODEM y protocolos serie
Verifique que una cadena de carga produce el tráiler CRC-16/XMODEM de dieciséis bits esperado bajo el poli 0x1021 e init cero antes de comparar logs de dispositivo o vectores de prueba unitaria.
Demostraciones de resto CRC en el aula
El profesorado muestra el valor clásico 123456789 → 31C3 y deja que el alumnado recalcule otras cadenas cortas sin instalar una biblioteca CRC.
Preguntas frecuentes
¿Qué parámetros CRC-16 usa esta herramienta?
CRC-16/XMODEM: poli 0x1021 (CCITT), init 0x0000, sin reflexión, xorout 0x0000. El valor de comprobación documentado para ASCII 123456789 es 31C3.
¿Qué ocurre si el texto está vacío?
Se exige una cadena no vacía; la entrada vacía no se trata como un checksum cero exitoso.
¿Es gratuita la calculadora de checksum CRC-16 XMODEM?
La herramienta del navegador se ejecuta gratis en su dispositivo.
¿Es CRC-16/XMODEM lo mismo que CRC-16/CCITT-FALSE?
No. Ambos usan el poli 0x1021, pero XMODEM siembra el registro con cero mientras CCITT-FALSE usa 0xFFFF, de modo que los valores de comprobación difieren. Esta herramienta implementa solo XMODEM.
¿Cómo se cuentan las letras con tilde y otros caracteres no ASCII?
El texto se codifica en UTF-8 antes del cálculo, así que un carácter que ocupa varios bytes aporta cada uno de ellos, igual que lo vería un dispositivo embebido que recibiera la misma secuencia UTF-8.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/enc/crc16-xmodem \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"123456789"}'const res = await fetch("https://api.kit.forhosting.com/enc/crc16-xmodem", {
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/crc16-xmodem",
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/crc16-xmodem", 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/crc16-xmodem", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"text": "123456789"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.crc16_xmodem",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
La entrada vacía se rechaza con invalid_input para que quien llame no confunda un campo ausente con un checksum cero real.
Contrato de entrada, errores de cadena vacía y forma de la respuesta JSON
La cadena se codifica como UTF-8 antes del bucle CRC, de forma que los caracteres multibyte aportan cada byte de unidad de código exactamente como lo haría un dispositivo embebido si recibiera el mismo flujo UTF-8. Fije tanto una ruta de éxito como un error de entrada vacía en la integración continua para que cambios accidentales de poly o init no pasen desapercibidos. Los campos opcionales nulos se omiten en lugar de emitirse como null, acorde al contrato del renderizador declarativo para formularios web limpios. Envíe por POST un cuerpo JSON con un único campo de cadena obligatorio llamado text: cualquier secuencia no vacía de caracteres que desee verificar. Se aceptan los alias input, value, s, data, message y payload para el mismo campo, de modo que los stubs de SDK y los envíos de formulario sigan siendo flexibles. Si falta text, el valor no es una cadena o la cadena está vacía, la petición falla con invalid_input y un mensaje claro de que se exige una cadena no vacía; esos fallos no se facturan en la API prepago. En caso de éxito el cuerpo incluye result, crc16 y hex todos con el mismo checksum hexadecimal de cuatro dígitos en minúsculas; decimal con el entero de cero a sesenta y cinco mil quinientos treinta y cinco; polynomial fijo en 0x1021; algorithm fijo en CRC-16/XMODEM; input_bytes igual a la longitud UTF-8; text repitiendo la entrada; y message resumiendo el recuento de bytes y el resultado hex. Mantenga las cargas en tamaños de texto ordinarios adecuados a una llamada de ítem en un Worker isolate; esta herramienta es para cadenas cortas y fragmentos de protocolo, no para binarios de varios megabytes.
Dónde aporta valor una API de checksum CRC-16 XMODEM y cómo funciona el precio
Use la herramienta gratuita en el navegador para comprobaciones puntuales; use la API prepago de KIT desde backends, funciones serverless y SDK cuando necesite un contrato estable bajo saldo a $0.002 por ítem exitoso.
Casos de integración
Fixtures de CI para código de trama
Los pipelines fijan salidas hex deterministas de CRC-16/XMODEM y el error de entrada vacía para que cambios accidentales de poly o init fallen de inmediato.
Preguntas técnicas
¿Cómo se calcula un checksum CRC-16 XMODEM de texto?
Envíe JSON con un campo de cadena no vacío text. La API codifica la cadena en UTF-8, ejecuta CRC-16/XMODEM con polinomio 0x1021 e init 0x0000 y devuelve la palabra como cuatro dígitos hex en minúsculas en result, crc16 y hex.