CRC32 チェックサム計算ツール

テキスト、16進数のバイト列、ファイル全体の CRC-32 または CRC-32C チェックサムを計算し、16進数、10進数、Base64 で表示して、期待する値と比較できます。ファイルはローカルで読み込まれ、アップロードされることはありません。

すべてのアルゴリズム

すべてブラウザ内で処理され、データはアップロードされません。

使い方

  1. テキストを入力または貼り付けます。生のバイト列は「入力形式」を「16進数」に切り替えて入力し、ファイルの内容のチェックサムを求めるには「ファイルを開く」でファイルを選びます。
  2. ZIP、gzip、PNG 用のチェックサムなら、「アルゴリズム」は CRC-32 のままにしておきます。iSCSI、ext4、Btrfs、Google Cloud Storage 用のチェックサムを求める場合は、CRC-32C を選びます。
  3. 「出力形式」で「16進数(小文字)」「16進数(大文字)」「10進数」「Base64」のいずれかを選びます。
  4. 照合するには、期待するチェックサムを「比較対象」に貼り付けます。0x を付けない16進数、10進数、Base64 のいずれでも入力できます。

CRC32 チェックサムとは

巡回冗長検査(CRC)は、入力全体を 1 つの長い 2 進多項式とみなして固定の生成多項式で割り、その余りを結果とします。CRC-32 では余りは 32 ビットで、通常は16進数 8 桁、または 0~4,294,967,295 の符号なし整数で表されます。データにほぼどんな変更を加えても、余りは変わります。

CRC は、実際のケーブル、無線、ディスクで発生するエラーを検出するために設計されています。CRC-32 は長さ 32 ビットまでのバースト誤りをすべて検出でき、ランダムな破損を見逃すのは約 43 億回に 1 回程度です。また、計算が非常に高速なため、ZIP、gzip、PNG、Ethernet フレームに組み込まれています。

CRC-32 と CRC-32C

CRC-32CRC-32C(Castagnoli)
多項式0x04C11DB7(ビット反転形 0xEDB88320)0x1EDC6F41(ビット反転形 0x82F63B78)
123456789 のチェック値cbf43926e3069283
主な用途ZIP、gzip、PNG、EthernetiSCSI、SCTP、ext4 のメタデータ、Btrfs、Google Cloud Storage
ハードウェア対応ARMv8 の CRC32 命令x86 SSE4.2 の crc32 命令、ARMv8

どちらも初期値 0xFFFFFFFF から始め、各バイトのビットを最下位ビットから順に処理し、最後に値を反転します。異なるのは多項式だけですが、それによって同じデータからまったく無関係な 2 つの結果が得られます。多くのツールが「CRC32」と呼ぶのは前者で、CRC のカタログでは CRC-32/ISO-HDLC として登録されています。CRC-32C は誤り検出能力の高さから、後にストレージやネットワークのプロトコルで採用されました。Google Cloud Storage は CRC-32C を、Amazon S3 はどちらかの方式を、4 バイトをビッグエンディアン順に並べて Base64 にした形式で返します。これは、このツールの Base64 出力とまったく同じ形式です。

セキュリティ検査ではなく、あくまでチェックサム

CRC は偶発的な事故から守るためのもので、攻撃を防ぐものではありません。CRC は線形関数なので、誰でもファイルを改変したうえで 4 バイトを調整し、CRC-32 を変えないままにできます。そのため、CRC が一致しても、意図的な改ざんがないことの証明にはなりません。ダウンロードを確認するには信頼できる入手元の SHA-256 ハッシュ値と比較し、メッセージの送信者を証明するには HMAC を使用してください。

また、32 ビットはデータを識別するには短すぎます。ランダムなファイルが約 77,000 個あれば、そのうち 2 つが同じ CRC-32 になる確率はすでに 50% に達します。そのため、一意の ID や重複排除のキーとしては使わないでください。攻撃者が関与しない場面なら、MD5 や SHA-256 のほうがはるかに優れたフィンガープリントになります。

コードで CRC32 を計算する

# Python:Python 3 の zlib.crc32 は符号なし
# "& 0xffffffff" が必要なのは Python 2 のみ
import zlib
format(zlib.crc32(b'123456789'), '08x')    # 'cbf43926'

// Node.js 20.15 以降、22.2 以降
require('zlib').crc32('123456789').toString(16).padStart(8, '0')   // 'cbf43926'

// Go (import "hash/crc32")
crc32.ChecksumIEEE(data)                                   // CRC-32
crc32.Checksum(data, crc32.MakeTable(crc32.Castagnoli))    // CRC-32C

// Java:java.util.zip.CRC32、Java 9 以降は java.util.zip.CRC32C も使用可能

// PHP
sprintf('%08x', crc32('123456789'));   // 'cbf43926'
hash('crc32b', '123456789');           // 'cbf43926'(同じ CRC-32)
hash('crc32c', '123456789');           // 'e3069283'
hash('crc32', '123456789');            // '181989fc'(別の CRC)

PHP では名前に注意してください。crc32 という名前のハッシュアルゴリズムは ZIP のチェックサムではなく、bzip2 で使われる CRC を逆のバイト順で出力したものです。ZIP、gzip、このツールと同じ値を得るには、crc32b または crc32() 関数を使用してください。Unix の cksum コマンドはさらに別の方式を使っており、ファイルの長さも計算に含めるため、その値はどちらとも一致しません。

エンコード例

入力 (UTF-8)CRC-32
Hello, World!ec4ac3d0
Base64.is915d7207
你好50a2b841

よくある質問

「123456789」の CRC32 はいくつですか?
この文字列は、CRC アルゴリズムの標準的なテスト入力です。CRC-32 は cbf43926(10進数では 3421780262)、CRC-32C は e3069283 です。自作の実装がこれらの値を返せば、このツールと同じパラメーターを使っていることになります。
ほかのツールと CRC32 が異なるのはなぜですか?
次の 4 点を確認してください。方式(CRC-32、CRC-32C、bzip2 の CRC、POSIX の cksum はすべて異なる結果になります)、入力のバイト列(改行コード、末尾の改行、文字コード)、数値の形式(言語によっては符号付き 32 ビット整数を返すため、大きな値が負の数になります)、そしてバイト順です。
ZIP や gzip ファイルの中で CRC のバイトが逆順になっているのはなぜですか?
ZIP と gzip は CRC-32 をリトルエンディアンのバイト順で保存するため、16進エディターで見ると、通常の表記とは 4 バイトが逆順に並んでいます。PNG はビッグエンディアンで保存します。このツールや unzip -v をはじめ、ほとんどのプログラムは最上位バイトから表示します。
大きなファイルの CRC32 も計算できますか?

はい。「ファイルを開く」をクリックすると、ファイルをアップロードすることなく、お使いのデバイス上でそのバイト列からチェックサムが計算されます。ブラウザがメモリに読み込めるファイルであれば、どれでも扱えます。結果は、SFV ファイルや ZIP の一覧に記載された値と比較できます。

CRC32 はハッシュ関数ですか?

任意の長さのデータを固定の 32 ビット値に変換するため、ハッシュ関数と一緒に紹介されることがよくありますが、CRC32 はチェックサムです。偶発的なエラーは検出できても、意図的にデータを改変する人に対しては何の防御にもなりません。より強力なフィンガープリントが必要な場合は、結果の下にある「すべてのアルゴリズム」の表で、同じ入力の MD5 や SHA ファミリーの値を確認できます。