 |
|
|
И знаю, почему так делается. Если интересна теория - почитайте книгу Питерсона и Уэлдона "Коды, исправляющие ошибки", М., Мир, 1976.
Приведенный Вами пример очевидно ошибочен. Уж не знаю, это ошибка автора, ошибка переводчика или ошибка, вкравшаяся при цитировании. Чтобы приведенный пример был корректен, нужно после обработки сообщения прокрутить цикл еще четыре раза (в случае CRC-32), т. е. дополнить сообщение четырьмя нулями. Или, что эквивалентно если первоначально в регистр прописывается нуль, добавлять байт сообщения не справа к регистру в п. 1., а делать XOR очередного байта сообщения со старшим байтом регистра до его сдвига - перед п. 1. Т. е. алгоритм такой:
1. Прописать в регистр нуль.
2. XOR очередного байта сообщения со старшим байтом регистра.
3. Сдвиг регистра влево на 1 байт и дополнение регистра справа нулем.
4. Байт, выдвинутый из регистра используется в качестве индекса в таблице 256 32-битных значений.
5. Операция XOR табличного значения с содержимым регистра.
6. Если сообщение до конца не обработано, вернуться к 2 шагу.
7. Приписать содержимое регистра к сообщению в конце в порядке от старшего байта к младшему.
Достаточным условием для того, чтобы этот цикл, повторенный для сообщения, дополненного проверочными байтами, давал нуль, является равенство нулю нулевого элемента таблицы. Результат будет нулевой даже в том случае, если все остальные элементы таблицы Вы построите некорректно. Правда, вероятность необнаружения искажения последовательности может при этом сильно возрасти.
И учтите, что иногда используются модификации CRC, в которых в качестве проверочных используют, например, инверсию обычных проверочных бит. В этом случае прогон цикла по последовательности, дополненной проверочными битами, даст не ноль, а другую константу. Это позволяет отловить ситуацию, когда в канале связи все биты сообщения вместе с проверочными заменились нулями - обычный алгоритм CRC в этом случае ошибку не обнаруживает. К Вашему алгоритму это не относится.
E-mail: 
info@telesys.ru
