Suma de verificación CRC-32

Esta herramienta de suma de verificación CRC-32 acepta texto plano, lo serializa como UTF-8 y aplica el perfil IEEE estándar usado por PKZIP, PNG e ISO-HDLC—el mismo camino que produce el famoso valor de comprobación cbf43926 para la cadena ASCII uno-dos-tres-cuatro-cinco-seis-siete-ocho-nueve.

Qué significa CRC-32 y qué polinomio usa esta herramienta

Esta capacidad implementa el polinomio IEEE reflejado que en software se escribe a menudo como cero-x-E-D-B-ocho-ocho-tres-dos-cero, con valor inicial todo unos y un exclusive-or final de todo unos. El texto de entrada se codifica primero como UTF-8 para que caracteres multibyte como letras acentuadas o emoji aporten sus bytes reales en el cable, igual que la mayoría de formatos de archivo y cuerpos HTTP tratan las cadenas. Si una herramienta de terceros discrepa con este endpoint sobre los mismos bytes UTF-8, casi siempre usa otro polinomio, otro init o xor-out, u otra codificación de los mismos caracteres.

Contrato de entrada, campos de respuesta y comportamiento con entrada vacía

La cadena vacía se permite a propósito: muchas bibliotecas CRC documentan el residual de longitud cero como cero, y las canalizaciones que resumen campos opcionales necesitan una respuesta estable en lugar de un fallo duro. Algorithm es siempre la etiqueta CRC-32 barra ISO-HDLC y polynomial es siempre la cadena cero-x-E-D-B-ocho-ocho-tres-dos-cero para que ejemplos OpenAPI y respuestas de soporte citen el perfil sin ambigüedad. No hay conmutador de modo para otras anchuras o polinomios CRC: si necesita CRC-16, Adler-32 o un resumen criptográfico, use una capacidad dedicada para que cada página de destino coincida con una sola intención de búsqueda. Envíe un cuerpo JSON con el campo obligatorio text igual a la cadena cuya suma de verificación desea calcular. Se aceptan los alias input, value, s, string y content para que formularios antiguos y clientes breves sigan enlazando. Los números finitos y los enteros grandes se convierten a cadena; objetos, arrays, booleanos, null, Infinity y NaN provocan invalid_input y no se facturan. Cuando la longitud de origen es cero, la respuesta pone empty en true, crc32 en ocho dígitos cero, crc32_int en cero y bytes en cero. Con entrada no vacía empty es false, bytes iguala la longitud UTF-8 (que puede superar la longitud en caracteres de JavaScript con glifos multibyte), crc32 es el residual hex de ocho dígitos en minúsculas sin prefijo cero-x, y crc32_int es el mismo valor como entero de treinta y dos bits sin signo, útil en lenguajes que prefieren números a cadenas.

Dónde una API de suma de verificación CRC-32 aporta valor

Los desarrolladores pegan fragmentos cortos de configuración, muestras de protocolo y bases de nombres de archivo en una calculadora de suma de verificación CRC-32 cuando necesitan una etiqueta de integridad compacta compatible con herramientas ZIP y PNG sin instalar una utilidad local. Los ingenieros de soporte recalculan residuales a partir del texto del ticket para confirmar que un volcado pegado no se truncó en tránsito. Los laboratorios educativos usan el mismo endpoint para mostrar que cambiar un solo carácter invierte muchos dígitos hex, ilustrando la detección de errores sin introducir maquinaria criptográfica. Como la implementación es parse pura de nivel A, cada llamada exitosa cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente; la validación fallida no consume saldo. Mantenga las cargas bajo el techo de caracteres documentado, trate el campo hex como destino canónico de pegado, y obtendrá valores CRC-32 reproducibles y compatibles con ZIP para documentación, SDK, workers en el borde y demostraciones de aula sin levantar un servicio de hash aparte.