Adler-32
| 
| 
Adler-32 は、Mark Adler が考案したチェックサムアルゴリズム。同じ長さの巡回冗長検査と比較すると、信頼性と引き換えに高速性を追求している。その元となった Fletcher-16 に比較すると信頼性が高いが、Fletcher-32 に比較すると若干信頼性が劣る。
歴史
Adler-32 はフレッチャーのチェックサムを修正したものである。
同じく Mark Adler が開発したzlib圧縮ライブラリの一部として使われている。Adler-32 に基づくローリングチェックサムが rsync で使われている。
アルゴリズム
Adler-32 チェックサムは、まず2つの16ビットのチェックサム A と B を計算し、それらを連結して32ビットの整数にする。Aは全てのバイトの総和に1を加えた値、B は A を計算している各ステップの値を累積した総和である。
初期状態では、A は 1 に初期化され、B は 0 に初期化される。これらの総和は modulo 65521 で保持される（65521 は 216 未満の最大の素数）。これらのバイトはネットワークオーダー（ビッグエンディアン）で格納され、B が最上位バイト側に位置する。
式で表すと、以下のようになる。
ここで D はチェックサム計算対象のバイト列の各バイトを意味し、n はバイト数を意味する。
例
ASCII文字列 "Wikipedia" のAdler-32チェックサムは以下のように計算される。
この例では、総和が65521を超えることがないため、modulo演算は特に意味がない。
フレッチャーのチェックサムとの比較
1つめの違いは、Adler-32では素数の modulo を使って計算している点で、フレッチャーの場合は使うビット数に応じて modulo 24-1, 28-1, 216-1 を採用している（これらは合成数である）。素数を使うことで、フレッチャーのチェックサムでは捉えられないバイト列の違いを捉えられることがある。
2つめの違いはアルゴリズムの高速性に関連するもので、Adler-32 では16ビットワード単位ではなく8ビットバイト単位で計算するため、ループ回数が2倍になる。このため16ビット境界に整列されたデータでは、フレッチャーのチェックサムの1.5倍から2倍の時間がかかる。ただし、バイト単位に整列されたデータでは、Adler-32 は普通に実装されたフレッチャーのチェックサムよりも高速である。
（省略されました・・全てを読むにはここを押してください）
出典:フリー百科事典『ウィキペディア』 改訂履歴
- Ｑ＆Ａ
- ニュース
