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

出典:wikipedia