CodeKitHubApa Itu Alat Ini?
CRC adalah singkatan dari Cyclic Redundancy Check, sebuah kode deteksi kesalahan yang pertama kali dijelaskan dalam makalah tahun 1975 oleh W. Wesley Peterson dan D.T. Brown, dan kemudian diformalkan dalam referensi seperti "A Painless Guide to CRC Error Detection Algorithms" oleh Ross Williams serta standar ITU-T / ISO 3309. CRC memperlakukan sebuah pesan sebagai bilangan biner besar dan membaginya dengan polinomial generator tetap; sisa dari pembagian itulah checksum-nya. Karena pembagian polinomial murah untuk dihitung baik di perangkat keras maupun perangkat lunak, CRC menjadi metode pengecekan kesalahan standar untuk sistem penyimpanan dan transmisi data.
CRC-32 — khususnya varian dengan polinomial 0xEDB88320, nilai awal 0xFFFFFFFF, dan XOR akhir 0xFFFFFFFF — distandarkan dalam IEEE 802.3 (Ethernet) dan digunakan sebagai checksum di dalam arsip ZIP dan gzip, file gambar PNG, serta banyak protokol jaringan dan penyimpanan lainnya. Ini adalah varian CRC yang paling sering diminta, itulah sebabnya menjadi algoritma bawaan pada alat ini. CRC-16/CCITT-FALSE (polinomial 0x1021) dan CRC-16/MODBUS (polinomial 0x8005, direfleksikan) adalah dua varian 16-bit yang banyak digunakan pada protokol serial seperti Modbus RTU, XMODEM, dan berbagai standar komunikasi tertanam/industri.
Penting untuk memahami apa yang bukan merupakan CRC: CRC bukan hash kriptografis. CRC adalah fungsi linear yang cepat dan tidak memiliki ketahanan terhadap manipulasi yang disengaja — sangat mudah untuk membuat pesan berbeda yang menghasilkan nilai CRC yang sama. CRC sangat baik dalam menangkap jenis kesalahan bit acak yang disebabkan oleh jalur transmisi yang bising, kerusakan disk, atau unduhan yang terpotong, tetapi tidak memberikan perlindungan sama sekali terhadap pihak yang sengaja ingin mengubah data tanpa terdeteksi.
Mengapa Menggunakannya?
- Kamu sedang debug modul RTU Modbus buat sistem monitoring listrik di pabrik dan frame yang dikirim PLC ditolak alat penerima dengan error checksum — masukkan payload frame di sini dengan CRC-16/MODBUS untuk cek apakah nilai yang kamu hitung manual sudah sesuai standar.
- Kamu develop firmware buat perangkat IoT lokal yang komunikasi lewat XMODEM dan hasil CRC-16/CCITT-FALSE dari kode C kamu beda sama yang diharapkan library referensi — tempel input yang sama di sini untuk isolasi apakah bug-nya di inisialisasi nilai awal atau di urutan bit refleksi.
- Kamu download file ZIP besar dari server kantor lewat koneksi kantor yang suka putus-putus dan curiga filenya corrupt sebelum diekstrak ke server produksi — cek CRC-32 file itu di sini dan bandingkan dengan checksum yang dikirim tim lain lewat Slack.
- Kamu lagi bikin parser custom buat baca file PNG dan salah satu chunk terus-terusan gagal validasi CRC — hitung ulang CRC-32 dari byte mentah chunk tersebut di sini untuk pastikan masalahnya ada di parsing kamu, bukan di file aslinya.
- Kamu ngerjain soal ujian sertifikasi jaringan atau tugas kuliah sistem komunikasi data yang minta hitung CRC manual dengan pembagian polinomial — pakai alat ini untuk verifikasi jawaban sebelum dikumpulkan, karena hitung manual gampang salah di step XOR.
- Tim kamu lagi transisi dari checksum custom internal ke standar CRC-32 IEEE 802.3 buat protokol komunikasi antar-microservice — tempel beberapa sample payload di sini untuk generate nilai referensi yang jadi acuan test unit di kedua sisi.
Cara Menggunakan
- Pilih tab "Text" lalu tempel atau ketik input Anda, atau beralih ke tab "File" dan pilih file dari perangkat Anda.
- Pilih algoritma CRC: CRC-32 (IEEE 802.3, default dan paling umum), CRC-16/CCITT-FALSE, atau CRC-16/MODBUS.
- Checksum akan diperbarui secara otomatis, ditampilkan dalam heksadesimal, desimal, dan biner.
- Klik "Copy" di sebelah hasil mana pun untuk menyalinnya ke clipboard Anda.
Contoh
Input
123456789Output
0xCBF43926 (3421780262)Ini adalah vektor uji CRC-32 (IEEE 802.3) standar yang telah dipublikasikan: CRC-32 dari string ASCII "123456789" selalu 0xCBF43926. Anda dapat memeriksa hasil dari alat ini terhadap implementasi CRC-32 lain yang benar menggunakan string yang persis sama ini.
CRC vs. hash kriptografis (MD5 / SHA)
Baik CRC maupun hash kriptografis mereduksi data menjadi sidik jari berukuran tetap, tetapi keduanya menyelesaikan masalah yang berbeda dan tidak dapat saling menggantikan.
| Properti | CRC (mis. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Tujuan | Mendeteksi kerusakan yang tidak disengaja | Mendeteksi manipulasi yang disengaja / memverifikasi integritas |
| Kecepatan | Sangat cepat, perangkat keras/lunak sederhana | Lebih lambat, komputasi lebih besar per byte |
| Ketahanan terhadap tabrakan | Tidak ada — mudah direkayasa dengan sengaja | Dirancang agar secara komputasi tidak layak (SHA-256) atau sudah dipatahkan untuk MD5 |
| Ukuran umum | 16 atau 32 bit | 128 bit (MD5) atau 256 bit (SHA-256) |
| Penggunaan umum | ZIP/gzip, PNG, Ethernet, Modbus, penyimpanan | Pemeriksaan integritas file, tanda tangan digital, penyimpanan kata sandi (dengan salting) |
Alat terkait
Jika Anda memerlukan checksum kriptografis alih-alih CRC deteksi kesalahan, alat-alat berikut lebih sesuai.
→ Multi-Algorithm Hash Generator · MD5 Generator · HMAC Generator
Debugging kesalahan CRC yang paling sering terjadi
Kesalahan paling umum saat mengimplementasikan CRC sendiri bukan pada rumus pembagian polinomialnya, melainkan pada tiga parameter tambahan yang sering diabaikan: nilai awal register (init value), apakah bit input dan output perlu direfleksikan (reflected in/out), dan nilai XOR yang diterapkan di akhir perhitungan. Dua implementasi bisa memakai polinomial yang benar-benar sama tapi tetap menghasilkan checksum berbeda kalau salah satu dari tiga parameter ini tidak cocok.
Kalau kamu sedang membangun implementasi CRC sendiri di C, Python, atau bahasa lain, cara tercepat mengonfirmasi kebenarannya adalah dengan vektor uji standar: string ASCII "123456789" harus selalu menghasilkan 0xCBF43926 untuk CRC-32 IEEE 802.3. Kalau hasil implementasimu berbeda dari nilai itu, masalahnya hampir pasti ada di salah satu dari tiga parameter tersembunyi tadi, bukan di logika pembagian polinomialnya.
Untuk protokol serial seperti Modbus RTU, urutan byte checksum yang dikirim di frame juga sering jadi sumber bug — CRC-16/MODBUS dikirim dalam urutan low-byte dulu baru high-byte (little-endian), berbeda dari kebiasaan menulis heksadesimal yang biasanya big-endian. Kalau frame kamu ditolak terus padahal nilai CRC sudah benar, cek dulu urutan byte pengirimannya.
Pertanyaan yang Sering Diajukan
Untuk apa CRC digunakan?
CRC (cyclic redundancy check) adalah kode deteksi kesalahan yang ditambahkan pada sebuah blok data sehingga penerima dapat menghitungnya ulang dan memastikan data tidak rusak secara tidak sengaja selama penyimpanan atau transmisi. CRC tertanam dalam standar seperti framing Ethernet IEEE 802.3, format file ZIP dan gzip, gambar PNG, serta banyak protokol serial dan industri seperti Modbus.
Apakah CRC-32 sama dengan MD5 atau SHA-256?
Tidak. CRC-32 adalah checksum deteksi kesalahan yang cepat dan linear, tanpa properti keamanan — sangat mudah membuat dua input berbeda dengan nilai CRC-32 yang sama secara sengaja. MD5 dan SHA-256 adalah fungsi hash kriptografis yang dirancang agar jenis tabrakan (collision) yang disengaja seperti itu secara komputasi tidak layak dilakukan. Gunakan CRC-32 untuk menangkap kerusakan yang tidak disengaja (disk yang tergores, paket jaringan yang hilang); gunakan hash kriptografis dari [Hash Generator](/hash-generator) atau [MD5 Generator](/md5-generator) kami saat Anda membutuhkan bukti manipulasi atau jaminan integritas terhadap pihak yang berniat jahat.
Varian CRC-32 mana yang digunakan alat ini?
Varian IEEE 802.3 / ZIP / PNG: polinomial 0xEDB88320 (bentuk refleksi bit dari 0x04C11DB7), nilai awal 0xFFFFFFFF, input dan output direfleksikan, serta XOR akhir 0xFFFFFFFF. Ini adalah varian yang digunakan oleh Ethernet, ZIP, gzip, dan PNG, dan yang menghasilkan 0xCBF43926 untuk string ASCII "123456789" — vektor uji standar yang dipublikasikan untuk memverifikasi implementasi CRC-32.
Apa perbedaan antara CRC-16/CCITT-FALSE dan CRC-16/MODBUS?
Keduanya adalah CRC 16-bit tetapi dengan polinomial dan parameter yang berbeda. CRC-16/CCITT-FALSE menggunakan polinomial 0x1021 dengan nilai awal 0xFFFF dan tanpa refleksi bit; umum digunakan pada protokol seperti XMODEM dan berbagai standar telekomunikasi. CRC-16/MODBUS menggunakan polinomial 0x8005 (direfleksikan menjadi 0xA001), juga dengan nilai awal 0xFFFF, tetapi dengan input dan output direfleksikan — inilah checksum yang ditambahkan Modbus RTU pada setiap frame serial. Keduanya akan menghasilkan hasil yang berbeda untuk input yang sama, sehingga penting untuk memilih varian yang sesuai dengan protokol target Anda.
Bisakah saya menghitung CRC dari sebuah file, bukan hanya teks?
Bisa. Beralih ke tab "File" dan pilih file dari perangkat Anda — alat ini membaca byte mentahnya secara lokal di browser (melalui File API) dan menghitung checksum tepat dari byte-byte tersebut, sama seperti yang dilakukan pembaca ZIP atau PNG.
Apakah data saya diunggah ke server?
Tidak. Baik perhitungan teks maupun file berjalan sepenuhnya di sisi klien menggunakan JavaScript dengan algoritma CRC berbasis tabel yang standar. Tidak ada yang Anda ketik atau unggah yang pernah meninggalkan browser Anda.
Kenapa hasil CRC saya beda padahal saya yakin input dan polinomialnya sama?
Penyebab paling umum adalah parameter tersembunyi yang sering terlupakan: nilai awal (init value), apakah bit input dan output direfleksikan, serta XOR akhir. Dua implementasi bisa memakai polinomial yang identik tapi tetap menghasilkan checksum berbeda kalau salah satu parameter ini tidak cocok — periksa satu per satu, bukan cuma polinomialnya saja.
Bisakah CRC dipakai untuk verifikasi password atau data sensitif seperti hash kriptografis?
Tidak disarankan sama sekali. CRC dirancang untuk mendeteksi kerusakan acak, bukan untuk menahan serangan yang disengaja — siapa pun bisa dengan mudah membuat input berbeda yang menghasilkan CRC sama. Untuk password atau data yang butuh jaminan keamanan, pakai fungsi hash kriptografis seperti SHA-256, bukan CRC-32 atau CRC-16.
Apakah CRC-32 di alat ini sama dengan yang dipakai fungsi crc32() di PHP atau zlib.crc32() di Python?
Ya — alat ini memakai varian IEEE 802.3 / ZIP standar dengan polinomial 0xEDB88320, yang sama persis dengan implementasi crc32() bawaan PHP, zlib.crc32() Python, dan fungsi CRC32 di zlib C library. Kamu bisa langsung membandingkan hasilnya satu-satu untuk validasi silang.
Kenapa hasil CRC-16/MODBUS dan CRC-16/CCITT-FALSE beda meskipun sama-sama 16-bit dan input-nya identik?
Keduanya memang sama-sama 16-bit tapi memakai polinomial dan konfigurasi refleksi bit yang berbeda total — MODBUS memakai polinomial 0x8005 dengan bit input dan output direfleksikan, sementara CCITT-FALSE memakai polinomial 0x1021 tanpa refleksi sama sekali. Ini kenapa penting memilih varian yang persis sesuai spesifikasi protokol yang kamu targetkan, bukan asal pilih "CRC-16" generik.