CodeKitHubЧто это за инструмент?
CRC расшифровывается как Cyclic Redundancy Check (циклический избыточный код) — код обнаружения ошибок, впервые описанный в статье 1975 года У. Уэсли Питерсона и Д. Т. Брауна, а позднее формализованный в таких источниках, как «A Painless Guide to CRC Error Detection Algorithms» Росса Уильямса и стандартах ITU-T / ISO 3309. CRC рассматривает сообщение как большое двоичное число и делит его на фиксированный образующий полином; остаток этого деления и есть контрольная сумма. Поскольку деление полиномов дёшево вычислять как аппаратно, так и программно, CRC стал стандартной проверкой ошибок в системах хранения и передачи данных.
CRC-32 — а именно вариант с полиномом 0xEDB88320, начальным значением 0xFFFFFFFF и финальным XOR 0xFFFFFFFF — стандартизирован в IEEE 802.3 (Ethernet) и используется как контрольная сумма в архивах ZIP и gzip, файлах изображений PNG и множестве сетевых и протоколов хранения данных. Это самый часто запрашиваемый вариант CRC, поэтому он выбран алгоритмом по умолчанию в этом инструменте. CRC-16/CCITT-FALSE (полином 0x1021) и CRC-16/MODBUS (полином 0x8005, отражённый) — два широко используемых 16-битных варианта, применяемых в последовательных протоколах вроде Modbus RTU, XMODEM и различных встраиваемых/промышленных стандартах связи.
Важно понимать, чем CRC не является: это не криптографическая хеш-функция. CRC — быстрые линейные функции, не устойчивые к преднамеренным манипуляциям: несложно построить другое сообщение с тем же значением CRC. Они отлично справляются со случайными сбоями битов, вызванными шумом на линии передачи, ошибками диска или обрывом загрузки, но не дают никакой защиты от злоумышленника, желающего незаметно подменить данные.
Зачем его использовать?
- Вы пишете прошивку для встраиваемого устройства и не уверены, что ваша самописная функция CRC-32 работает правильно, поэтому хотите сверить результат со стандартным тестовым вектором «123456789».
- Разрабатываете последовательное устройство, которое общается с ПЛК по Modbus RTU, и значение CRC-16/MODBUS в кадре не совпадает с ожидаемым по спецификации, из-за чего отладка застряла.
- Вручную восстановили запись из повреждённого ZIP-архива и хотите проверить, действительно ли восстановленные байты корректны, пересчитав CRC-32 из содержимого и сравнив со значением в заголовке.
- Получили отчёт о повреждённом PNG-изображении, извлекли байты подозрительного чанка и хотите сравнить записанный CRC с пересчитанным значением, чтобы локализовать причину.
- Переписываете парсер внутреннего протокола связи и хотите проверить свою реализацию CRC-16/CCITT-FALSE для XMODEM независимым инструментом перед выкаткой в продакшен.
- Данные, которые вы отлаживаете, — ещё не выпущенная прошивка или закрытый протокол, поэтому предпочитаете считать всё локально в браузере, а не отправлять на сторонний сервер.
Как использовать
- Выберите вкладку «Текст» и вставьте или введите данные, либо переключитесь на вкладку «Файл» и выберите файл на своём устройстве.
- Выберите алгоритм CRC: CRC-32 (IEEE 802.3, вариант по умолчанию и самый распространённый), CRC-16/CCITT-FALSE или CRC-16/MODBUS.
- Контрольная сумма обновляется автоматически и отображается в шестнадцатеричном, десятичном и двоичном виде.
- Нажмите «Copy» рядом с любым результатом, чтобы скопировать его в буфер обмена.
Пример
Ввод
123456789Результат
0xCBF43926 (3421780262)Это стандартный опубликованный тестовый вектор CRC-32 (IEEE 802.3): CRC-32 строки ASCII «123456789» всегда равен 0xCBF43926. Вы можете сверить результат этого инструмента с любой другой корректной реализацией CRC-32, используя именно эту строку.
CRC против криптографических хешей (MD5 / SHA)
И CRC, и криптографические хеши сводят данные к отпечатку фиксированного размера, но решают разные задачи и не взаимозаменяемы.
| Свойство | CRC (например, CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Назначение | Обнаружение случайных повреждений | Обнаружение преднамеренного вмешательства / проверка целостности |
| Скорость | Чрезвычайно быстро, простая аппаратная/программная реализация | Медленнее, больше вычислений на байт |
| Устойчивость к коллизиям | Отсутствует — легко подобрать намеренно | Разработана так, чтобы быть вычислительно неосуществимой (SHA-256), или уже взломана (MD5) |
| Типичный размер | 16 или 32 бита | 128 бит (MD5) или 256 бит (SHA-256) |
| Типичное применение | ZIP/gzip, PNG, Ethernet, Modbus, хранение данных | Проверка целостности файлов, цифровые подписи, хранение паролей (с солью) |
Похожие инструменты
Если вам нужна криптографическая контрольная сумма, а не CRC для обнаружения ошибок, эти инструменты подойдут лучше.
→ Генератор хешей (несколько алгоритмов) · Генератор MD5 · Генератор HMAC
Практическое применение при разработке встраиваемых систем и последовательной связи
В проектах, использующих промышленные и встраиваемые протоколы вроде Modbus RTU и XMODEM, ошибка в реализации CRC в конце кадра часто приводит к неприятному симптому: «связь вроде бы работает, но данные приходят неверные». Такую проблему трудно диагностировать, просто сравнивая логику CRC на бумаге с обеих сторон — надёжнее сначала сверить правильное значение для известных входных данных в этом калькуляторе, а затем сопоставить его побайтово с собственной реализацией.
Стоит особо учитывать, что за общим названием «CRC-16» скрывается множество разных вариантов, каждый со своей комбинацией полинома, начального значения, отражения битов на входе/выходе и финального XOR — и каждая комбинация даёт свой результат. Если в документации на устройство указано просто «CRC-16» без точных параметров, самый практичный способ выяснить, какой именно вариант используется, — взять образец кадра с известным корректным CRC и проверить его в этом инструменте и как CRC-16/CCITT-FALSE, и как CRC-16/MODBUS, пока значения не совпадут.
Часто задаваемые вопросы
Для чего используется CRC?
CRC (циклический избыточный код) — это код обнаружения ошибок, добавляемый к блоку данных, чтобы получатель мог пересчитать его и убедиться, что данные не были случайно повреждены при хранении или передаче. Он встроен в такие стандарты, как кадрирование IEEE 802.3 Ethernet, форматы файлов ZIP и gzip, изображения PNG, а также многие последовательные и промышленные протоколы, такие как Modbus.
CRC-32 — это то же самое, что MD5 или SHA-256?
Нет. CRC-32 — это быстрая линейная контрольная сумма для обнаружения ошибок без каких-либо свойств безопасности: легко намеренно подобрать два разных входных значения с одинаковым CRC-32. MD5 и SHA-256 — это криптографические хеш-функции, разработанные так, чтобы подобная преднамеренная коллизия была вычислительно неосуществимой. Используйте CRC-32 для обнаружения случайных повреждений (царапина на диске, потерянный сетевой пакет); используйте криптографический хеш из нашего [генератора хешей](/hash-generator) или [генератора MD5](/md5-generator), когда нужна защита от подмены или гарантии целостности против злоумышленника.
Какой вариант CRC-32 использует этот инструмент?
Вариант IEEE 802.3 / ZIP / PNG: полином 0xEDB88320 (бит-отражённая форма 0x04C11DB7), начальное значение 0xFFFFFFFF, отражение входа и выхода и финальный XOR 0xFFFFFFFF. Это вариант, используемый в Ethernet, ZIP, gzip и PNG, и именно он даёт значение 0xCBF43926 для строки ASCII «123456789» — стандартный опубликованный тестовый вектор для проверки реализации CRC-32.
В чём разница между CRC-16/CCITT-FALSE и CRC-16/MODBUS?
Оба варианта являются 16-битными CRC, но с разными полиномами и параметрами. CRC-16/CCITT-FALSE использует полином 0x1021 с начальным значением 0xFFFF и без отражения битов; он распространён в таких протоколах, как XMODEM, и различных телеком-стандартах. CRC-16/MODBUS использует полином 0x8005 (в отражённом виде 0xA001), также с начальным значением 0xFFFF, но с отражением входа и выхода — это контрольная сумма, которую Modbus RTU добавляет к каждому последовательному кадру. Для одного и того же входа они дадут разные результаты, поэтому важно выбирать вариант, который действительно указан в вашем целевом протоколе.
Могу ли я вычислить CRC файла, а не только текста?
Да. Переключитесь на вкладку «Файл» и выберите файл на своём устройстве — инструмент считывает его исходные байты локально в браузере (через File API) и вычисляет контрольную сумму именно по этим байтам, точно так же, как это сделал бы считыватель ZIP или PNG.
Отправляются ли мои данные на сервер?
Нет. Вычисления как для текста, так и для файла выполняются полностью на стороне клиента на JavaScript с использованием стандартного табличного алгоритма CRC. Ничего из введённого или загруженного никогда не покидает ваш браузер.
Результат не совпадает со значением из документации на моё Modbus-устройство. Почему?
Самая частая причина — порядок байтов (endianness). CRC-16/MODBUS обычно добавляется к кадру младшим байтом вперёд, но некоторые производители документируют значение в обратном порядке. Сначала сравните шестнадцатеричное значение из этого инструмента, не обращая внимания на порядок байтов; если оно всё равно не совпадает, возможно, устройство использует другой вариант начального значения или финального XOR.
Для файла опубликованы и CRC-32, и MD5 — что проверять?
Зависит от цели. Для проверки ошибки передачи или повреждения диска достаточно CRC-32. Для гарантии того, что файл не был намеренно изменён, проверяйте MD5 (а лучше SHA-256) — для CRC-32 легко намеренно подобрать коллизию, поэтому он не годится как гарантия целостности против злоумышленника.
Почему для одних и тех же 8 байт CRC-16/CCITT-FALSE и CRC-32 дают совершенно разные значения?
У каждого алгоритма свой образующий полином, разрядность регистра, начальное значение и обработка отражения битов на входе/выходе. Даже при одинаковых входных данных изменение любого из этих параметров даёт никак не связанный результат. Всегда выбирайте алгоритм, точно соответствующий указанному в спецификации протокола.
Можно ли посчитать CRC большого файла прямо в браузере?
Да. Поскольку инструмент читает файл через File API и обрабатывает байты табличным алгоритмом CRC, файлы размером в десятки мегабайт считаются с приемлемой скоростью. Для очень больших файлов (сотни МБ) скорость зависит от доступной памяти браузера и может заметно снизиться.