輸入
9 位元組開頭幾個位元組:31 32 33 34 35 36 37 38 39
自訂參數
Rocksoft 模型的六個數字。任何一份講 CRC 的規格書，講的就是這六個，順序通常也一樣——而且常常沒給演算法名字。
結果
—
對「123456789」的 check
—
每一份公開的 CRC 都會寫這個值。它跟規格書上的 check 對得起來，上面那六個數字才真的是那份文件講的演算法——先確認這個，再去信左邊的結果。
所有具名的 CRC
一份輸入，113 種公開演算法，一次全算。哪一列的結果跟你手上的檢查碼一樣，那就是你要找的演算法。
0 種
沒有演算法符合這個條件。
從檢查碼反推演算法
手上有一個訊框和它帶的檢查碼，但沒人寫下那是哪一種 CRC。把訊框放上面的輸入、檢查碼放這裡，讓搜尋回答你。
裝置或檔案針對上面那串位元組，實際帶著的值。
符合：0
113 個公開模型之後，搜尋會把 8 位元的多項式全試一遍，再試 16 位元；init 與 xorout 各取全 0 或全 1，兩種反轉設定都試。16 位元以上不做窮舉：四十億個多項式不是一個瀏覽器分頁跑得完的搜尋。
非 CRC 的檢查碼
結尾那幾個位元組不一定是 CRC。世上另外一半的協定實際在用的就是這八種，它們算的是同一份輸入。
| 檢查碼 | 十六進位 | 十進位 |
|---|---|---|
| sum8位元組加總，取 8 位元。 | — | — |
| sum16位元組加總，取 16 位元。 | — | — |
| xor8所有位元組 XOR 起來——Modbus ASCII 和 NMEA 的 LRC。 | — | — |
| fletcher16兩條 mod 255 的累加，所以順序換掉答案就會變。 | — | — |
| fletcher32同一套想法搬到 16 位元小端序字組，mod 65535。 | — | — |
| adler32Fletcher 的近親，mod 65521——每個 zlib 串流結尾都是它。 | — | — |
| internetChecksumRFC 1071：把 16 位元大端序字組的一補數和再取一次一補數。IP、UDP、TCP 的標頭都用它。 | — | — |
| bsdChecksum先右旋一位再相加——BSD 的 sum(1) 印出來的就是這個。 | — | — |
NMEA 0183 語句
檢查碼—
把開頭的 $ 或 ! 到 * 之間的字元全部 XOR。只有這一個吃的是整句話而不是上面那串位元組，因為標準就是這樣定的。