CodeKitHubMi ez az eszköz?
A CRC a Cyclic Redundancy Check rövidítése, egy hibadetektáló kód, amelyet először W. Wesley Peterson és D.T. Brown 1975-ös cikke írt le, később pedig olyan hivatkozások formalizáltak, mint Ross Williams „A Painless Guide to CRC Error Detection Algorithms” című írása és az ITU-T / ISO 3309 szabványok. A CRC az üzenetet nagy bináris számként kezeli, és elosztja egy fix generátorpolinommal; ennek az osztásnak a maradéka az ellenőrzőösszeg. Mivel a polinomosztás hardveresen és szoftveresen is olcsón kiszámítható, a CRC lett a tárolási és átviteli rendszerek alapértelmezett hibaellenőrzése.
A CRC-32 — pontosabban a 0xEDB88320 polinomú, 0xFFFFFFFF kezdőértékű és 0xFFFFFFFF záró XOR-ú változat — az IEEE 802.3 (Ethernet) szabványban van szabványosítva, és a ZIP és gzip archívumok, PNG képfájlok, valamint számtalan hálózati és tárolási protokoll belső ellenőrzőösszegeként szolgál. Ez messze a leggyakrabban keresett CRC-változat, ezért ez az alapértelmezett algoritmus ebben az eszközben. A CRC-16/CCITT-FALSE (0x1021 polinom) és a CRC-16/MODBUS (0x8005 polinom, tükrözve) két széles körben használt 16 bites változat, amelyek soros protokollokban találhatók, mint a Modbus RTU, XMODEM és különféle beágyazott/ipari kommunikációs szabványok.
Fontos megérteni, mi NEM a CRC: nem kriptográfiai hash. A CRC gyors, lineáris függvény, semmilyen ellenállással a szándékos manipulációval szemben — egyszerű olyan másik üzenetet szerkeszteni, amely ugyanazt a CRC-értéket adja. Kiválóan szűrik ki a zajos átviteli vonalak, lemezhibák vagy megszakadt letöltések okozta véletlen bitfordulásokat, de nulla védelmet nyújtanak egy olyan támadóval szemben, aki észrevétlenül akarja módosítani az adatot.
Miért érdemes használni?
- Modbus RTU driver-t hibakeresel, és a szolga eszköz folyamatosan visszautasítja a kereteidet — illeszd be ide a pontos bájtsorozatot CRC-16/MODBUS kiválasztásával, hogy ellenőrizd, egyezik-e a firmware CRC-rutinja a referenciaértékkel, mielőtt bármi mást debuggolnál.
- Most írtál egy CRC-32 táblagenerátor rutint nulláról C-ben vagy Rustban, és ellenőrizni akarod — futtasd át ezen az eszközön a szabvány „123456789” tesztvektort, és győződj meg róla, hogy 0xCBF43926-ot kapsz, mielőtt megbíznál benne éles adatokon.
- Egy ZIP-kicsomagoló eszköz CRC-eltérési hibát dob az egyik bejegyzésnél, és nem vagy biztos benne, hogy az archívum tényleg sérült-e — számítsd ki itt újra a kicsomagolt bájtok CRC-32-jét, és hasonlítsd össze a ZIP helyi fájlfejlécében tárolt értékkel.
- XMODEM-et vagy hasonló soros protokollt implementálsz, és a specifikáció csak annyit mond, hogy „csatold a CRC-16-ot” — számítsd ki itt előbb, hogy tudd, milyennek kell lenniük a helyes záró bájtoknak, mielőtt az adóoldali kódot debuggolni kezdenéd.
- Egy dokumentálatlan ellenőrzőösszeg-mezővel rendelkező beágyazott projektet örököltél, és gyanítod, hogy CRC-16/CCITT-FALSE, nem CRC-16/MODBUS — próbáld ki mindkét változatot egy ismert payloadon, és nézd meg, melyik egyezik az eszköz által ténylegesen küldött értékkel.
- 100%-ban helyi: a szöveged vagy fájlod teljes egészében JavaScriptben, a böngésződben kerül feldolgozásra, tehát semmi sem kerül feltöltésre.
Használati útmutató
- Válaszd a „Szöveg” fület, és illeszd be vagy írd be a bemenetet, vagy válts a „Fájl” fülre és válassz fájlt az eszközödről.
- Válaszd ki a CRC algoritmust: CRC-32 (IEEE 802.3, alapértelmezett és leggyakoribb), CRC-16/CCITT-FALSE vagy CRC-16/MODBUS.
- Az ellenőrzőösszeg automatikusan frissül, hexadecimális, decimális és bináris formában is megjelenítve.
- Kattints a „Másolás” gombra bármely eredmény mellett, hogy vágólapra másold.
Példa
Bemenet
123456789Kimenet
0xCBF43926 (3421780262)Ez a szabványos, publikált CRC-32 (IEEE 802.3) tesztvektor: a „123456789” ASCII string CRC-32-je mindig 0xCBF43926. Ezzel a pontos stringgel ellenőrizheted ennek az eszköznek a kimenetét bármely másik helyes CRC-32 implementációval szemben.
CRC vs. kriptográfiai hash-ek (MD5 / SHA)
Mind a CRC, mind a kriptográfiai hash-ek fix méretű lenyomatra redukálják az adatot, de eltérő problémákat oldanak meg, és nem felcserélhetők.
| Tulajdonság | CRC (pl. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Cél | Véletlen sérülés kiszűrése | Szándékos manipuláció kiszűrése / integritás ellenőrzése |
| Sebesség | Rendkívül gyors, egyszerű hardver/szoftver | Lassabb, több számítás bájtonként |
| Ütközésellenállás | Nincs — szándékosan triviálisan létrehozható | Számításilag kivitelezhetetlennek tervezve (SHA-256) vagy feltörve (MD5) |
| Jellemző méret | 16 vagy 32 bit | 128 bit (MD5) vagy 256 bit (SHA-256) |
| Gyakori felhasználás | ZIP/gzip, PNG, Ethernet, Modbus, tárolás | Fájlintegritás-ellenőrzés, digitális aláírás, jelszótárolás (sózással) |
A három CRC-változat egy pillantásra
Minden változatot a polinomja, kezdőértéke, a be- és kimeneti bitek tükrözöttsége, valamint a záró XOR határoz meg — ha bármelyiket elrontod, technikailag érvényes, de inkompatibilis ellenőrzőösszeget kapsz.
| Változat | Polinom | Kezdőérték | Tükrözött | Záró XOR | Gyakori felhasználás |
|---|---|---|---|---|---|
| CRC-32 (IEEE 802.3) | 0xEDB88320 | 0xFFFFFFFF | Igen (be és ki) | 0xFFFFFFFF | ZIP, gzip, PNG, Ethernet |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | Nem | 0x0000 | XMODEM, telekommunikációs protokollok |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | Igen (be és ki) | 0x0000 | Modbus RTU soros keretek |
Kapcsolódó eszközök
Ha hibaellenőrző CRC helyett kriptográfiai ellenőrzőösszegre van szükséged, ezek az eszközök jobban illenek.
→ Többalgoritmusos hash generátor · MD5 generátor · HMAC generátor
Gyakori kérdések
Mire használják a CRC-t?
A CRC (ciklikus redundanciaellenőrzés) egy adatblokkhoz csatolt hibadetektáló kód, amelyet a fogadó fél újraszámol, hogy megerősítse: az adat nem sérült meg véletlenül tárolás vagy átvitel közben. Beépítve szerepel olyan szabványokban, mint az IEEE 802.3 Ethernet keretezés, a ZIP és gzip fájlformátumok, PNG képek, valamint számos soros és ipari protokoll, például a Modbus.
A CRC-32 ugyanaz, mint az MD5 vagy az SHA-256?
Nem. A CRC-32 egy gyors, lineáris, biztonsági tulajdonságok nélküli hibaellenőrző ellenőrzőösszeg — triviális szándékosan két különböző bemenetet szerkeszteni ugyanazzal a CRC-32 értékkel. Az MD5 és az SHA-256 kriptográfiai hash-függvények, amelyeket úgy terveztek, hogy egy ilyen szándékos ütközés számításilag kivitelezhetetlen legyen. A CRC-32-t véletlen sérülés kiszűrésére használd (karcos lemez, elveszett hálózati csomag); kriptográfiai hash-t a Hash generátorunkból vagy MD5 generátorunkból használj, ha manipuláció elleni bizonyítékra vagy integritási garanciára van szükséged egy támadóval szemben.
Melyik CRC-32 változatot használja ez az eszköz?
Az IEEE 802.3 / ZIP / PNG változatot: 0xEDB88320 polinom (a 0x04C11DB7 bitre tükrözött formája), 0xFFFFFFFF kezdőérték, tükrözött bemenet és kimenet, valamint 0xFFFFFFFF záró XOR. Ez az a változat, amelyet az Ethernet, ZIP, gzip és PNG használ, és amely 0xCBF43926-ot ad a „123456789” ASCII stringre — ez a szabványos publikált tesztvektor egy CRC-32 implementáció ellenőrzéséhez.
Mi a különbség a CRC-16/CCITT-FALSE és a CRC-16/MODBUS között?
Mindkettő 16 bites CRC, de eltérő polinommal és paraméterekkel. A CRC-16/CCITT-FALSE a 0x1021 polinomot használja 0xFFFF kezdőértékkel, bittükrözés nélkül; olyan protokollokban gyakori, mint az XMODEM és különféle telekommunikációs szabványok. A CRC-16/MODBUS a 0x8005 polinomot használja (0xA001-ként tükrözve), szintén 0xFFFF kezdőértékkel, de tükrözött bemenettel és kimenettel — ez az az ellenőrzőösszeg, amelyet a Modbus RTU minden soros kerethez csatol. Ugyanazon bemenetre eltérő eredményt adnak, ezért fontos azt a változatot választani, amelyet a célprotokollod ténylegesen előír.
Kiszámolhatom egy fájl CRC-jét, nem csak szövegét?
Igen. Válts a „Fájl” fülre, és válassz fájlt az eszközödről — az eszköz helyben, a böngészőben olvassa be a nyers bájtokat (a File API-n keresztül), és pontosan ezekből a bájtokból számítja ki az ellenőrzőösszeget, ugyanúgy, ahogy egy ZIP- vagy PNG-olvasó tenné.
Az adataim szerverre kerülnek?
Nem. Mind a szöveg, mind a fájl feldolgozása teljes egészében kliensoldalon, JavaScriptben zajlik, egy szabványos táblázat-alapú CRC algoritmussal. Semmi, amit beírsz vagy feltöltesz, nem hagyja el a böngésződet.
Miért ad a saját CRC-32 implementációm eltérő eredményt, mint ez az eszköz?
A leggyakoribb ok az eltérő kezdőérték, záró XOR vagy bittükrözési beállítás — a CRC-32 nem egyetlen fix algoritmus, hanem egy paramétercsalád, és az eszköz által használt IEEE 802.3/ZIP/PNG változat 0xFFFFFFFF-ről indul, tükrözi a bemenetet és a kimenetet is, és XOR-olja a végeredményt 0xFFFFFFFF-fel. Ha bármelyik lépést kihagyod, egy másik, technikailag „érvényes”, de inkompatibilis ellenőrzőösszeget kapsz. Teszteld az implementációdat a „123456789” → 0xCBF43926 vektorral, hogy beazonosítsd, melyik lépés hiányzik.
Van fájlméret-korlát a feltöltésnél?
Az eszköz nem érvényesít mesterséges korlátot, de nagyon nagy fájloknál lassabb lehet, mivel a CRC bájtonként kerül kiszámításra JavaScriptben a böngésződben. Tipikus firmware-image-eknél, ZIP-bejegyzéseknél vagy protokollkereteknél — néhány bájttól több tíz megabájtig — a teljesítmény gyakorlatilag azonnali.
Befolyásolja a szóköz vagy a sorvég stílusa a beillesztett szöveg CRC-jét?
Igen — a CRC a bemenet pontos bájtjaiból számolódik, így egy záró új sor, egy elveszett szóköz vagy a Windows-stílusú CRLF a Unix-stílusú LF sorvéggel szemben mind eltérő ellenőrzőösszeget ad, még ha a látható szöveg azonosnak is tűnik. Ha egy másik eszközből származó ellenőrzőösszeget próbálsz egyeztetni, illeszd be pontosan azt, amit az az eszköz hashelt, beleértve a záró szóközöket is, vagy inkább használd a Fájl fület a nyers bájtok közvetlen összehasonlításához.
Lehet két teljesen különböző fájlnak ugyanaz a CRC-32 értéke?
Igen, és ez elvárt, nem hiba — a CRC-32-nek csak 2^32 lehetséges kimenete van, így elég nagy adathalmaznál matematikailag garantáltan léteznek ütközések, és szándékosan is triviálisan létrehozhatók, mivel a CRC-32-nek nincs kriptográfiai ütközésellenállása. Pontosan ezért alkalmas a CRC-32 a véletlen sérülés kiszűrésére, de alkalmatlan annak ellenőrzésére, hogy egy fájlt nem manipuláltak-e.
Melyik CRC-változatot használjam, ha a protokolldokumentáció nem adja meg a paramétereket?
Kezdd azzal a változattal, amely leginkább az adott protokollcsaládhoz köthető: CRC-16/MODBUS a Modbus RTU soros kommunikációhoz, CRC-16/CCITT-FALSE az XMODEM-hez és sok telekommunikációs eredetű protokollhoz, valamint CRC-32 (IEEE 802.3 változat) mindenhez, ami ZIP-, gzip-, PNG- vagy Ethernet-jellegű. Ha egyik sem egyezik egy valódi eszközről származó, ismerten helyes kerettel, a protokoll valószínűleg nem szabványos polinomot vagy paraméterkészletet használ, ami kívül esik ezen az eszközön.