CodeKitHubCe este acest instrument?
CRC înseamnă Cyclic Redundancy Check (verificare ciclică de redundanță), un cod de detectare a erorilor descris pentru prima dată în lucrarea din 1975 a lui W. Wesley Peterson și D.T. Brown, formalizat ulterior în surse precum "A Painless Guide to CRC Error Detection Algorithms" de Ross Williams și standardele ITU-T / ISO 3309. Un CRC tratează un mesaj ca pe un număr binar mare și îl împarte la un polinom generator fix; restul acelei împărțiri este suma de control. Pentru că împărțirea polinomială e ieftin de calculat atât în hardware cât și în software, CRC-urile au devenit verificarea implicită de erori pentru sisteme de stocare și transmisie.
CRC-32 — mai exact varianta cu polinomul 0xEDB88320, o valoare inițială de 0xFFFFFFFF și un XOR final de 0xFFFFFFFF — e standardizat în IEEE 802.3 (Ethernet) și folosit ca sumă de control în arhivele ZIP și gzip, fișierele imagine PNG și nenumărate protocoale de rețea și stocare. E de departe cea mai solicitată variantă CRC, motiv pentru care e algoritmul implicit al acestui instrument. CRC-16/CCITT-FALSE (polinomul 0x1021) și CRC-16/MODBUS (polinomul 0x8005, reflectat) sunt două variante pe 16 biți larg folosite în protocoale seriale precum Modbus RTU, XMODEM și diverse standarde de comunicație industrială și embedded.
E important de înțeles ce nu este un CRC: nu e un hash criptografic. CRC-urile sunt funcții liniare, rapide, fără rezistență la manipulare deliberată — e simplu să construiești un mesaj diferit care produce aceeași valoare CRC. Sunt excelente la detectarea tipului de erori de biți aleatorii cauzate de linii de transmisie zgomotoase, erori de disc sau descărcări trunchiate, dar oferă zero protecție împotriva unui atacator care vrea să modifice date fără să fie detectat.
De ce să-l folosești?
- Programezi un driver Modbus RTU la nivel de biți și dispozitivul slave tot respinge cadrele tale — lipește secvența exactă de octeți aici cu CRC-16/MODBUS selectat pentru a verifica dacă rutina CRC din firmware se potrivește cu valoarea de referință, înainte de a depana altceva.
- Tocmai ai scris o rutină de generare a tabelului CRC-32 de la zero în C sau Rust și vrei să o verifici — rulează vectorul de test standard "123456789" prin acest instrument și confirmă că obții 0xCBF43926 înainte de a avea încredere în implementarea ta pe date reale.
- Un instrument de extragere ZIP aruncă o eroare de nepotrivire CRC pe o intrare și nu ești sigur dacă arhiva e chiar coruptă — recalculează CRC-32 al octeților extrași aici și compară-l cu valoarea stocată în antetul local al fișierului din ZIP.
- Implementezi XMODEM sau un protocol serial similar, iar specificația spune doar "adaugă CRC-16" fără prea multe explicații — calculează-l aici mai întâi ca să știi cum ar trebui să arate octeții finali corecți înainte de a depana codul de transmisie.
- Ai moștenit un proiect embedded cu un câmp de sumă de control nedocumentat și bănuiești că e CRC-16/CCITT-FALSE, nu CRC-16/MODBUS — încearcă ambele variante pe o sarcină cunoscută și vezi care se potrivește cu valoarea pe care dispozitivul o trimite de fapt.
- 100% local: textul sau fișierul tău e procesat integral în JavaScript, în browser, deci nimic nu e încărcat nicăieri.
Cum se folosește
- Alege fila "Text" și lipește sau scrie datele de intrare, sau comută pe fila "Fișier" și alege un fișier de pe dispozitivul tău.
- Selectează algoritmul CRC: CRC-32 (IEEE 802.3, implicit și cel mai comun), CRC-16/CCITT-FALSE sau CRC-16/MODBUS.
- Suma de control se actualizează automat, afișată în hexazecimal, zecimal și binar.
- Apasă "Copiază" lângă orice rezultat pentru a-l copia în clipboard.
Exemplu
Intrare
123456789Rezultat
0xCBF43926 (3421780262)Acesta e vectorul de test standard publicat pentru CRC-32 (IEEE 802.3): CRC-32 al șirului ASCII "123456789" este mereu 0xCBF43926. Poți verifica rezultatul acestui instrument față de orice altă implementare corectă de CRC-32 folosind exact acest șir.
CRC vs. hash-uri criptografice (MD5 / SHA)
Atât CRC-urile cât și hash-urile criptografice reduc datele la o amprentă de dimensiune fixă, dar rezolvă probleme diferite și nu sunt interschimbabile.
| Proprietate | CRC (ex. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Scop | Detectează coruperea accidentală | Detectează modificarea intenționată / verifică integritatea |
| Viteză | Extrem de rapid, hardware/software simplu | Mai lent, mai mult calcul per octet |
| Rezistență la coliziuni | Deloc — trivial de construit intenționat | Conceput să fie imposibil de calculat (SHA-256) sau compromis pentru MD5 |
| Dimensiune tipică | 16 sau 32 biți | 128 biți (MD5) sau 256 biți (SHA-256) |
| Utilizări comune | ZIP/gzip, PNG, Ethernet, Modbus, stocare | Verificări de integritate a fișierelor, semnături digitale, stocare de parole (cu salt) |
Cele trei variante CRC pe scurt
Fiecare variantă e definită de polinomul său, valoarea inițială, dacă biții de intrare/ieșire sunt reflectați și XOR-ul final — greșește oricare dintre aceștia și vei calcula o sumă de control tehnic validă, dar incompatibilă.
| Variantă | Polinom | Valoare inițială | Reflectat | XOR final | Utilizare comună |
|---|---|---|---|---|---|
| CRC-32 (IEEE 802.3) | 0xEDB88320 | 0xFFFFFFFF | Da (intrare & ieșire) | 0xFFFFFFFF | ZIP, gzip, PNG, Ethernet |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | Nu | 0x0000 | XMODEM, protocoale telecom |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | Da (intrare & ieșire) | 0x0000 | Cadre seriale Modbus RTU |
Instrumente similare
Dacă ai nevoie de o sumă de control criptografică în loc de un CRC de detectare a erorilor, aceste instrumente se potrivesc mai bine.
→ Generator de Hash Multi-Algoritm · Generator MD5 · Generator HMAC
Întrebări frecvente
La ce e folosit un CRC?
Un CRC (verificare ciclică de redundanță) e un cod de detectare a erorilor atașat unui bloc de date, astfel încât receptorul îl poate recalcula și confirma că datele nu s-au corupt accidental în timpul stocării sau transmisiei. E integrat în standarde precum framing-ul Ethernet IEEE 802.3, formatele de fișiere ZIP și gzip, imaginile PNG și multe protocoale seriale și industriale precum Modbus.
CRC-32 e la fel cu MD5 sau SHA-256?
Nu. CRC-32 e o sumă de control rapidă, liniară, de detectare a erorilor, fără proprietăți de securitate — e trivial să construiești intenționat două intrări diferite cu aceeași valoare CRC-32. MD5 și SHA-256 sunt funcții hash criptografice concepute pentru a face acest tip de coliziune deliberată imposibil de calculat practic. Folosește CRC-32 pentru a detecta coruperea accidentală (un disc zgâriat, un pachet de rețea pierdut); folosește un hash criptografic din [Generatorul de Hash-uri](/hash-generator) sau [Generatorul MD5](/md5-generator) când ai nevoie de dovadă de manipulare sau garanții de integritate împotriva unui atacator.
Ce variantă CRC-32 folosește acest instrument?
Varianta IEEE 802.3 / ZIP / PNG: polinomul 0xEDB88320 (forma reflectată la nivel de bit a lui 0x04C11DB7), valoare inițială 0xFFFFFFFF, intrare și ieșire reflectate, și un XOR final de 0xFFFFFFFF. Aceasta e varianta folosită de Ethernet, ZIP, gzip și PNG, și cea care produce 0xCBF43926 pentru șirul ASCII "123456789" — vectorul de test standard publicat pentru verificarea unei implementări CRC-32.
Care e diferența dintre CRC-16/CCITT-FALSE și CRC-16/MODBUS?
Ambele sunt CRC-uri pe 16 biți, dar cu polinoame și parametri diferiți. CRC-16/CCITT-FALSE folosește polinomul 0x1021 cu o valoare inițială de 0xFFFF și fără reflectare de biți; e comun în protocoale precum XMODEM și diverse standarde derivate din telecomunicații. CRC-16/MODBUS folosește polinomul 0x8005 (reflectat ca 0xA001), tot cu o valoare inițială de 0xFFFF, dar cu intrare și ieșire reflectate — e suma de control pe care Modbus RTU o adaugă la fiecare cadru serial. Vor produce rezultate diferite pentru aceeași intrare, deci e important să alegi varianta specificată de fapt de protocolul tău țintă.
Pot calcula CRC-ul unui fișier, nu doar text?
Da. Comută pe fila "Fișier" și alege un fișier de pe dispozitivul tău — instrumentul îi citește octeții bruți local, în browser (prin File API), și calculează suma de control exact pe acei octeți, la fel cum ar face un cititor ZIP sau PNG.
Datele mele sunt încărcate pe un server?
Nu. Atât calculul pentru text, cât și cel pentru fișier rulează integral pe partea de client, în JavaScript, folosind un algoritm CRC standard bazat pe tabel. Nimic din ce scrii sau încarci nu părăsește vreodată browserul tău.
De ce implementarea mea proprie de CRC-32 dă un rezultat diferit față de acest instrument?
Cea mai comună cauză e o valoare inițială, un XOR final sau o setare de reflectare de biți nepotrivite — CRC-32 nu e un algoritm fix unic, e o familie de parametri, iar varianta IEEE 802.3/ZIP/PNG folosită de acest instrument pornește de la 0xFFFFFFFF, reflectă atât intrarea cât și ieșirea, și face XOR pe rezultatul final cu 0xFFFFFFFF. Omiterea oricărui pas produce o sumă de control diferită, la fel de "validă" tehnic, dar incompatibilă. Testează-ți implementarea cu vectorul "123456789" → 0xCBF43926 pentru a izola care pas nu se potrivește.
Există o limită de dimensiune pentru încărcarea fișierelor?
Nu există o limită artificială impusă de instrument, dar fișierele foarte mari pot fi lente, deoarece CRC-ul e calculat octet cu octet în JavaScript, în browserul tău. Pentru imagini firmware tipice, intrări ZIP sau cadre de protocol — de la câțiva octeți până la zeci de megabytes — performanța e practic instantă.
Spațiile albe sau stilul de sfârșit de linie afectează CRC-ul textului lipit?
Da — un CRC e calculat peste octeții exacți ai intrării tale, deci o linie nouă finală, un spațiu rătăcit sau capetele de linie stil Windows CRLF versus stil Unix LF vor produce toate o sumă de control diferită, chiar dacă textul vizibil pare identic. Dacă potrivești o sumă de control de la alt instrument, lipește exact ce a fost calculat de acel instrument, inclusiv orice spații albe finale, sau, mai bine, folosește fila Fișier pentru a compara direct octeții bruți.
Pot avea două fișiere complet diferite aceeași valoare CRC-32?
Da, și e de așteptat, nu e o eroare — CRC-32 are doar 2^32 rezultate posibile, deci coliziunile sunt garantate matematic pentru seturi de date suficient de mari, și sunt și triviale de construit deliberat, deoarece CRC-32 nu are rezistență criptografică la coliziuni. Exact de asta CRC-32 e bun pentru detectarea coruperii accidentale, dar nepotrivit pentru verificarea faptului că un fișier nu a fost modificat.
Ce variantă CRC ar trebui să folosesc dacă documentația protocolului nu specifică parametrii?
Începe cu varianta cel mai asociată cu familia acelui protocol: CRC-16/MODBUS pentru comunicație serială Modbus RTU, CRC-16/CCITT-FALSE pentru XMODEM și multe protocoale derivate din telecomunicații, și CRC-32 (varianta IEEE 802.3) pentru orice legat de ZIP, gzip, PNG sau Ethernet. Dacă niciuna nu se potrivește cu un cadru cunoscut ca fiind corect de la dispozitivul real, protocolul poate folosi un polinom sau set de parametri nestandard, în afara celor acoperite de acest instrument.