CodeKitHubこのツールとは？
CRCはCyclic Redundancy Check(巡回冗長検査)の略で、1975年のW. Wesley PetersonとD.T. Brownによる論文で初めて記述されたエラー検出符号であり、後にRoss Williamsの「A Painless Guide to CRC Error Detection Algorithms」やITU-T/ISO 3309規格などの文献で正式化されました。CRCはメッセージを大きな二進数として扱い、それを固定の生成多項式で除算します。その除算の余りがチェックサムです。多項式除算はハードウェアでもソフトウェアでも計算コストが低いため、CRCはストレージや伝送システムにおけるデフォルトのエラーチェックとなりました。
CRC-32——具体的には多項式0xEDB88320、初期値0xFFFFFFFF、最終XOR 0xFFFFFFFFのバリアント——はIEEE 802.3(Ethernet)で標準化されており、ZIPやgzipアーカイブ、PNG画像ファイル、その他無数のネットワーク・ストレージプロトコルの内部チェックサムとして使用されています。圧倒的に最もよく求められるCRCバリアントであるため、このツールのデフォルトアルゴリズムになっています。CRC-16/CCITT-FALSE(多項式0x1021)とCRC-16/MODBUS(多項式0x8005、リフレクト)は、Modbus RTU、XMODEM、さまざまな組み込み・産業用通信規格などのシリアルプロトコルで広く使われている2つの16ビットバリアントです。
CRCが何でないかを理解することが重要です。CRCは暗号学的ハッシュではありません。CRCは高速で線形な関数であり、意図的な操作に対する耐性はまったくありません。同じCRC値を生成する別のメッセージを作ることは容易です。CRCはノイズの多い伝送路やディスクエラー、途中で切れたダウンロードなどによって生じるランダムなビット反転を検出するのには優れていますが、データを検知されずに改ざんしようとする攻撃者に対しては何の保護にもなりません。
なぜこれを使うのか？
- 組み込み機器のファームウェアを書いていて、自作したCRC-32ルーチンの出力が正しいのか自信が持てず、標準テストベクター「123456789」で答え合わせをしたいとき。
- PLCとModbus RTU経由で通信するシリアル機器を開発していて、送信フレームに付加すべきCRC-16/MODBUS値が仕様書の期待値と一致しないままデバッグが行き詰まっているとき。
- 破損したZIPファイルから復元したエントリが正しいデータかどうか確信が持てず、生のバイト列から自分でCRC-32を再計算してヘッダに記録された値と突き合わせたいとき。
- PNG画像の一部が壊れているという報告を受けて、該当チャンクのバイト列を抜き出し、記録されているCRCと実際の計算結果を比較して原因を切り分けたいとき。
- 社内の通信プロトコルパーサーを書き直していて、XMODEM用のCRC-16/CCITT-FALSE実装が正しいかどうかを、独立した第三者ツールで検証したいとき。
- デバッグ対象のデータがまだ社外に出せない段階の未公開ファームウェアやプロプライエタリなプロトコルであるため、サーバーに送信せずブラウザ内だけで計算を完結させたいとき。
使い方
- 「テキスト」タブを選択して入力を貼り付けるか入力するか、「ファイル」タブに切り替えてデバイスからファイルを選択します。
- CRCアルゴリズムを選択します: CRC-32(IEEE 802.3、デフォルトかつ最も一般的)、CRC-16/CCITT-FALSE、またはCRC-16/MODBUS。
- チェックサムは自動的に更新され、16進数、10進数、2進数で表示されます。
- 結果の横にある「コピー」をクリックすると、クリップボードにコピーされます。
例
入力
123456789出力
0xCBF43926 (3421780262)これは標準として公開されているCRC-32(IEEE 802.3)のテストベクターです。ASCII文字列「123456789」のCRC-32は常に0xCBF43926になります。この正確な文字列を使って、他の正しいCRC-32実装とこのツールの出力を照合できます。
CRCと暗号学的ハッシュ(MD5 / SHA)の比較
CRCと暗号学的ハッシュはどちらもデータを固定サイズのフィンガープリントに圧縮しますが、異なる問題を解決するものであり、互換性はありません。
| 特性 | CRC(例: CRC-32) | MD5 / SHA-256 |
|---|---|---|
| 目的 | 偶発的な破損の検出 | 意図的な改ざんの検出 / 完全性の検証 |
| 速度 | 極めて高速、単純なハードウェア/ソフトウェア | より遅く、バイトあたりの計算量が多い |
| 衝突耐性 | なし——意図的に作るのは容易 | 計算量的に実現不可能になるよう設計(SHA-256)、またはMD5は破られている |
| 一般的なサイズ | 16または32ビット | 128ビット(MD5)または256ビット(SHA-256) |
| 一般的な用途 | ZIP/gzip、PNG、Ethernet、Modbus、ストレージ | ファイル整合性チェック、デジタル署名、パスワード保存(ソルト付き) |
関連ツール
エラー検出用のCRCではなく暗号学的チェックサムが必要な場合は、以下のツールがより適しています。
組み込み・シリアル通信開発での実務的な使い方
Modbus RTUやXMODEMのような産業用・組み込みプロトコルを扱う開発現場では、フレームの末尾に付加するCRCの実装ミスが原因で、機器同士が『通信はできているのにデータが正しく認識されない』という厄介な症状を引き起こすことがよくあります。こうした問題は、送信側と受信側で別々に実装されたCRCロジックを机上で見比べるだけでは原因が特定しにくく、既知の入力に対する正しい出力値をこのツールで先に確認し、自作の実装と1バイトずつ突き合わせていくのが最も確実なデバッグ方法です。
特に注意したいのが、同じ『CRC-16』という名前でも、多項式・初期値・入出力のビット反転・最終XORの組み合わせによって全く異なる値を返すバリアントが数多く存在する点です。仕様書に『CRC-16』としか書かれておらず具体的なパラメータが不明な場合は、既知の正しいCRC値を持つサンプルフレームを1つ用意し、CRC-16/CCITT-FALSEとCRC-16/MODBUSの両方でこのツールを使って照合すれば、どちらのバリアントが実際に使われているかを絞り込めます。
よくある質問
CRCは何のために使われますか?
CRC(巡回冗長検査)はデータブロックに付加されるエラー検出符号で、受信側が再計算することで、保存や伝送中にデータが偶発的に破損していないかを確認できます。IEEE 802.3のEthernetフレーミング、ZIPやgzipファイル形式、PNG画像、Modbusなど多くのシリアル・産業用プロトコルに組み込まれています。
CRC-32はMD5やSHA-256と同じですか?
いいえ。CRC-32はセキュリティ特性を持たない高速で線形なエラー検出用チェックサムであり、同じCRC-32値を持つ2つの異なる入力を意図的に作ることは容易です。MD5とSHA-256は、そのような意図的な衝突を計算量的に実現不可能にするよう設計された暗号学的ハッシュ関数です。ディスクの傷やネットワークパケットの欠落といった偶発的な破損を検出するにはCRC-32を使い、攻撃者による改ざんに対する耐タンパー性や完全性の保証が必要な場合は、[ハッシュジェネレーター](/hash-generator)や[MD5ジェネレーター](/md5-generator)の暗号学的ハッシュを使ってください。
このツールはどのCRC-32バリアントを使用していますか?
IEEE 802.3/ZIP/PNGバリアントです: 多項式0xEDB88320(0x04C11DB7のビット反転形式)、初期値0xFFFFFFFF、入出力ともにリフレクト、最終XOR 0xFFFFFFFF。これはEthernet、ZIP、gzip、PNGで使用されているバリアントであり、ASCII文字列「123456789」に対して0xCBF43926を生成する、CRC-32実装を検証するための標準テストベクターです。
CRC-16/CCITT-FALSEとCRC-16/MODBUSの違いは何ですか?
どちらも16ビットのCRCですが、多項式とパラメータが異なります。CRC-16/CCITT-FALSEは多項式0x1021を使用し、初期値0xFFFF、ビット反転なしで、XMODEMやさまざまな通信規格などのプロトコルで一般的です。CRC-16/MODBUSは多項式0x8005(反転すると0xA001)を使用し、同じく初期値0xFFFFですが、入出力ともにリフレクトされます。これはModbus RTUが各シリアルフレームに付加するチェックサムです。同じ入力に対しても異なる結果を生成するため、対象プロトコルが実際に指定しているバリアントを選ぶことが重要です。
テキストだけでなくファイルのCRCも計算できますか?
はい。「ファイル」タブに切り替えてデバイスからファイルを選択すると、このツールはブラウザ内でローカルに(File API経由で)生のバイト列を読み取り、ZIPやPNGリーダーと同じ方法でそれらのバイトに対してチェックサムを計算します。
私のデータはサーバーにアップロードされますか?
いいえ。テキストとファイルの計算はどちらも、標準的なテーブルベースのCRCアルゴリズムを使用してクライアント側のJavaScriptで完全に実行されます。入力またはアップロードした内容がブラウザから出ることはありません。
計算結果がModbus機器の仕様書に載っている値と一致しません。なぜですか?
最も多い原因は、バイト順(エンディアン)の解釈違いです。CRC-16/MODBUSは計算結果を下位バイト・上位バイトの順でフレームに付加するのが一般的ですが、機器やドキュメントによっては逆順で記載されていることがあります。このツールが出す16進数の値自体が仕様と一致しているか、まずバイト順を無視して比較し、それでも一致しない場合は初期値やXOR処理が異なるバリアントを使っている可能性を疑ってください。
同じデータに対してCRC-32とMD5の値が両方載っている場合、どちらを信頼すべきですか?
目的によります。単なる転送エラーやディスク破損のチェックであればCRC-32で十分ですが、ファイルが意図的に改ざんされていないかを保証したい場合はMD5(理想的にはSHA-256)を確認してください。CRC-32は衝突を意図的に作るのが容易なため、セキュリティ目的の完全性検証には使えません。
同じ8バイトの入力でも、CRC-16/CCITT-FALSEとCRC-32でまったく違う値が出るのはなぜですか?
使用する生成多項式、レジスタ幅、初期値、そして入出力のビット反転処理(リフレクト)がアルゴリズムごとに異なるためです。同じ入力データであっても、これらのパラメータが一つでも違えば出力は無関係な値になります。プロトコル仕様書に記載されたアルゴリズム名と一致するものを必ず選んでください。
大きなファイルでもブラウザだけでCRCを計算できますか?
はい。File API経由でファイルを読み込み、テーブルベースのCRCアルゴリズムでバイト列を処理するため、数十MB程度のファイルであれば実用的な速度で計算できます。数百MBを超える非常に大きなファイルの場合は、ブラウザのメモリとタブの処理能力に依存するため、動作が重くなることがあります。