ファイル A
ファイル A をここにドロップ
クリックして選択も可 — 形式・サイズ問わず
ファイル B
ファイル B をここにドロップ
クリックして選択も可 — 形式・サイズ問わず
両方のスロットにファイルを入れると比較できます。
ファームウェアのビルド2つ、ディスクイメージ2つ、設定ダンプ2つ — byte単位の比較を、まるごとブラウザ内で。
ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。
ファイル A をここにドロップ
クリックして選択も可 — 形式・サイズ問わず
ファイル B をここにドロップ
クリックして選択も可 — 形式・サイズ問わず
byte単位で同一になるはずのファームウェアのビルドが、なぜか一致しない。転送が怪しかった回線で届いたファイルと、本来一致すべき元ファイル。デバイスが書き込む前と後の設定ブロブ。どれも聞きたいことは同じで、しかもチェックサムが絶対に答えてくれない問いです — どのbyteが、どこで変わったのか。両方のファイルを置けば、差分ごとのoffset、その差分が何byte続いているか、そして実際のbyte列が左右に並びます。0x1F40 が「ハッシュが合わなかった」ではなく「見に行ける場所」になります。
アップロードはしません。このサイトではいつも言っていることですが、このツールでは効き方が違います。実際に差分を取りたいファイルは、未発表のファームウェアイメージ、顧客データのダンプ、挙動がおかしかったマシンから取ったディスクイメージ。ビルド成果物を2つ寄こせと言ってくるサイトは、いちばん出してはいけない2つを要求していることになります。このページは静的ファイルで、比較はあなたのマシンのWeb Worker内、2つのファイルはFile APIでディスクから直接読みます。送る先のサーバーがそもそも存在しないので、ブラウザ内だけで完結するbinary diffは、アップロード型とは別物の選択肢です。
大きいファイルは「ほとんど読まない」ことで扱います。まず両方をチャンクごとにハッシュし、ハッシュが一致したチャンクはbyte単位で見るまでもなく同一と分かるので、食い違った領域だけを詳しく読みます。だから500 MBのイメージ2つを比べても1 GBをメモリに抱える必要はなく、埋め込みのバージョン文字列だけが違う2つのビルドなら、ディスクを読み終わるのとほぼ同時に終わります。2画面のビューはhex editorと同じ方式で仮想化してあり、画面に映っている行だけを組み立てるので、2 GBのイメージでもスクロールは軽いままです。
byte単位の差分が何ではないかも、はっきり言っておきます。これはテキスト差分ではなく、位置合わせもしません。ファイル先頭付近に1 byte挿入すれば、そこから後ろのbyteは全部1つずれるので、このツールは「ファイルのほぼ全体が違う」と正直に報告します。byteのレベルでは正しく、あなたのやった編集の説明としては役に立たない結果です。ここに位置合わせの魔法はありませんし、あるふりをすれば出力そのものが信用できなくなります。それでも報告する内容は使えます。比較したbyte位置に対する一致率、クリックすれば任意の差分区間へ飛べる区間リスト、そしてhex editorと同じoffset/hex/ASCII構成の同期した2画面 — 「ずれているだけで中身は同じ」を、数字に隠されずに目で見られます。
されません。2つのファイルはFile APIでローカルに開き、Blob.slice() でチャンクごとに読みます。ハッシュ計算とbyte比較はブラウザ内のWeb Workerで動きます。ページ自体は裏にAPIを持たない静的ファイルなので、原理的にアップロード先がありません。それがこのツールの要点です。まだ出荷していないファームウェアと、顧客の壊れたデータベース — いちばん差分を取りたくて、いちばん他人のサーバーに置きたくない2種類のファイルだからです。
byte単位の差分は、位置0と位置0、位置1と位置1、という具合に同じ位置同士を比べるからです。offset 16に1 byte挿入すると16以降のbyteが全部1つ後ろへずれるので、そこから先はほとんど噛み合わず、ファイル末尾まで続く差分として報告されます。ツールは嘘をついていません — そのbyte位置には本当に違う値が入っています — ただ人間が欲しい答えではない、というだけです。人間はそれを「1 byteの編集」と呼ぶからです。テキストに近いファイルなら行単位のdiffが正解。バイナリなら、差分が始まるoffsetを見てください。そこが挿入位置で、たいていそれが知りたかった事実です。
重なっている範囲はbyte単位で比較し、片方にしかない末尾はoffsetと長さ付きの差分として報告します。黙って捨てたりはしません。一致率は長いほうのファイルを分母にするので、1 MBのファイルに1 MB追記したものは100%ではなく約50%になります。追記されたデータは実在する差分で、完全一致と表示するほうが誤解を招くからです。長さの不一致それ自体も別に明示します。同じファームウェアのビルド2つなら、まずそこを知りたいことが多いからです。
上限になるのはメモリではなくディスク速度、という程度までです。どちらのファイルも丸ごとは読み込みません。チャンクのハッシュで食い違う領域を特定し、詳しく比べるのはその領域だけ、hexの2画面も画面上の行しか描きません。片側が数百MBは日常的で、数GBのディスクイメージも動きます — 最初のパスは両方のファイルをハッシュに流す必要があるので、ディスクが渡し終えるまでの時間はかかります。ブラウザのタブにはメモリ上限があり、だからこそここではイメージを一度に抱えようとしていません。
見られます。各画面はhex editorと同じoffset・hex・ASCIIの列を持ち、ハイライトはhexのbyteとASCII側の両方にかかります。埋め込み文字列やファイルパスの中の変化が、起きたその場所でテキストとして読めます。当たりを付けていた差分の確認には、これがいちばん速いことが多いです。ビルド日時、バージョン番号、シリアル番号はASCII列で普通の文字として現れる一方、hex列は動いたbyteしか見せてくれないからです。
同じ値が入っているbyte位置の割合を、長いほうのファイルの長さで割ったものです。それ以上の細工はないので、理屈は追いやすく、そのぶん自分で誤読もしやすい数字です。同じ長さの無関係なファイル2つでも、偶然だけで0.4%前後にはなります。ランダムなbyte同士は256回に1回一致するからです。先頭に1 byte入っただけのファイルは、中身がほぼ同じでも数%まで落ちます。区間リストと並べてざっと当たりを付ける数字として読むのが正解です — 短い区間3つで99.98%なら文字列を1か所書き換えただけ、6%なら別のファイル — 本当の答えが欲しいときはoffsetを読んでください。