Checksum CRC-32

Esta ferramenta de checksum CRC-32 aceita texto simples, serializa-o como UTF-8 e aplica o perfil IEEE padrão usado por PKZIP, PNG e ISO-HDLC—o mesmo caminho que produz o famoso valor de verificação cbf43926 para a string ASCII um-dois-três-quatro-cinco-seis-sete-oito-nove.

O que CRC-32 significa e qual polinômio esta ferramenta usa

Esta capacidade implementa o polinômio IEEE refletido frequentemente escrito em software como zero-x-E-D-B-oito-oito-três-dois-zero, com valor inicial todos uns e um exclusive-or final de todos uns. O texto de entrada é primeiro codificado como UTF-8 para que caracteres multibyte como letras acentuadas ou emoji contribuam com seus bytes reais no fio, como a maioria dos formatos de arquivo e corpos HTTP trata strings. Se uma ferramenta de terceiros discordar deste endpoint nos mesmos bytes UTF-8, quase sempre usa outro polinômio, outro init ou xor-out, ou outra codificação dos mesmos caracteres.

Contrato de entrada, campos de resposta e comportamento com entrada vazia

A string vazia é permitida de propósito: muitas bibliotecas CRC documentam o residual de comprimento zero como zero, e pipelines que resumem campos opcionais precisam de uma resposta estável em vez de falha dura. Algorithm é sempre o rótulo CRC-32 barra ISO-HDLC e polynomial é sempre a string zero-x-E-D-B-oito-oito-três-dois-zero para que exemplos OpenAPI e respostas de suporte citem o perfil sem ambiguidade. Não há chave de modo para outras larguras ou polinômios CRC: se você precisa de CRC-16, Adler-32 ou um digest criptográfico, use uma capacidade dedicada para que cada landing page corresponda a uma única intenção de busca. Envie um corpo JSON com o campo obrigatório text definido como a string cujo checksum você deseja calcular. Os aliases input, value, s, string e content são aceitos para que formulários antigos e clientes curtos ainda vinculam. Números finitos e inteiros grandes são convertidos em string; objetos, arrays, booleanos, null, Infinity e NaN geram invalid_input e não são cobrados. Quando o comprimento de origem é zero, a resposta define empty como true, crc32 com oito dígitos zero, crc32_int como zero e bytes como zero. Para entrada não vazia empty é false, bytes é igual ao comprimento UTF-8 (que pode exceder o comprimento em caracteres JavaScript para glifos multibyte), crc32 é o residual hex de oito dígitos em minúsculas sem prefixo zero-x, e crc32_int é o mesmo valor como inteiro de trinta e dois bits sem sinal, útil em linguagens que preferem números a strings.

Onde uma API de checksum CRC-32 justifica o uso

Desenvolvedores colam fragmentos curtos de configuração, amostras de protocolo e bases de nomes de arquivo em uma calculadora de checksum CRC-32 quando precisam de uma tag de integridade compacta compatível com ferramentas ZIP e PNG sem instalar utilitário local. Engenheiros de suporte recalculam residuais a partir do texto do ticket para confirmar que um dump colado não foi truncado em trânsito. Laboratórios educativos usam o mesmo endpoint para mostrar que mudar um caractere inverte muitos dígitos hex, ilustrando detecção de erros sem introduzir maquinaria criptográfica. Como a implementação é parse pura de nível A, cada chamada bem-sucedida custa o preço base publicado US$ 0,002 sem tokens de modelo e sem rede de saída; validação falha não consome saldo. Mantenha os payloads abaixo do teto de caracteres documentado, trate o campo hex como destino canônico de cola, e você obtém valores CRC-32 reproduzíveis e compatíveis com ZIP para docs, SDKs, workers de borda e demos de sala de aula sem levantar um serviço de hash separado.