CodeKitHubHvad er dette værktøj?
CRC står for Cyclic Redundancy Check, en fejldetekterende kode først beskrevet i 1975-artiklen af W. Wesley Peterson og D.T. Brown, og senere formaliseret i referencer som Ross Williams' "A Painless Guide to CRC Error Detection Algorithms" og ITU-T/ISO 3309-standarderne. En CRC behandler en besked som et stort binært tal og dividerer det med et fast generatorpolynomium; resten af den division er tjeksummen. Fordi polynomiedivision er billig at beregne i både hardware og software, blev CRC'er standarden for fejlkontrol i lagrings- og transmissionssystemer.
CRC-32 — specifikt varianten med polynomium 0xEDB88320, en startværdi på 0xFFFFFFFF og en afsluttende XOR med 0xFFFFFFFF — er standardiseret i IEEE 802.3 (Ethernet) og bruges som tjeksummen inde i ZIP- og gzip-arkiver, PNG-billedfiler og utallige netværks- og lagringsprotokoller. Det er langt den mest efterspurgte CRC-variant, hvilket er grunden til, at den er standardalgoritmen i dette værktøj. CRC-16/CCITT-FALSE (polynomium 0x1021) og CRC-16/MODBUS (polynomium 0x8005, spejlet) er to udbredte 16-bit varianter, der findes i seriel-protokoller som Modbus RTU, XMODEM og diverse indlejrede/industrielle kommunikationsstandarder.
Det er vigtigt at forstå, hvad en CRC ikke er: det er ikke en kryptografisk hash. CRC'er er hurtige, lineære funktioner uden modstandsdygtighed over for bevidst manipulation — det er ligetil at konstruere en anden besked, der giver samme CRC-værdi. De er fremragende til at fange den slags tilfældige bitfejl, der skyldes støjfyldte transmissionslinjer, diskfejl eller afbrudte downloads, men de giver nul beskyttelse mod en modstander, der ønsker at manipulere data uden at blive opdaget.
Hvorfor bruge det?
- Du fejlfinder en Modbus RTU-driver på bit-niveau, og slave-enheden bliver ved med at afvise dine frames — indsæt den præcise byte-sekvens her med CRC-16/MODBUS valgt for at tjekke, om din firmwares CRC-rutine matcher referenceværdien, før du fejlfinder noget andet.
- Du har lige skrevet en CRC-32-tabelgenereringsrutine i C eller Rust fra bunden og vil sundhedstjekke den — kør standard-"123456789"-testvektoren gennem dette værktøj, og bekræft at du får 0xCBF43926, før du stoler på implementeringen med rigtige data.
- Et ZIP-udpakningsværktøj kaster en CRC-uoverensstemmelsesfejl på en post, og du er ikke sikker på, om arkivet rent faktisk er korrupt — genberegn CRC-32 for de udpakkede bytes her, og sammenlign den med værdien gemt i ZIP-filens lokale header.
- Du implementerer XMODEM eller en lignende seriel protokol, og specifikationen siger bare "tilføj CRC-16" uden yderligere forklaring — beregn den her først, så du ved, hvordan de korrekte afsluttende bytes bør se ud, før du begynder at fejlfinde din sende-kode.
- Du har arvet et indlejret projekt med et udokumenteret tjeksumfelt og har mistanke om, at det er CRC-16/CCITT-FALSE frem for CRC-16/MODBUS — prøv begge varianter mod en kendt payload, og se hvilken der matcher den værdi, enheden faktisk sender.
- 100% lokalt: din tekst eller fil behandles udelukkende i JavaScript i din browser, så intet uploades nogen steder.
Sådan bruger du det
- Vælg fanen "Tekst" og indsæt eller skriv din inputtekst, eller skift til fanen "Fil" og vælg en fil fra din enhed.
- Vælg CRC-algoritmen: CRC-32 (IEEE 802.3, standarden og mest almindelige), CRC-16/CCITT-FALSE, eller CRC-16/MODBUS.
- Tjeksummen opdateres automatisk og vises i hexadecimal, decimal og binær form.
- Klik på "Kopiér" ud for et resultat for at kopiere det til udklipsholderen.
Eksempel
Input
123456789Output
0xCBF43926 (3421780262)Dette er den standardiserede, offentliggjorte CRC-32-testvektor (IEEE 802.3): CRC-32 for ASCII-strengen "123456789" er altid 0xCBF43926. Du kan tjekke dette værktøjs output mod enhver anden korrekt CRC-32-implementering med præcis denne streng.
CRC vs. kryptografiske hashes (MD5 / SHA)
Både CRC'er og kryptografiske hashes reducerer data til et fast fingeraftryk, men de løser forskellige problemer og er ikke ombyttelige.
| Egenskab | CRC (fx CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Formål | Opdage utilsigtet korruption | Opdage bevidst manipulation / verificere integritet |
| Hastighed | Ekstremt hurtig, simpel hardware/software | Langsommere, mere beregning per byte |
| Kollisionsmodstand | Ingen — trivielt at konstruere bevidst | Designet til at være beregningsmæssigt umuligt (SHA-256) eller brudt for MD5 |
| Typisk størrelse | 16 eller 32 bit | 128 bit (MD5) eller 256 bit (SHA-256) |
| Almindelig brug | ZIP/gzip, PNG, Ethernet, Modbus, lagring | Filintegritetstjek, digitale signaturer, adgangskodelagring (med salt) |
De tre CRC-varianter i korte træk
Hver variant defineres af sit polynomium, startværdi, om input-/output-bits spejles, og den afsluttende XOR — får du bare ét af disse forkert, beregner du en teknisk gyldig, men inkompatibel tjeksum.
| Variant | Polynomium | Startværdi | Spejlet | Afsluttende XOR | Almindelig brug |
|---|---|---|---|---|---|
| CRC-32 (IEEE 802.3) | 0xEDB88320 | 0xFFFFFFFF | Ja (ind & ud) | 0xFFFFFFFF | ZIP, gzip, PNG, Ethernet |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | Nej | 0x0000 | XMODEM, telekom-protokoller |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | Ja (ind & ud) | 0x0000 | Modbus RTU seriel-frames |
Flere værktøjer
Hvis du har brug for en kryptografisk tjeksum i stedet for en fejldetekterende CRC, er disse værktøjer et bedre valg.
→ Multi-Algorithm Hash Generator · MD5 Generator · HMAC Generator
Ofte stillede spørgsmål
Hvad bruges en CRC til?
En CRC (cyklisk redundanskontrol) er en fejldetekterende kode, der tilføjes en datablok, så modtageren kan genberegne den og bekræfte, at dataen ikke er blevet utilsigtet korrumperet under lagring eller transmission. Den er indbygget i standarder som IEEE 802.3 Ethernet-framing, ZIP- og gzip-filformaterne, PNG-billeder og mange serielle og industrielle protokoller som Modbus.
Er CRC-32 det samme som MD5 eller SHA-256?
Nej. CRC-32 er en hurtig, lineær fejldetekterende tjeksum uden sikkerhedsegenskaber — det er trivielt bevidst at konstruere to forskellige input med samme CRC-32-værdi. MD5 og SHA-256 er kryptografiske hashfunktioner designet til at gøre den slags bevidste kollisioner beregningsmæssigt umulige. Brug CRC-32 til at fange utilsigtet korruption (en ridset disk, en tabt netværkspakke); brug en kryptografisk hash fra vores Hash Generator eller MD5 Generator, når du har brug for manipulationssikring eller integritetsgarantier mod en modstander.
Hvilken CRC-32-variant bruger dette værktøj?
IEEE 802.3/ZIP/PNG-varianten: polynomium 0xEDB88320 (den bit-spejlede form af 0x04C11DB7), startværdi 0xFFFFFFFF, spejlet input og output, og en afsluttende XOR med 0xFFFFFFFF. Dette er varianten brugt af Ethernet, ZIP, gzip og PNG, og den, der giver 0xCBF43926 for ASCII-strengen "123456789" — den standardiserede, offentliggjorte testvektor til verificering af en CRC-32-implementering.
Hvad er forskellen mellem CRC-16/CCITT-FALSE og CRC-16/MODBUS?
Begge er 16-bit CRC'er men med forskellige polynomier og parametre. CRC-16/CCITT-FALSE bruger polynomium 0x1021 med en startværdi på 0xFFFF og ingen bit-spejling; den er almindelig i protokoller som XMODEM og diverse telekom-standarder. CRC-16/MODBUS bruger polynomium 0x8005 (spejlet som 0xA001), også med startværdi 0xFFFF, men med spejlet input og output — det er den tjeksum, Modbus RTU tilføjer til hver seriel frame. De giver forskellige resultater for samme input, så det er vigtigt at vælge den variant, din målprotokol faktisk specificerer.
Kan jeg beregne CRC for en fil, ikke kun tekst?
Ja. Skift til fanen "Fil" og vælg en fil fra din enhed — værktøjet læser dens rå bytes lokalt i browseren (via File API) og beregner tjeksummen over præcis de bytes, på samme måde som en ZIP- eller PNG-læser ville gøre.
Bliver mine data uploadet til en server?
Nej. Både tekst- og filberegningen kører udelukkende klient-side i JavaScript med en standardiseret tabelbaseret CRC-algoritme. Intet du skriver eller uploader forlader nogensinde din browser.
Hvorfor giver min egen CRC-32-implementering et andet resultat end dette værktøj?
Den mest almindelige årsag er en fejlmatchet startværdi, afsluttende XOR eller bit-spejlingsindstilling — CRC-32 er ikke én fast algoritme, det er en familie af parametre, og IEEE 802.3/ZIP/PNG-varianten, som dette værktøj bruger, starter ved 0xFFFFFFFF, spejler både input og output, og XOR'er slutresultatet med 0xFFFFFFFF. At springe et af disse trin over giver en anden, lige så "gyldig" men inkompatibel tjeksum. Test din implementering mod vektoren "123456789" → 0xCBF43926 for at isolere, hvilket trin der er galt.
Er der en størrelsesgrænse for filupload?
Der er ingen kunstig grænse håndhævet af værktøjet, men meget store filer kan være langsomme, da CRC'en beregnes byte for byte i JavaScript i din browser. For typiske firmware-images, ZIP-poster eller protokol-frames — fra få bytes op til flere titals megabytes — er ydelsen i praksis øjeblikkelig.
Påvirker mellemrum eller linjeafslutningsstil CRC'en for indsat tekst?
Ja — en CRC beregnes over de præcise bytes i dit input, så et afsluttende linjeskift, et ekstra mellemrum, eller Windows-stil CRLF versus Unix-stil LF linjeafslutninger vil alle give forskellige tjeksummer, selv om den synlige tekst ser identisk ud. Hvis du matcher en tjeksum fra et andet værktøj, indsæt præcis det, værktøjet hashede, inklusive eventuelle afsluttende mellemrum, eller brug hellere fanen Fil til at sammenligne rå bytes direkte.
Kan to helt forskellige filer have samme CRC-32-værdi?
Ja, og det er forventet, ikke en fejl — CRC-32 har kun 2^32 mulige output, så kollisioner er matematisk garanteret at eksistere for tilstrækkeligt store datasæt, og de er også trivielle at konstruere bevidst, da CRC-32 ikke har kryptografisk kollisionsmodstand. Det er præcis derfor, CRC-32 er fint til at fange utilsigtet korruption, men uegnet til at verificere, at en fil ikke er blevet manipuleret.
Hvilken CRC-variant skal jeg bruge, hvis protokoldokumentationen ikke specificerer parametre?
Start med den variant, der oftest associeres med den protokolfamilie: CRC-16/MODBUS til Modbus RTU seriel kommunikation, CRC-16/CCITT-FALSE til XMODEM og mange telekom-afledte protokoller, og CRC-32 (IEEE 802.3-varianten) til alt ZIP-, gzip-, PNG- eller Ethernet-relateret. Hvis ingen matcher en kendt korrekt frame fra den rigtige enhed, bruger protokollen måske et ikke-standard polynomium eller parametersæt uden for det, dette værktøj dækker.