CodeKitHubVad är detta verktyg?
CRC står för Cyclic Redundancy Check, en felupptäckande kod som första gången beskrevs 1975 av W. Wesley Peterson och D.T. Brown, och senare formaliserades i referenser som Ross Williams "A Painless Guide to CRC Error Detection Algorithms" och ITU-T/ISO 3309-standarderna. En CRC behandlar ett meddelande som ett stort binärt tal och delar det med ett fast generatorpolynom; resten av den divisionen är kontrollsumman. Eftersom polynomdivision är billigt att beräkna både i hårdvara och mjukvara blev CRC:er standard för felkontroll inom lagring och överföring.
CRC-32 — specifikt varianten med polynom 0xEDB88320, ett startvärde på 0xFFFFFFFF och en avslutande XOR med 0xFFFFFFFF — är standardiserad i IEEE 802.3 (Ethernet) och används som kontrollsumma i ZIP- och gzip-arkiv, PNG-bilder och otaliga nätverks- och lagringsprotokoll. Det är den absolut mest efterfrågade CRC-varianten, vilket är varför den är standardalgoritmen i det här verktyget. CRC-16/CCITT-FALSE (polynom 0x1021) och CRC-16/MODBUS (polynom 0x8005, speglat) är två vitt använda 16-bitarsvarianter som finns i serieprotokoll som Modbus RTU, XMODEM och diverse inbyggda/industriella kommunikationsstandarder.
Det är viktigt att förstå vad en CRC inte är: den är inte en kryptografisk hash. CRC:er är snabba, linjära funktioner utan motstånd mot avsiktlig manipulation — det är enkelt att konstruera ett annat meddelande som ger samma CRC-värde. De är utmärkta på att fånga slumpmässiga bitfel orsakade av störda överföringslinjer, diskfel eller avbrutna nedladdningar, men de ger inget skydd mot en angripare som vill manipulera data utan att det upptäcks.
Varför använda det?
- Du felsöker en Modbus RTU-drivrutin på bitnivå och slavenheten avvisar ständigt dina ramar — klistra in exakt bytesekvensen här med CRC-16/MODBUS valt för att kolla om din firmwares CRC-rutin matchar referensvärdet innan du felsöker något annat.
- Du har precis skrivit en CRC-32-tabellgenereringsrutin i C eller Rust från grunden och vill sanitetskontrollera den — kör standardtestvektorn "123456789" genom verktyget och bekräfta att du får 0xCBF43926 innan du litar på din implementation med riktig data.
- Ett ZIP-extraheringsverktyg kastar ett CRC-mismatchfel på en post och du är osäker på om arkivet faktiskt är korrupt — räkna om CRC-32 för de extraherade bytesen här och jämför med värdet som lagras i ZIP-filens lokala header.
- Du implementerar XMODEM eller ett liknande serieprotokoll och specifikationen säger bara "lägg till CRC-16" utan vidare förklaring — beräkna den här först så du vet hur de korrekta avslutande bytesen ska se ut innan du börjar felsöka din sändningskod.
- Du har ärvt ett inbyggt system-projekt med ett odokumenterat kontrollsummefält och misstänker att det är CRC-16/CCITT-FALSE snarare än CRC-16/MODBUS — prova båda varianterna mot en känd nyttolast och se vilken som matchar värdet enheten faktiskt skickar.
- 100% lokalt: din text eller fil bearbetas helt i JavaScript i din webbläsare, så inget laddas upp någonstans.
Så använder du det
- Välj fliken "Text" och klistra in eller skriv din indata, eller byt till fliken "Fil" och välj en fil från din enhet.
- Välj CRC-algoritm: CRC-32 (IEEE 802.3, standard och vanligast), CRC-16/CCITT-FALSE, eller CRC-16/MODBUS.
- Kontrollsumman uppdateras automatiskt, visad i hexadecimal, decimal och binär form.
- Klicka på "Kopiera" bredvid valfritt resultat för att kopiera det till urklipp.
Exempel
Inmatning
123456789Resultat
0xCBF43926 (3421780262)Det här är den standardiserade publicerade CRC-32-testvektorn (IEEE 802.3): CRC-32 för ASCII-strängen "123456789" är alltid 0xCBF43926. Du kan jämföra verktygets utdata mot vilken annan korrekt CRC-32-implementation som helst med exakt den här strängen.
CRC jämfört med kryptografiska hashar (MD5 / SHA)
Både CRC:er och kryptografiska hashar reducerar data till ett fast fingeravtryck, men de löser olika problem och är inte utbytbara.
| Egenskap | CRC (t.ex. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Syfte | Upptäcka oavsiktlig korruption | Upptäcka avsiktlig manipulation / verifiera integritet |
| Hastighet | Extremt snabb, enkel hårdvara/mjukvara | Långsammare, mer beräkning per byte |
| Kollisionsresistens | Ingen — trivialt att konstruera avsiktligt | Designad att vara beräkningsmässigt ogenomförbar (SHA-256) eller trasig för MD5 |
| Typisk storlek | 16 eller 32 bitar | 128 bitar (MD5) eller 256 bitar (SHA-256) |
| Vanlig användning | ZIP/gzip, PNG, Ethernet, Modbus, lagring | Filintegritetskontroller, digitala signaturer, lösenordslagring (med salt) |
De tre CRC-varianterna i korthet
Varje variant definieras av sitt polynom, startvärde, om in-/utdatabitar speglas, och den avslutande XOR:en — får du någon av dessa fel beräknar du en tekniskt giltig men inkompatibel kontrollsumma.
| Variant | Polynom | Startvärde | Speglad | Avslutande XOR | Vanlig användning |
|---|---|---|---|---|---|
| CRC-32 (IEEE 802.3) | 0xEDB88320 | 0xFFFFFFFF | Ja (in & ut) | 0xFFFFFFFF | ZIP, gzip, PNG, Ethernet |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | Nej | 0x0000 | XMODEM, telekomprotokoll |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | Ja (in & ut) | 0x0000 | Modbus RTU-serieramar |
Fler verktyg
Om du behöver en kryptografisk kontrollsumma istället för en felupptäckande CRC, är de här verktygen ett bättre val.
→ Multi-Algorithm Hash Generator · MD5 Generator · HMAC Generator
Vanliga frågor
Vad används en CRC till?
En CRC (cyklisk redundanskontroll) är en felupptäckande kod som läggs till ett datablock så att mottagaren kan räkna om den och bekräfta att datan inte oavsiktligt korrumperats under lagring eller överföring. Den finns inbyggd i standarder som IEEE 802.3 Ethernet-ramning, ZIP- och gzip-filformaten, PNG-bilder, och många serie- och industriprotokoll som Modbus.
Är CRC-32 samma sak som MD5 eller SHA-256?
Nej. CRC-32 är en snabb, linjär felupptäckande kontrollsumma utan säkerhetsegenskaper — det är trivialt att avsiktligt konstruera två olika indata med samma CRC-32-värde. MD5 och SHA-256 är kryptografiska hashfunktioner designade för att göra den typen av avsiktlig kollision beräkningsmässigt ogenomförbar. Använd CRC-32 för att fånga oavsiktlig korruption (en repad disk, ett tappat nätverkspaket); använd en kryptografisk hash från vår Hash Generator eller MD5 Generator när du behöver manipuleringssäkerhet eller integritetsgaranti mot en angripare.
Vilken CRC-32-variant använder verktyget?
IEEE 802.3/ZIP/PNG-varianten: polynom 0xEDB88320 (den bitspeglade formen av 0x04C11DB7), startvärde 0xFFFFFFFF, speglad indata och utdata, och en avslutande XOR med 0xFFFFFFFF. Det är varianten som används av Ethernet, ZIP, gzip och PNG, och den som ger 0xCBF43926 för ASCII-strängen "123456789" — den standardiserade publicerade testvektorn för att verifiera en CRC-32-implementation.
Vad är skillnaden mellan CRC-16/CCITT-FALSE och CRC-16/MODBUS?
Båda är 16-bitars CRC:er men med olika polynom och parametrar. CRC-16/CCITT-FALSE använder polynom 0x1021 med startvärde 0xFFFF och ingen bitspegling; den är vanlig i protokoll som XMODEM och diverse telekomstandarder. CRC-16/MODBUS använder polynom 0x8005 (speglat som 0xA001), också med startvärde 0xFFFF, men med speglad indata och utdata — det är kontrollsumman Modbus RTU lägger till varje serieram. De ger olika resultat för samma indata, så det är viktigt att välja varianten ditt målprotokoll faktiskt specificerar.
Kan jag beräkna CRC för en fil, inte bara text?
Ja. Byt till fliken "Fil" och välj en fil från din enhet — verktyget läser dess råa bytes lokalt i webbläsaren (via File API) och beräknar kontrollsumman över exakt de bytesen, på samma sätt som en ZIP- eller PNG-läsare skulle göra.
Skickas min data till en server?
Nej. Både text- och filberäkningen körs helt klientsidan i JavaScript med en standardiserad tabellbaserad CRC-algoritm. Inget du skriver eller laddar upp lämnar någonsin din webbläsare.
Varför ger min egenskrivna CRC-32-implementation ett annat resultat än det här verktyget?
Den vanligaste orsaken är felmatchat startvärde, avslutande XOR eller bitspeglingsinställning — CRC-32 är inte en enda fast algoritm, det är en familj av parametrar, och IEEE 802.3/ZIP/PNG-varianten som verktyget använder startar på 0xFFFFFFFF, speglar både indata och utdata, och XOR:ar slutresultatet med 0xFFFFFFFF. Att hoppa över något av dessa steg ger en annan, lika "giltig" men inkompatibel kontrollsumma. Testa din implementation mot vektorn "123456789" → 0xCBF43926 för att isolera vilket steg som är fel.
Finns det en storleksgräns för filuppladdning?
Det finns ingen konstgjord gräns i verktyget, men mycket stora filer kan vara långsamma eftersom CRC:n beräknas byte för byte i JavaScript i din webbläsare. För typiska firmware-avbildningar, ZIP-poster eller protokollramar — från några bytes upp till tiotals megabyte — är prestandan i praktiken omedelbar.
Påverkar mellanslag eller radslutsstil CRC:n för inklistrad text?
Ja — en CRC beräknas över de exakta bytesen i din indata, så en avslutande radbrytning, ett extra mellanslag, eller Windows-stil CRLF jämfört med Unix-stil LF radslut ger alla olika kontrollsummor även om den synliga texten ser identisk ut. Om du matchar en kontrollsumma från ett annat verktyg, klistra in exakt det verktyget hashade, inklusive eventuella avslutande blanktecken, eller använd hellre fliken Fil för att jämföra råa bytes direkt.
Kan två helt olika filer ha samma CRC-32-värde?
Ja, och det är förväntat, inte en bugg — CRC-32 har bara 2^32 möjliga utdata, så kollisioner är matematiskt garanterade att finnas för tillräckligt stora datamängder, och de är också triviala att konstruera avsiktligt eftersom CRC-32 saknar kryptografisk kollisionsresistens. Det är exakt varför CRC-32 fungerar bra för att fånga oavsiktlig korruption men är olämplig för att verifiera att en fil inte manipulerats.
Vilken CRC-variant ska jag använda om protokolldokumentationen inte specificerar parametrar?
Börja med varianten mest associerad med den protokollfamiljen: CRC-16/MODBUS för Modbus RTU-seriekommunikation, CRC-16/CCITT-FALSE för XMODEM och många telekomhärledda protokoll, och CRC-32 (IEEE 802.3-varianten) för allt ZIP-, gzip-, PNG- eller Ethernet-relaterat. Om ingen matchar en känt korrekt ram från den riktiga enheten kan protokollet använda ett icke-standardpolynom eller parameteruppsättning utanför vad verktyget täcker.