CodeKitHubCzym jest to narzędzie?
CRC to skrót od Cyclic Redundancy Check (cykliczna kontrola nadmiarowa) — kod wykrywający błędy, opisany po raz pierwszy w pracy W. Wesleya Petersona i D.T. Browna z 1975 roku, a później sformalizowany w takich źródłach jak "A Painless Guide to CRC Error Detection Algorithms" Rossa Williamsa oraz w standardach ITU-T / ISO 3309. CRC traktuje wiadomość jako dużą liczbę binarną i dzieli ją przez ustalony wielomian generujący; reszta z tego dzielenia stanowi sumę kontrolną. Ponieważ dzielenie wielomianowe jest tanie w implementacji zarówno sprzętowej, jak i programowej, CRC stało się domyślnym mechanizmem kontroli błędów w systemach przechowywania i transmisji danych.
CRC-32 — a konkretnie wariant z wielomianem 0xEDB88320, wartością początkową 0xFFFFFFFF i końcowym XOR-em 0xFFFFFFFF — jest znormalizowany w IEEE 802.3 (Ethernet) i stosowany jako suma kontrolna w archiwach ZIP i gzip, plikach obrazów PNG oraz niezliczonych protokołach sieciowych i pamięci masowej. Jest to zdecydowanie najczęściej wykorzystywany wariant CRC, dlatego jest domyślnym algorytmem w tym narzędziu. CRC-16/CCITT-FALSE (wielomian 0x1021) i CRC-16/MODBUS (wielomian 0x8005, odbity) to dwa powszechnie stosowane warianty 16-bitowe, spotykane w protokołach szeregowych takich jak Modbus RTU, XMODEM oraz różnych standardach komunikacji przemysłowej i wbudowanej.
Ważne jest zrozumienie, czym CRC nie jest: to nie jest funkcja skrótu kryptograficznego. CRC to szybkie, liniowe funkcje, które nie stawiają żadnego oporu celowej manipulacji — bardzo łatwo skonstruować inną wiadomość dającą tę samą wartość CRC. Doskonale wykrywają one przypadkowe przekłamania bitów spowodowane zaszumioną transmisją, błędami dysku czy przerwanym pobieraniem, ale nie zapewniają żadnej ochrony przed napastnikiem, który chce niezauważenie zmienić dane.
Dlaczego warto go używać?
- Piszesz ręcznie sterownik Modbus RTU, a urządzenie slave wciąż odrzuca Twoje ramki — wklej tutaj dokładną sekwencję bajtów z wybranym CRC-16/MODBUS, żeby sprawdzić, czy procedura CRC w Twoim firmwarze zgadza się z wartością referencyjną, zanim zaczniesz debugować cokolwiek innego.
- Właśnie napisałeś od zera procedurę generowania tablicy CRC-32 w C lub Ruście i chcesz szybko ją zweryfikować — przepuść przez to narzędzie standardowy wektor testowy "123456789" i potwierdź, że otrzymujesz 0xCBF43926, zanim zaufasz swojej implementacji na prawdziwych danych.
- Narzędzie do rozpakowywania ZIP zgłasza błąd niezgodności CRC dla jednego wpisu i nie masz pewności, czy archiwum jest faktycznie uszkodzone — przelicz tutaj CRC-32 wypakowanych bajtów i porównaj z wartością zapisaną w lokalnym nagłówku pliku ZIP.
- Implementujesz XMODEM lub podobny protokół szeregowy, a specyfikacja mówi tylko "dołącz CRC-16" bez dalszych szczegółów — oblicz go najpierw tutaj, żeby wiedzieć, jak powinny wyglądać poprawne bajty końcowe, zanim zaczniesz debugować kod nadawczy.
- Odziedziczyłeś projekt embedded z nieudokumentowanym polem sumy kontrolnej i podejrzewasz, że to CRC-16/CCITT-FALSE, a nie CRC-16/MODBUS — wypróbuj obie warianty na znanym payloadzie i sprawdź, która pasuje do wartości faktycznie wysyłanej przez urządzenie.
- 100% lokalnie: Twój tekst lub plik jest przetwarzany całkowicie w JavaScript w przeglądarce, więc nic nigdzie nie jest wysyłane.
Jak używać
- Wybierz zakładkę „Tekst” i wklej lub wpisz dane wejściowe, albo przełącz się na zakładkę „Plik” i wybierz plik ze swojego urządzenia.
- Wybierz algorytm CRC: CRC-32 (IEEE 802.3, domyślny i najpopularniejszy), CRC-16/CCITT-FALSE lub CRC-16/MODBUS.
- Suma kontrolna aktualizuje się automatycznie, wyświetlana w formacie szesnastkowym, dziesiętnym i binarnym.
- Kliknij „Kopiuj” obok dowolnego wyniku, aby skopiować go do schowka.
Przykład
Wejście
123456789Wynik
0xCBF43926 (3421780262)To standardowy, publikowany wektor testowy CRC-32 (IEEE 802.3): CRC-32 ciągu ASCII "123456789" zawsze wynosi 0xCBF43926. Możesz porównać wynik tego narzędzia z dowolną inną poprawną implementacją CRC-32, używając dokładnie tego ciągu.
CRC a skróty kryptograficzne (MD5 / SHA)
Zarówno CRC, jak i skróty kryptograficzne redukują dane do odcisku o stałej długości, ale rozwiązują różne problemy i nie są wymienne.
| Właściwość | CRC (np. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Cel | Wykrywanie przypadkowego uszkodzenia | Wykrywanie celowej ingerencji / weryfikacja integralności |
| Szybkość | Bardzo szybkie, proste w sprzęcie i oprogramowaniu | Wolniejsze, więcej obliczeń na bajt |
| Odporność na kolizje | Brak — trywialne do celowego wywołania | Zaprojektowane jako obliczeniowo niewykonalne (SHA-256) lub złamane w przypadku MD5 |
| Typowy rozmiar | 16 lub 32 bity | 128 bitów (MD5) lub 256 bitów (SHA-256) |
| Typowe zastosowania | ZIP/gzip, PNG, Ethernet, Modbus, pamięć masowa | Kontrola integralności plików, podpisy cyfrowe, przechowywanie haseł (z solą) |
Powiązane narzędzia
Jeśli potrzebujesz sumy kryptograficznej zamiast CRC wykrywającego błędy, te narzędzia będą lepszym wyborem.
→ Wielofunkcyjny generator skrótów · Generator MD5 · Generator HMAC
Trzy warianty CRC w skrócie
Każdy wariant jest zdefiniowany przez swój wielomian, wartość początkową, to, czy bity wejścia/wyjścia są odbite, oraz końcowy XOR — pomylenie choćby jednego z tych parametrów daje technicznie poprawną, ale niekompatybilną sumę kontrolną.
| Wariant | Wielomian | Wartość początkowa | Odbicie | Końcowy XOR | Typowe zastosowanie |
|---|---|---|---|---|---|
| CRC-32 (IEEE 802.3) | 0xEDB88320 | 0xFFFFFFFF | Tak (wej. i wyj.) | 0xFFFFFFFF | ZIP, gzip, PNG, Ethernet |
| CRC-16/CCITT-FALSE | 0x1021 | 0xFFFF | Nie | 0x0000 | XMODEM, protokoły telekomunikacyjne |
| CRC-16/MODBUS | 0x8005 | 0xFFFF | Tak (wej. i wyj.) | 0x0000 | Ramki szeregowe Modbus RTU |
Najczęściej zadawane pytania
Do czego służy CRC?
CRC (cykliczna kontrola nadmiarowa) to kod wykrywania błędów dołączany do bloku danych, dzięki czemu odbiorca może obliczyć go ponownie i potwierdzić, że dane nie zostały przypadkowo uszkodzone podczas przechowywania lub transmisji. Jest wbudowany w standardy takie jak ramki Ethernet IEEE 802.3, formaty plików ZIP i gzip, obrazy PNG oraz wiele protokołów szeregowych i przemysłowych, takich jak Modbus.
Czy CRC-32 to to samo co MD5 lub SHA-256?
Nie. CRC-32 to szybka, liniowa suma kontrolna wykrywająca błędy, pozbawiona jakichkolwiek właściwości kryptograficznych — celowe skonstruowanie dwóch różnych danych wejściowych o tej samej wartości CRC-32 jest trywialne. MD5 i SHA-256 to kryptograficzne funkcje skrótu zaprojektowane tak, by taka celowa kolizja była obliczeniowo niewykonalna. Używaj CRC-32 do wykrywania przypadkowych uszkodzeń (zarysowany dysk, zgubiony pakiet sieciowy); użyj skrótu kryptograficznego z naszego [Generatora skrótów](/hash-generator) lub [Generatora MD5](/md5-generator), gdy potrzebujesz dowodu integralności lub ochrony przed celową ingerencją.
Którego wariantu CRC-32 używa to narzędzie?
Wariantu IEEE 802.3 / ZIP / PNG: wielomian 0xEDB88320 (bitowo odbita postać 0x04C11DB7), wartość początkowa 0xFFFFFFFF, odbicie danych wejściowych i wyjściowych oraz końcowy XOR z 0xFFFFFFFF. To wariant stosowany w Ethernecie, ZIP, gzip i PNG, który dla ciągu ASCII "123456789" zwraca 0xCBF43926 — standardowy, publikowany wektor testowy do weryfikacji implementacji CRC-32.
Jaka jest różnica między CRC-16/CCITT-FALSE a CRC-16/MODBUS?
Oba to 16-bitowe CRC, ale z różnymi wielomianami i parametrami. CRC-16/CCITT-FALSE używa wielomianu 0x1021 z wartością początkową 0xFFFF i bez odbicia bitów; jest powszechny w protokołach takich jak XMODEM i różnych standardach telekomunikacyjnych. CRC-16/MODBUS używa wielomianu 0x8005 (odbitego jako 0xA001), również z wartością początkową 0xFFFF, ale z odbiciem danych wejściowych i wyjściowych — to suma kontrolna dołączana przez Modbus RTU do każdej ramki szeregowej. Dla tych samych danych wejściowych dają różne wyniki, dlatego ważne jest, by wybrać wariant zgodny z tym, co określa docelowy protokół.
Czy mogę obliczyć CRC pliku, a nie tylko tekstu?
Tak. Przełącz się na zakładkę „Plik” i wybierz plik ze swojego urządzenia — narzędzie odczytuje jego surowe bajty lokalnie w przeglądarce (za pomocą File API) i oblicza sumę kontrolną dokładnie z tych bajtów, tak samo jak zrobiłby to czytnik ZIP lub PNG.
Czy moje dane są wysyłane na serwer?
Nie. Obliczenia zarówno dla tekstu, jak i pliku odbywają się całkowicie po stronie klienta, w JavaScript, z użyciem standardowego, tablicowego algorytmu CRC. Nic z tego, co wpiszesz lub prześlesz, nigdy nie opuszcza Twojej przeglądarki.
Dlaczego moja własna implementacja CRC-32 daje inny wynik niż to narzędzie?
Najczęstszą przyczyną jest niezgodna wartość początkowa, końcowy XOR lub ustawienie odbicia bitów — CRC-32 to nie jeden ustalony algorytm, tylko rodzina parametrów, a wariant IEEE 802.3/ZIP/PNG używany przez to narzędzie zaczyna od 0xFFFFFFFF, odbija zarówno wejście, jak i wyjście, i wykonuje XOR wyniku końcowego z 0xFFFFFFFF. Pominięcie któregokolwiek z tych kroków daje inną, technicznie poprawną, ale niekompatybilną sumę kontrolną. Przetestuj swoją implementację na wektorze "123456789" → 0xCBF43926, żeby ustalić, który krok jest niezgodny.
Czy jest limit rozmiaru dla przesyłanego pliku?
Narzędzie nie narzuca sztucznego limitu, ale bardzo duże pliki mogą działać wolniej, ponieważ CRC jest obliczane bajt po bajcie w JavaScript w przeglądarce. Dla typowych obrazów firmware'u, wpisów ZIP czy ramek protokołów — od kilku bajtów po dziesiątki megabajtów — wydajność jest praktycznie natychmiastowa.
Czy białe znaki lub styl końca linii wpływają na CRC wklejonego tekstu?
Tak — CRC jest obliczane na dokładnych bajtach wejścia, więc końcowy znak nowej linii, przypadkowa spacja albo zakończenia linii w stylu Windows (CRLF) w porównaniu z Unix (LF) dadzą różne sumy kontrolne, nawet jeśli widoczny tekst wygląda identycznie. Jeśli dopasowujesz sumę kontrolną z innego narzędzia, wklej dokładnie to, co ono haszowało, łącznie z końcowymi białymi znakami, albo lepiej użyj zakładki Plik, żeby porównać surowe bajty bezpośrednio.
Czy dwa zupełnie różne pliki mogą mieć tę samą wartość CRC-32?
Tak, i to jest oczekiwane, a nie błąd — CRC-32 ma tylko 2^32 możliwych wyników, więc kolizje są matematycznie gwarantowane przy wystarczająco dużych zbiorach danych, a do tego są też trywialne do celowego skonstruowania, ponieważ CRC-32 nie ma kryptograficznej odporności na kolizje. Właśnie dlatego CRC-32 nadaje się do wykrywania przypadkowych uszkodzeń, ale nie do weryfikacji, czy plik nie został zmodyfikowany.
Którego wariantu CRC użyć, jeśli dokumentacja protokołu nie podaje parametrów?
Zacznij od wariantu najbardziej kojarzonego z daną rodziną protokołów: CRC-16/MODBUS dla komunikacji szeregowej Modbus RTU, CRC-16/CCITT-FALSE dla XMODEM i wielu protokołów wywodzących się z telekomunikacji, a CRC-32 (wariant IEEE 802.3) dla wszystkiego związanego z ZIP, gzip, PNG czy Ethernetem. Jeśli żaden z nich nie pasuje do znanej, poprawnej ramki z realnego urządzenia, protokół może używać niestandardowego wielomianu lub zestawu parametrów wykraczającego poza to, co obsługuje to narzędzie.