CodeKitHubChe cos'è questo strumento?
CRC è l'acronimo di Cyclic Redundancy Check, un codice per il rilevamento di errori descritto per la prima volta nell'articolo del 1975 di W. Wesley Peterson e D.T. Brown, e successivamente formalizzato in riferimenti come "A Painless Guide to CRC Error Detection Algorithms" di Ross Williams e negli standard ITU-T / ISO 3309. Un CRC tratta un messaggio come un grande numero binario e lo divide per un polinomio generatore fisso; il resto di quella divisione è il checksum. Poiché la divisione polinomiale è economica da calcolare sia in hardware che in software, i CRC sono diventati il controllo di errore predefinito per i sistemi di archiviazione e trasmissione.
Il CRC-32 — nello specifico la variante con polinomio 0xEDB88320, valore iniziale 0xFFFFFFFF e XOR finale 0xFFFFFFFF — è standardizzato in IEEE 802.3 (Ethernet) ed è usato come checksum negli archivi ZIP e gzip, nei file immagine PNG e in innumerevoli protocolli di rete e archiviazione. È di gran lunga la variante CRC più richiesta, motivo per cui è l'algoritmo predefinito in questo strumento. CRC-16/CCITT-FALSE (polinomio 0x1021) e CRC-16/MODBUS (polinomio 0x8005, riflesso) sono due varianti a 16 bit ampiamente utilizzate in protocolli seriali come Modbus RTU, XMODEM e vari standard di comunicazione embedded/industriali.
È importante capire cosa un CRC non è: non è un hash crittografico. I CRC sono funzioni lineari veloci e privi di resistenza a manipolazioni deliberate — è semplice costruire un messaggio diverso che produca lo stesso valore CRC. Sono eccellenti nel rilevare il tipo di bit-flip casuali causati da linee di trasmissione rumorose, errori del disco o download troncati, ma non offrono alcuna protezione contro un avversario che voglia manomettere i dati senza essere rilevato.
Perché usarlo?
- Stai facendo bit-banging su un driver Modbus RTU e il dispositivo slave continua a rifiutare i tuoi frame — incolla qui la sequenza esatta di byte con CRC-16/MODBUS selezionato per verificare se la routine CRC del tuo firmware corrisponde al valore di riferimento prima di indagare altrove.
- Hai appena scritto da zero una routine di generazione tabella CRC-32 in C o Rust e vuoi un controllo di sanità — passa il vettore di test standard "123456789" in questo strumento e conferma di ottenere 0xCBF43926 prima di fidarti della tua implementazione su dati reali.
- Uno strumento di estrazione ZIP restituisce un errore di CRC non corrispondente su una voce e non sei sicuro se l'archivio sia davvero corrotto — ricalcola qui il CRC-32 dei byte estratti e confrontalo con il valore memorizzato nell'header locale del file ZIP.
- Stai implementando XMODEM o un protocollo seriale simile e la specifica dice solo "aggiungi il CRC-16" senza molti dettagli — calcolalo qui prima, così sai come dovrebbero apparire i byte finali corretti prima di iniziare a debuggare il codice di trasmissione.
- Hai ereditato un progetto embedded con un campo checksum non documentato e sospetti che sia CRC-16/CCITT-FALSE invece di CRC-16/MODBUS — prova entrambe le varianti su un payload noto e vedi quale corrisponde al valore che il dispositivo invia realmente.
- 100% locale: il tuo testo o file viene elaborato interamente in JavaScript nel tuo browser, quindi nulla viene caricato altrove.
Come si usa
- Scegli la scheda "Text" e incolla o digita il tuo input, oppure passa alla scheda "File" e seleziona un file dal tuo dispositivo.
- Seleziona l'algoritmo CRC: CRC-32 (IEEE 802.3, quello predefinito e più comune), CRC-16/CCITT-FALSE oppure CRC-16/MODBUS.
- Il checksum si aggiorna automaticamente, mostrato in esadecimale, decimale e binario.
- Clicca su "Copy" accanto a qualsiasi risultato per copiarlo negli appunti.
Esempio
Input
123456789Risultato
0xCBF43926 (3421780262)Questo è il vettore di test standard pubblicato per CRC-32 (IEEE 802.3): il CRC-32 della stringa ASCII "123456789" è sempre 0xCBF43926. Puoi verificare l'output di questo strumento rispetto a qualsiasi altra implementazione CRC-32 corretta usando esattamente questa stringa.
CRC vs. hash crittografici (MD5 / SHA)
Sia i CRC che gli hash crittografici riducono i dati a un'impronta di dimensione fissa, ma risolvono problemi diversi e non sono intercambiabili.
| Proprietà | CRC (es. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Scopo | Rilevare corruzioni accidentali | Rilevare manomissioni intenzionali / verificare l'integrità |
| Velocità | Estremamente veloce, hardware/software semplice | Più lento, più calcolo per byte |
| Resistenza alle collisioni | Nessuna — banale da progettare di proposito | Progettata per essere computazionalmente infattibile (SHA-256) o violata nel caso di MD5 |
| Dimensione tipica | 16 o 32 bit | 128 bit (MD5) o 256 bit (SHA-256) |
| Usi comuni | ZIP/gzip, PNG, Ethernet, Modbus, archiviazione | Controlli di integrità dei file, firme digitali, memorizzazione delle password (con salting) |
Strumenti correlati
Se hai bisogno di un checksum crittografico anziché di un CRC per il rilevamento errori, questi strumenti sono più adatti.
→ Multi-Algorithm Hash Generator · MD5 Generator · HMAC Generator
Le tre varianti CRC in breve
Ogni variante è definita dal suo polinomio, valore iniziale, se i bit di input/output sono riflessi, e lo XOR finale — sbagliare anche uno solo di questi parametri produce un checksum tecnicamente valido ma incompatibile.
| Variante | Polinomio | Valore iniziale | Riflesso | XOR finale | Uso comune |
|---|---|---|---|---|---|
| CRC-32 (IEEE 802.3) | 0xEDB88320 | 0xFFFFFFFF | Sì (in e out) | 0xFFFFFFFF | ZIP, gzip, PNG, Ethernet |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | No | 0x0000 | XMODEM, protocolli telecom |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | Sì (in e out) | 0x0000 | Frame seriali Modbus RTU |
Domande frequenti
A cosa serve un CRC?
Un CRC (controllo a ridondanza ciclica) è un codice di rilevamento errori aggiunto a un blocco di dati in modo che il destinatario possa ricalcolarlo e confermare che i dati non siano stati corrotti accidentalmente durante l'archiviazione o la trasmissione. È integrato in standard come il framing Ethernet IEEE 802.3, i formati file ZIP e gzip, le immagini PNG e molti protocolli seriali e industriali come Modbus.
Il CRC-32 è uguale a MD5 o SHA-256?
No. Il CRC-32 è un checksum di rilevamento errori veloce e lineare, privo di proprietà di sicurezza — è banale costruire di proposito due input diversi con lo stesso valore CRC-32. MD5 e SHA-256 sono funzioni hash crittografiche progettate per rendere questo tipo di collisione deliberata computazionalmente infattibile. Usa il CRC-32 per rilevare corruzioni accidentali (un disco graffiato, un pacchetto di rete perso); usa un hash crittografico dal nostro [Generatore di Hash](/hash-generator) o [Generatore MD5](/md5-generator) quando hai bisogno di rilevamento delle manomissioni o garanzie di integrità contro un avversario.
Quale variante di CRC-32 usa questo strumento?
La variante IEEE 802.3 / ZIP / PNG: polinomio 0xEDB88320 (la forma riflessa a livello di bit di 0x04C11DB7), valore iniziale 0xFFFFFFFF, input e output riflessi, e uno XOR finale di 0xFFFFFFFF. È la variante usata da Ethernet, ZIP, gzip e PNG, ed è quella che produce 0xCBF43926 per la stringa ASCII "123456789" — il vettore di test standard pubblicato per verificare un'implementazione CRC-32.
Qual è la differenza tra CRC-16/CCITT-FALSE e CRC-16/MODBUS?
Entrambi sono CRC a 16 bit ma con polinomi e parametri diversi. CRC-16/CCITT-FALSE usa il polinomio 0x1021 con un valore iniziale di 0xFFFF e nessuna riflessione dei bit; è comune in protocolli come XMODEM e vari standard di telecomunicazione. CRC-16/MODBUS usa il polinomio 0x8005 (riflesso come 0xA001), anch'esso con valore iniziale 0xFFFF, ma con input e output riflessi — è il checksum che Modbus RTU aggiunge a ogni frame seriale. Producono risultati diversi per lo stesso input, quindi è importante scegliere la variante effettivamente specificata dal protocollo di destinazione.
Posso calcolare il CRC di un file, non solo di un testo?
Sì. Passa alla scheda "File" e scegli un file dal tuo dispositivo: lo strumento ne legge i byte grezzi localmente nel browser (tramite le File API) e calcola il checksum esattamente su quei byte, allo stesso modo in cui farebbe un lettore ZIP o PNG.
I miei dati vengono caricati su un server?
No. Sia il calcolo del testo che quello del file avvengono interamente lato client in JavaScript usando un algoritmo CRC standard basato su tabelle. Nulla di ciò che digiti o carichi lascia mai il tuo browser.
Perché la mia implementazione CRC-32 scritta a mano dà un risultato diverso da questo strumento?
La causa più comune è un valore iniziale, uno XOR finale o un'impostazione di riflessione dei bit non corrispondenti — il CRC-32 non è un unico algoritmo fisso, è una famiglia di parametri, e la variante IEEE 802.3/ZIP/PNG usata da questo strumento parte da 0xFFFFFFFF, riflette sia input che output, e fa lo XOR del risultato finale con 0xFFFFFFFF. Saltare anche solo uno di questi passaggi produce un checksum diverso, tecnicamente valido ma incompatibile. Testa la tua implementazione contro il vettore "123456789" → 0xCBF43926 per isolare quale passaggio non torna.
C'è un limite di dimensione per il caricamento del file?
Non c'è un limite artificiale imposto dallo strumento, ma file molto grandi possono essere lenti dato che il CRC viene calcolato byte per byte in JavaScript nel tuo browser. Per firmware tipici, voci ZIP o frame di protocollo — da pochi byte fino a decine di megabyte — le prestazioni sono di fatto istantanee.
Gli spazi bianchi o lo stile di fine riga influiscono sul CRC di un testo incollato?
Sì — un CRC viene calcolato sui byte esatti del tuo input, quindi un a-capo finale, uno spazio vagante, o le terminazioni di riga CRLF stile Windows contro LF stile Unix produrranno tutti un checksum diverso anche se il testo visibile sembra identico. Se stai confrontando un checksum con un altro strumento, incolla esattamente ciò che quello strumento ha hashato, spazi finali inclusi, oppure meglio, usa la scheda File per confrontare i byte grezzi direttamente.
Due file completamente diversi possono avere lo stesso valore CRC-32?
Sì, e questo è previsto, non un bug — il CRC-32 ha solo 2^32 output possibili, quindi le collisioni sono matematicamente garantite per dataset abbastanza grandi, e sono anche banali da costruire deliberatamente dato che il CRC-32 non ha resistenza crittografica alle collisioni. È esattamente per questo che il CRC-32 va bene per rilevare corruzioni accidentali ma non è adatto a verificare che un file non sia stato manomesso.
Quale variante CRC dovrei usare se la documentazione del protocollo non specifica i parametri?
Inizia con la variante più associata a quella famiglia di protocolli: CRC-16/MODBUS per la comunicazione seriale Modbus RTU, CRC-16/CCITT-FALSE per XMODEM e molti protocolli derivati dalle telecomunicazioni, e CRC-32 (variante IEEE 802.3) per tutto ciò che riguarda ZIP, gzip, PNG o Ethernet. Se nessuna delle due corrisponde a un frame noto e corretto dal dispositivo reale, il protocollo potrebbe usare un polinomio o un set di parametri non standard fuori da quanto copre questo strumento.