CodeKitHubCông Cụ Này Là Gì?
CRC là viết tắt của Cyclic Redundancy Check (kiểm tra dư thừa theo chu kỳ), một mã phát hiện lỗi được mô tả lần đầu trong bài báo năm 1975 của W. Wesley Peterson và D.T. Brown, và sau đó được chuẩn hóa trong các tài liệu tham khảo như "A Painless Guide to CRC Error Detection Algorithms" của Ross Williams và các tiêu chuẩn ITU-T / ISO 3309. CRC coi một thông điệp như một số nhị phân lớn và chia nó cho một đa thức sinh cố định; phần dư của phép chia đó chính là checksum. Vì phép chia đa thức rẻ khi tính toán cả trên phần cứng lẫn phần mềm, CRC đã trở thành phương pháp kiểm tra lỗi mặc định cho các hệ thống lưu trữ và truyền dữ liệu.
CRC-32 — cụ thể là biến thể với đa thức 0xEDB88320, giá trị khởi tạo 0xFFFFFFFF và phép XOR cuối 0xFFFFFFFF — được chuẩn hóa trong IEEE 802.3 (Ethernet) và được dùng làm checksum bên trong các tệp lưu trữ ZIP và gzip, tệp ảnh PNG, cùng vô số giao thức mạng và lưu trữ khác. Đây là biến thể CRC được yêu cầu nhiều nhất, đó là lý do nó là thuật toán mặc định trong công cụ này. CRC-16/CCITT-FALSE (đa thức 0x1021) và CRC-16/MODBUS (đa thức 0x8005, đảo bit) là hai biến thể 16-bit được sử dụng rộng rãi, xuất hiện trong các giao thức nối tiếp như Modbus RTU, XMODEM, và nhiều tiêu chuẩn giao tiếp nhúng/công nghiệp khác.
Điều quan trọng cần hiểu là CRC không phải là gì: nó không phải là một hàm băm mật mã học. CRC là các hàm tuyến tính nhanh, không có khả năng chống lại việc thao túng có chủ đích — việc tạo ra một thông điệp khác cho cùng giá trị CRC là điều đơn giản. Chúng rất tốt trong việc phát hiện các lỗi lật bit ngẫu nhiên do đường truyền nhiễu, lỗi đĩa, hoặc tải xuống bị cắt ngắn gây ra, nhưng chúng không cung cấp bất kỳ sự bảo vệ nào chống lại kẻ tấn công muốn giả mạo dữ liệu mà không bị phát hiện.
Tại Sao Nên Dùng?
- Bạn đang debug module RTU Modbus cho hệ thống giám sát điện trong nhà máy, và khung dữ liệu PLC gửi đi bị thiết bị nhận từ chối vì lỗi checksum — nhập payload của khung vào đây với CRC-16/MODBUS để kiểm tra xem giá trị bạn tính tay có khớp chuẩn không.
- Bạn phát triển firmware cho thiết bị IoT nội địa giao tiếp qua XMODEM, và kết quả CRC-16/CCITT-FALSE từ code C của bạn khác với thư viện tham chiếu — dán cùng đầu vào vào đây để tách lỗi nằm ở giá trị khởi tạo hay ở thứ tự đảo bit.
- Bạn tải file ZIP dung lượng lớn qua mạng công ty hay bị ngắt kết nối và nghi ngờ file bị hỏng trước khi giải nén lên server production — kiểm tra CRC-32 của file ở đây rồi so sánh với checksum đồng nghiệp gửi qua Slack.
- Bạn viết trình phân tích tệp PNG tùy chỉnh và một chunk cứ liên tục báo lỗi xác thực CRC — tính lại CRC-32 từ byte thô của chunk đó ở đây để xác nhận lỗi nằm ở code parsing của bạn, không phải ở file gốc.
- Bạn làm bài thi chứng chỉ mạng hoặc bài tập môn truyền thông dữ liệu yêu cầu tính CRC thủ công bằng phép chia đa thức — dùng công cụ này để đối chiếu đáp án trước khi nộp, vì tính tay rất dễ sai ở bước XOR.
- Đội bạn đang chuyển từ checksum tự chế nội bộ sang chuẩn CRC-32 IEEE 802.3 cho giao thức giao tiếp giữa các microservice — dán vài mẫu payload vào đây để tạo giá trị tham chiếu dùng làm căn cứ cho unit test ở cả hai phía.
Cách Sử Dụng
- Chọn tab "Text" và dán hoặc gõ nội dung đầu vào của bạn, hoặc chuyển sang tab "File" và chọn một tệp từ thiết bị của bạn.
- Chọn thuật toán CRC: CRC-32 (IEEE 802.3, mặc định và phổ biến nhất), CRC-16/CCITT-FALSE, hoặc CRC-16/MODBUS.
- Checksum sẽ tự động cập nhật, hiển thị ở dạng thập lục phân (hex), thập phân và nhị phân.
- Nhấp "Copy" bên cạnh bất kỳ kết quả nào để sao chép vào clipboard của bạn.
Ví dụ
Đầu vào
123456789Đầu ra
0xCBF43926 (3421780262)Đây là vector kiểm thử CRC-32 (IEEE 802.3) chuẩn đã được công bố: giá trị CRC-32 của chuỗi ASCII "123456789" luôn luôn là 0xCBF43926. Bạn có thể đối chiếu kết quả của công cụ này với bất kỳ triển khai CRC-32 chính xác nào khác bằng chuỗi này.
CRC so với các hàm băm mật mã học (MD5 / SHA)
Cả CRC và hàm băm mật mã học đều rút gọn dữ liệu thành một dấu vân tay có kích thước cố định, nhưng chúng giải quyết các vấn đề khác nhau và không thể thay thế cho nhau.
| Đặc điểm | CRC (ví dụ: CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Mục đích | Phát hiện lỗi hỏng ngẫu nhiên | Phát hiện giả mạo có chủ đích / xác minh tính toàn vẹn |
| Tốc độ | Cực nhanh, phần cứng/phần mềm đơn giản | Chậm hơn, tính toán nhiều hơn trên mỗi byte |
| Khả năng chống va chạm | Không có — dễ dàng tạo va chạm có chủ đích | Được thiết kế để không khả thi về mặt tính toán (SHA-256) hoặc đã bị phá vỡ đối với MD5 |
| Kích thước điển hình | 16 hoặc 32 bit | 128 bit (MD5) hoặc 256 bit (SHA-256) |
| Ứng dụng phổ biến | ZIP/gzip, PNG, Ethernet, Modbus, lưu trữ | Kiểm tra toàn vẹn tệp, chữ ký số, lưu trữ mật khẩu (kèm salting) |
Công cụ liên quan
Nếu bạn cần một checksum mật mã học thay vì một CRC phát hiện lỗi, các công cụ sau sẽ phù hợp hơn.
→ Công cụ tạo Hash đa thuật toán · Công cụ tạo MD5 · Công cụ tạo HMAC
Debug những lỗi CRC thường gặp nhất
Lỗi phổ biến nhất khi tự triển khai CRC không nằm ở công thức chia đa thức, mà ở ba tham số phụ thường bị bỏ qua: giá trị khởi tạo của thanh ghi (init value), việc bit đầu vào/đầu ra có cần đảo hay không (reflected in/out), và giá trị XOR áp dụng ở cuối phép tính. Hai cách triển khai có thể dùng đúng cùng một đa thức nhưng vẫn cho checksum khác nhau nếu một trong ba tham số này không khớp.
Nếu bạn đang tự xây dựng CRC bằng C, Python, hay ngôn ngữ khác, cách nhanh nhất xác nhận đúng sai là dùng vector kiểm thử chuẩn: chuỗi ASCII "123456789" luôn phải cho ra 0xCBF43926 với CRC-32 IEEE 802.3. Nếu kết quả triển khai của bạn khác giá trị đó, gần như chắc chắn vấn đề nằm ở một trong ba tham số ẩn kể trên, không phải ở logic chia đa thức.
Với giao thức nối tiếp như Modbus RTU, thứ tự byte checksum gửi trong khung dữ liệu cũng là nguồn lỗi thường gặp — CRC-16/MODBUS được gửi theo thứ tự byte thấp trước rồi byte cao (little-endian), khác với thói quen viết hex thường là big-endian. Nếu khung dữ liệu của bạn cứ bị từ chối dù giá trị CRC đã đúng, hãy kiểm tra lại thứ tự byte khi gửi.
Câu Hỏi Thường Gặp
CRC được dùng để làm gì?
CRC (cyclic redundancy check) là một mã phát hiện lỗi được gắn vào một khối dữ liệu để bên nhận có thể tính lại và xác nhận dữ liệu không bị hỏng ngẫu nhiên trong quá trình lưu trữ hoặc truyền tải. Nó được tích hợp vào các tiêu chuẩn như khung truyền Ethernet IEEE 802.3, định dạng tệp ZIP và gzip, ảnh PNG, và nhiều giao thức nối tiếp cũng như công nghiệp như Modbus.
CRC-32 có giống MD5 hoặc SHA-256 không?
Không. CRC-32 là một checksum phát hiện lỗi nhanh, tuyến tính, không có tính chất bảo mật nào — việc cố ý tạo ra hai đầu vào khác nhau có cùng giá trị CRC-32 là điều tầm thường. MD5 và SHA-256 là các hàm băm mật mã học được thiết kế để khiến kiểu va chạm có chủ đích đó trở nên không khả thi về mặt tính toán. Hãy dùng CRC-32 để phát hiện lỗi hỏng ngẫu nhiên (đĩa bị xước, gói tin mạng bị rớt); hãy dùng một hàm băm mật mã học từ [Hash Generator](/hash-generator) hoặc [MD5 Generator](/md5-generator) của chúng tôi khi bạn cần bằng chứng chống giả mạo hoặc đảm bảo toàn vẹn trước kẻ tấn công.
Công cụ này dùng biến thể CRC-32 nào?
Biến thể IEEE 802.3 / ZIP / PNG: đa thức 0xEDB88320 (dạng đảo bit của 0x04C11DB7), giá trị khởi tạo 0xFFFFFFFF, đầu vào và đầu ra đều được đảo bit, và phép XOR cuối là 0xFFFFFFFF. Đây là biến thể được dùng bởi Ethernet, ZIP, gzip và PNG, và cũng là biến thể tạo ra 0xCBF43926 cho chuỗi ASCII "123456789" — vector kiểm thử chuẩn đã công bố để xác minh một triển khai CRC-32.
Sự khác biệt giữa CRC-16/CCITT-FALSE và CRC-16/MODBUS là gì?
Cả hai đều là CRC 16-bit nhưng với đa thức và tham số khác nhau. CRC-16/CCITT-FALSE dùng đa thức 0x1021 với giá trị khởi tạo 0xFFFF và không đảo bit; nó phổ biến trong các giao thức như XMODEM và nhiều tiêu chuẩn viễn thông khác. CRC-16/MODBUS dùng đa thức 0x8005 (đảo bit thành 0xA001), cũng với giá trị khởi tạo 0xFFFF, nhưng đầu vào và đầu ra đều được đảo bit — đây là checksum mà Modbus RTU gắn vào cuối mỗi khung nối tiếp. Chúng sẽ cho ra kết quả khác nhau với cùng một đầu vào, vì vậy điều quan trọng là chọn đúng biến thể mà giao thức mục tiêu của bạn thực sự quy định.
Tôi có thể tính CRC của một tệp, không chỉ văn bản không?
Có. Chuyển sang tab "File" và chọn một tệp từ thiết bị của bạn — công cụ sẽ đọc các byte thô của tệp cục bộ trong trình duyệt (thông qua File API) và tính checksum trên chính xác những byte đó, giống như cách một trình đọc ZIP hoặc PNG sẽ làm.
Dữ liệu của tôi có được tải lên máy chủ không?
Không. Cả việc tính toán trên văn bản lẫn tệp đều chạy hoàn toàn phía trình duyệt (client-side) bằng JavaScript, sử dụng thuật toán CRC dựa trên bảng tra cứu tiêu chuẩn. Không có gì bạn gõ hoặc tải lên rời khỏi trình duyệt của bạn.
Tại sao kết quả CRC của tôi khác dù tôi chắc chắn đầu vào và đa thức giống nhau?
Nguyên nhân phổ biến nhất là các tham số ẩn thường bị bỏ quên: giá trị khởi tạo (init value), việc bit đầu vào/đầu ra có được đảo hay không, và giá trị XOR áp dụng ở cuối. Hai cách triển khai có thể dùng cùng một đa thức nhưng vẫn cho checksum khác nhau nếu một trong các tham số này không khớp — hãy kiểm tra từng cái một, đừng chỉ dừng lại ở đa thức.
CRC có thể dùng để xác minh mật khẩu hoặc dữ liệu nhạy cảm như hàm băm mật mã học không?
Hoàn toàn không nên. CRC được thiết kế để phát hiện lỗi hỏng ngẫu nhiên, không phải để chống lại tấn công có chủ đích — ai cũng có thể dễ dàng tạo ra đầu vào khác nhau cho cùng giá trị CRC. Với mật khẩu hoặc dữ liệu cần đảm bảo an toàn, hãy dùng hàm băm mật mã học như SHA-256, không phải CRC-32 hay CRC-16.
CRC-32 trong công cụ này có giống hàm crc32() trong PHP hay zlib.crc32() trong Python không?
Có — công cụ này dùng biến thể IEEE 802.3 / ZIP chuẩn với đa thức 0xEDB88320, hoàn toàn giống với hàm crc32() có sẵn trong PHP, zlib.crc32() trong Python, và hàm CRC32 trong thư viện zlib của C. Bạn có thể đối chiếu kết quả trực tiếp để kiểm chứng chéo.
Tại sao kết quả CRC-16/MODBUS và CRC-16/CCITT-FALSE khác nhau dù cùng là 16-bit và đầu vào giống hệt nhau?
Cả hai đều là 16-bit nhưng dùng đa thức và cấu hình đảo bit hoàn toàn khác nhau — MODBUS dùng đa thức 0x8005 với bit đầu vào và đầu ra đều được đảo, còn CCITT-FALSE dùng đa thức 0x1021 không đảo bit chút nào. Đây là lý do quan trọng khi chọn đúng biến thể phù hợp với đặc tả giao thức mục tiêu, thay vì chọn bừa "CRC-16" chung chung.