入力
9 バイト先頭バイト:31 32 33 34 35 36 37 38 39
自分のパラメータ
Rocksoft モデルの6つの数値。CRC を説明しているデータシートは、たいていこの順でこの6つを書いています。名前は書いていないことも多い。
結果
—
「123456789」に対する check
—
公表されている CRC は必ずこの値を書いています。データシートの check と一致すれば、上の6つはその文書が言っているアルゴリズムそのものです。左の結果を信じるのはそのあとで。
名前のある CRC 全部
入力ひとつに対して、公表されている 113 種を一度に計算します。手元のチェックサムと一致する行が、探しているアルゴリズムです。
0 種
その条件に合うアルゴリズムはありません。
チェックサムから逆に辿る
フレームとそれが載せているチェックサムはあるのに、どの CRC で作られたかはどこにも書いていない。フレームを上の入力に、チェックサムをここに入れれば、探索が答えます。
上のバイト列に対して、機器やファイルが実際に載せている値です。
一致: 0
公表されている 113 モデルの先は、8ビットの多項式を全部、次に16ビットを全部試します。init と xorout はそれぞれ全0か全1、反転は両方。16ビットより広い幅は総当たりしません。40億通りの多項式は、ブラウザのタブが終えられる探索ではありません。
CRC 以外のチェックサム
末尾のバイトが必ず CRC とはかぎりません。世の中のプロトコルの残り半分が実際に使っているのはこの8つで、同じ入力に対して計算しています。
| チェックサム | 16進 | 10進 |
|---|---|---|
| sum8バイトを足して 8 ビットに丸めたもの。 | — | — |
| sum16バイトを足して 16 ビットに丸めたもの。 | — | — |
| xor8全バイトの XOR。Modbus ASCII と NMEA の LRC。 | — | — |
| fletcher16mod 255 の走行和が2本。並び替えると値が変わります。 | — | — |
| fletcher32同じ考えを16ビットのリトルエンディアン語に、mod 65535 で。 | — | — |
| adler32Fletcher の親戚、mod 65521。zlib ストリームの末尾にいます。 | — | — |
| internetChecksumRFC 1071。16ビットのビッグエンディアン語の1の補数和の、さらに1の補数。IP・UDP・TCP のヘッダ。 | — | — |
| bsdChecksum右に1ビット回してから足す。BSD の sum(1) が出す値。 | — | — |
NMEA 0183 センテンス
チェックサム—
先頭の $ または ! と * の間にある文字を全部 XOR します。これだけは上のバイト列ではなくセンテンスを取ります。規格がそう定めているからです。