CodeKitHubO que é esta ferramenta?
CRC significa Cyclic Redundancy Check (verificação de redundância cíclica), um código de detecção de erros descrito pela primeira vez no artigo de 1975 de W. Wesley Peterson e D.T. Brown, e posteriormente formalizado em referências como "A Painless Guide to CRC Error Detection Algorithms", de Ross Williams e nos padrões ITU-T / ISO 3309. Um CRC trata uma mensagem como um grande número binário e a divide por um polinômio gerador fixo; o resto dessa divisão é o checksum. Como a divisão polinomial é barata de computar tanto em hardware quanto em software, os CRCs se tornaram a verificação de erros padrão em sistemas de armazenamento e transmissão.
O CRC-32 — especificamente a variante com polinômio 0xEDB88320, valor inicial 0xFFFFFFFF e XOR final de 0xFFFFFFFF — é padronizado no IEEE 802.3 (Ethernet) e usado como checksum em arquivos ZIP e gzip, imagens PNG e inúmeros protocolos de rede e armazenamento. É, de longe, a variante de CRC mais requisitada, e por isso é o algoritmo padrão desta ferramenta. CRC-16/CCITT-FALSE (polinômio 0x1021) e CRC-16/MODBUS (polinômio 0x8005, refletido) são duas variantes de 16 bits amplamente usadas, encontradas em protocolos seriais como Modbus RTU, XMODEM e diversos padrões de comunicação embarcada e industrial.
É importante entender o que um CRC não é: ele não é um hash criptográfico. CRCs são funções rápidas e lineares, sem nenhuma resistência a manipulação deliberada — é simples construir uma mensagem diferente que produza o mesmo valor de CRC. Eles são excelentes para detectar o tipo de inversão aleatória de bits causada por linhas de transmissão ruidosas, erros de disco ou downloads truncados, mas não oferecem proteção alguma contra um adversário que deseja adulterar dados sem ser detectado.
Por que usar?
- Você está escrevendo firmware para um dispositivo embarcado e não tem certeza se sua rotina CRC-32 caseira está correta, então quer conferir o resultado contra o vetor de teste padrão "123456789".
- Está desenvolvendo um equipamento serial que conversa com um CLP via Modbus RTU, e o valor CRC-16/MODBUS anexado ao quadro não bate com o esperado pela especificação, travando a depuração.
- Recuperou manualmente uma entrada de um arquivo ZIP corrompido e quer conferir se os bytes recuperados são realmente válidos, recalculando o CRC-32 a partir do conteúdo bruto e comparando com o valor gravado no cabeçalho.
- Recebeu um relatório de que uma imagem PNG está corrompida, extraiu os bytes do chunk suspeito e quer comparar o CRC gravado com o valor recalculado para isolar a causa do problema.
- Está reescrevendo o parser de um protocolo de comunicação interno e quer validar sua implementação de CRC-16/CCITT-FALSE para XMODEM usando uma ferramenta independente antes de colocar em produção.
- Os dados que você está depurando ainda são um firmware não lançado ou um protocolo proprietário confidencial — por isso prefere calcular tudo localmente no navegador em vez de enviar a um servidor.
Como usar
- Escolha a aba "Texto" e cole ou digite sua entrada, ou mude para a aba "Arquivo" e escolha um arquivo do seu dispositivo.
- Selecione o algoritmo de CRC: CRC-32 (IEEE 802.3, o padrão e mais comum), CRC-16/CCITT-FALSE ou CRC-16/MODBUS.
- O checksum é atualizado automaticamente, exibido em hexadecimal, decimal e binário.
- Clique em "Copiar" ao lado de qualquer resultado para copiá-lo para a área de transferência.
Exemplo
Entrada
123456789Resultado
0xCBF43926 (3421780262)Este é o vetor de teste padrão e publicado do CRC-32 (IEEE 802.3): o CRC-32 da string ASCII "123456789" é sempre 0xCBF43926. Você pode conferir o resultado desta ferramenta em relação a qualquer outra implementação correta de CRC-32 usando exatamente essa string.
CRC vs. hashes criptográficos (MD5 / SHA)
Tanto os CRCs quanto os hashes criptográficos reduzem dados a uma impressão digital de tamanho fixo, mas resolvem problemas diferentes e não são intercambiáveis.
| Propriedade | CRC (ex.: CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Propósito | Detectar corrupção acidental | Detectar adulteração intencional / verificar integridade |
| Velocidade | Extremamente rápido, hardware/software simples | Mais lento, mais computação por byte |
| Resistência a colisões | Nenhuma — trivial de engendrar propositalmente | Projetado para ser computacionalmente inviável (SHA-256) ou quebrado no caso do MD5 |
| Tamanho típico | 16 ou 32 bits | 128 bits (MD5) ou 256 bits (SHA-256) |
| Usos comuns | ZIP/gzip, PNG, Ethernet, Modbus, armazenamento | Verificação de integridade de arquivos, assinaturas digitais, armazenamento de senhas (com salt) |
Ferramentas relacionadas
Se você precisa de um checksum criptográfico em vez de um CRC de detecção de erros, estas ferramentas são mais adequadas.
→ Gerador de Hash Multi-Algoritmo · Gerador de MD5 · Gerador de HMAC
Uso prático em desenvolvimento embarcado e comunicação serial
Em projetos que lidam com protocolos industriais e embarcados como Modbus RTU e XMODEM, um erro na implementação do CRC no fim do quadro costuma causar aquele sintoma frustrante em que "a comunicação parece funcionar, mas os dados chegam errados". Esse tipo de problema é difícil de diagnosticar apenas comparando a lógica de CRC implementada de cada lado no papel — o caminho mais confiável é conferir primeiro o valor correto para uma entrada conhecida nesta calculadora e depois comparar byte a byte com a sua própria implementação.
Vale atenção especial ao fato de que o termo genérico "CRC-16" esconde muitas variantes diferentes, cada uma com uma combinação própria de polinômio, valor inicial, reflexão de bits de entrada/saída e XOR final — e cada combinação produz um resultado diferente. Quando a documentação de um equipamento só diz "CRC-16" sem especificar os parâmetros exatos, o jeito mais prático de descobrir qual variante está em uso é pegar um quadro de exemplo com CRC conhecido e testá-lo nesta ferramenta tanto como CRC-16/CCITT-FALSE quanto como CRC-16/MODBUS até encontrar o que bate.
Perguntas frequentes
Para que serve um CRC?
Um CRC (verificação de redundância cíclica) é um código de detecção de erros anexado a um bloco de dados para que o receptor possa recalculá-lo e confirmar que os dados não foram acidentalmente corrompidos durante o armazenamento ou a transmissão. Ele está embutido em padrões como o enquadramento Ethernet IEEE 802.3, os formatos de arquivo ZIP e gzip, imagens PNG e muitos protocolos seriais e industriais, como o Modbus.
CRC-32 é o mesmo que MD5 ou SHA-256?
Não. O CRC-32 é um checksum de detecção de erros rápido e linear, sem propriedades de segurança — é trivial construir propositalmente duas entradas diferentes com o mesmo valor de CRC-32. MD5 e SHA-256 são funções hash criptográficas projetadas para tornar esse tipo de colisão deliberada computacionalmente inviável. Use o CRC-32 para detectar corrupção acidental (um disco arranhado, um pacote de rede perdido); use um hash criptográfico do nosso [Gerador de Hash](/hash-generator) ou [Gerador de MD5](/md5-generator) quando precisar de evidência de adulteração ou garantias de integridade contra um adversário.
Qual variante de CRC-32 esta ferramenta usa?
A variante IEEE 802.3 / ZIP / PNG: polinômio 0xEDB88320 (a forma bit-refletida de 0x04C11DB7), valor inicial 0xFFFFFFFF, entrada e saída refletidas, e um XOR final de 0xFFFFFFFF. Essa é a variante usada por Ethernet, ZIP, gzip e PNG, e a que produz 0xCBF43926 para a string ASCII "123456789" — o vetor de teste padrão e publicado para verificar uma implementação de CRC-32.
Qual é a diferença entre CRC-16/CCITT-FALSE e CRC-16/MODBUS?
Ambos são CRCs de 16 bits, mas com polinômios e parâmetros diferentes. O CRC-16/CCITT-FALSE usa o polinômio 0x1021 com valor inicial 0xFFFF e sem reflexão de bits; é comum em protocolos como XMODEM e diversos padrões de telecomunicações. O CRC-16/MODBUS usa o polinômio 0x8005 (refletido como 0xA001), também com valor inicial 0xFFFF, mas com entrada e saída refletidas — é o checksum que o Modbus RTU anexa a cada quadro serial. Eles produzem resultados diferentes para a mesma entrada, por isso é importante escolher a variante que o protocolo de destino realmente especifica.
Posso calcular o CRC de um arquivo, não apenas de texto?
Sim. Mude para a aba "Arquivo" e escolha um arquivo do seu dispositivo — a ferramenta lê seus bytes brutos localmente no navegador (via File API) e calcula o checksum exatamente sobre esses bytes, da mesma forma que um leitor de ZIP ou PNG faria.
Meus dados são enviados a um servidor?
Não. Tanto o cálculo de texto quanto o de arquivo são executados inteiramente no lado do cliente, em JavaScript, usando um algoritmo CRC padrão baseado em tabelas. Nada do que você digita ou envia jamais sai do seu navegador.
O resultado não bate com o valor documentado no manual do meu dispositivo Modbus. Por quê?
A causa mais comum é a ordem dos bytes (endianness). O CRC-16/MODBUS costuma ser anexado ao quadro com o byte menos significativo primeiro, mas alguns fabricantes documentam o valor na ordem inversa. Primeiro compare o valor hexadecimal desta ferramenta ignorando a ordem dos bytes; se ainda assim não bater, é possível que o dispositivo use uma variante diferente de valor inicial ou XOR final.
Se um arquivo tem CRC-32 e MD5 publicados, qual devo conferir?
Depende do objetivo. Para verificar erro de transferência ou corrupção de disco, o CRC-32 já é suficiente. Para garantir que o arquivo não foi adulterado de propósito, confira o MD5 (ou idealmente SHA-256) — o CRC-32 é fácil de colidir intencionalmente, então não serve como garantia de integridade contra adulteração.
Por que a mesma entrada de 8 bytes produz valores completamente diferentes em CRC-16/CCITT-FALSE e CRC-32?
Cada algoritmo usa um polinômio gerador, tamanho de registrador, valor inicial e tratamento de reflexão de bits diferentes. Mesmo com os mesmos dados de entrada, mudar qualquer um desses parâmetros produz um resultado completamente não relacionado. Sempre escolha o algoritmo que corresponde exatamente ao especificado na documentação do protocolo.
Dá para calcular o CRC de arquivos grandes só com o navegador?
Sim. Como a ferramenta lê o arquivo via File API e processa os bytes com um algoritmo CRC baseado em tabelas, arquivos de dezenas de megabytes são calculados em velocidade prática. Para arquivos muito grandes (centenas de MB), o desempenho depende da memória disponível no navegador e pode ficar mais lento.