Several common CRC instance predefined and available from a list. Furthermore, the definition of own CRC instances is supported by specifying:
Width of CRC (8, 16 or 32 bit)
Initial CRC value
Final XOR value
Also the generation of CRC lookup tables is supported.
If the input data is defined as 'string', then each character (including whitespaces) is converted to its (byte) value and this byte stream is the input for the calculation. E.g. the string "12" is converted to its ASCII respresentation [0x31, 0x32]. This means that the CRC of input string "12" and byte input 0x31 0x32 is the same.
If the input data is defined as 'bytes', then the byte values shall be given in hexadecimal notation beginning with a "0x" and separated by a white space, e.g "0x31 0x32". If no whitespace is detected, the "0x" prefix must be omitted and always two digits are taken for a character. So instead of "0x31 0x32", it's also possible to specify "3132". Note that this means that "01" and "0001" are then NOT the same.
If the input data is defined as 'binary string', then the byte values shall be given as eight-digit binary strings, separated by a white space. So "00110001 00110010" is the same as bytes 0x31 0x32. If a single string has less than eight digits, zeros are padded as prefix, so 100 is actually interpreted as 00000100. If a single string has more than eight digits, only the first eight digits are used.
2019/02/12: Added the support for 64bit CRC calculation and for binary string input.
2016/11/11: Added the option to print the CRC lookup table 'reversed'.
2016/07/27: Fixed a bug: A hexadecimal value with more than two digits after the "0x" is not correctly parsed. This could have resulted in the fact that the calculated CRC value of 0x01 differs to e.g. of 0x0001. Please note the added description above about input data. Thanks to Matthew Reed for pointing the issue to me.
2016/07/09: Fixed a bug: When the input data was given as bytes, then the number of whitespaces had an influence on the result. E.g the CRC value of "0x31 0x32" and "0x31 0x32" (note the additional space character) were not the same. The fix now shall ignore all number and kinds of whitespace characters and take only the byte values into account. Thanks to Alan Ott Goodman for pointing the issue to me.
2016/03/09: Fixed a bug: Sometimes a CRC32 result value was printed with only seven digits! A zero was then missing, e.g. the printed result was 0xC6FF2F8 instead of the correct one 0xC6FF02F8. Thanks to David Goodman for pointing the issue to me.
2015/05/30: Initial release.