ByteScope

TIFF ファイル形式

Tagged Image File Format。スキャンや印刷で使われる柔軟なラスターコンテナ。

MIME タイプ
image/tiff
拡張子
.tif, .tiff
カテゴリ
画像

マジックナンバー(ファイル署名)

0x0000000049492A00II*·'II' little-endian + 42

ビッグエンディアンの TIFF は代わりに 4D 4D 00 2A('MM' + 42)で始まります。

TIFF 形式について

TIFF はタグベースのコンテナで、複数の画像・レイヤー・任意のメタデータを保持できるため、出版や文書スキャンで好まれます。先頭 2 バイトがバイトオーダーを示し、リトルエンディアンなら II、ビッグエンディアンなら MM、その後にマジックナンバー 42 が続きます。それ以外はすべてオフセットをたどって到達します。ヘッダが image file directory を指し、各ディレクトリは 12 バイトのタグエントリの並びと次のディレクトリへのポインタでできていて、各タグは値をその場に持つか、さらに別の場所を指すかのどちらかです。TIFF が同時代の形式より長生きし、そして構造的に同じ TIFF が 2 つとして存在しないのは、この設計のせいです。

ヘッダーの構造(バイト単位)

オフセット長さフィールド意味
02Byte orderII なら 49 49 でリトルエンディアン、MM なら 4D 4D でビッグエンディアン。直後の 2 バイトを含め、ファイル中のすべての多バイト数値を支配するので、他の何かを解釈する前に必ず読まなければならない唯一のフィールドです。カタログの署名がリトルエンディアン形しか載せていないのは、双方向の署名を固定バイト列として表現できないためです。
22Version number数値の 42 で、ビッグエンディアンのファイルでは 00 2A、リトルエンディアンでは 2A 00 と書かれます。実はバージョンではありません。一度も変わったことがなく、オフセット 0 のバイトオーダーが正直だったことを裏付ける 2 つ目のマジックナンバーです。ここが 43 なら BigTIFF で、ヘッダ配置がまるごと別物になります。
44Offset of the first image file directoryIFD0 の開始位置をファイル先頭から数えたもの。小さい値である必要はどこにもありません。書き手は画素データの後ろにディレクトリを置いてよく、macOS の sips は日常的にそうするので、ヘッダが数千バイト先を指しているファイルはまったく普通です。オフセットは偶数でなければならず、0 であってはいけません。
8variableFirst byte after the headerオフセット 8 は IFD が合法的に置ける最も早い位置で、実際よく使われますが、あくまでオフセット 4 のヘッダがたまたまそこを指しているというだけです。IFD 自体は 2 バイトのエントリ数、その数だけの 12 バイトエントリ(タグ・型・個数、そして値そのものか値へのオフセット)、最後に次の IFD への 4 バイトオフセット、連鎖の終わりなら 0 という構成です。
42Offset byte size — BigTIFF onlyオフセット 2 が 42 ではなく 43 と読めるとき、ヘッダは 8 バイト長くなり、このフィールドがファイルオフセットのサイズ、常に 8 を保持します。BigTIFF を古典的な TIFF として読むと、このフィールドが IFD ポインタの下半分に見えてしまい、パーサは意味のない場所へ飛ばされます。
62Reserved — BigTIFF only常に 00 00。ひとつ手前のフィールドと合わせて、古典的な TIFF リーダーが 4 バイトの IFD オフセットとして食べてしまう部分です。BigTIFF が互換性を保とうとせずバージョン番号のほうを変えたのは、まさにこれが理由です。
88First IFD offset — BigTIFF only64 ビットのオフセットで、これこそが BigTIFF の存在理由です。古典的な TIFF は 4 ギガバイトより先を指せません。BigTIFF のディレクトリエントリは 12 バイトではなく 20 バイトで、個数と値も 64 ビットなので、2 つの配置は先頭 2 バイト以外まったく共通点がありません。

似た形式との見分け方

紛らわしい形式見分け方
Big-endian TIFFカタログの署名は 49 49 2A 00 しかカバーしていません。ビッグエンディアンのファイルは 4D 4D 00 2A で、同じくらい正当で同じくらいよく見かけます。Motorola や Sun 系譜のスキャナやプリプレスソフトはこちらを既定にしますし、JPEG の中の Exif もよくこの順序を使います。片方しか照合しない検出器は、世界の TIFF の半分を不明と呼ぶことになります。
JPEG競合相手ではなく、hex ダンプで見分けられると得をするコンテナ関係です。JPEG の中の Exif ブロックは、完結した TIFF 構造そのものです。カメラの JPEG なら、ASCII の Exif と NUL 2 つの 6 バイト後、オフセット 12 に 49 49 2A 00 か 4D 4D 00 2A が見つかります。この構造の中のオフセットはすべてファイル先頭ではなく TIFF ヘッダからの相対値で、手書きの Exif パーサがゴミを読む古典的な原因はこれです。
DNGDNG、NEF、ARW、ORF をはじめ大半の RAW 形式はバイトレベルでは TIFF ファイルで、TIFF リーダーできれいに解析できます。見分けるのは IFD0 の中のタグで、DNG なら DNGVersion (0xC612) などです。例外は Canon の CR2 で、こちらは独自のヘッダを名乗り、素の TIFF なら最初のディレクトリがあるオフセット 8 に ASCII の CR とバージョンの組を置きます。Canon が公開したのではなく、リバースエンジニアリングによって文書化された配置です。
BigTIFF違いは 1 バイトです。ファイルが今宣言したバイトオーダーでオフセット 2 のバージョンフィールドを読んでください。42 なら古典的な TIFF、43 なら BigTIFF です。ホールスライドの顕微鏡画像、衛星画像、大きな OME-TIFF スタックを格納しているものは後者になります。古典的な TIFF リーダーにこれを渡しても、間違った画像が出てくるのではなく、意味不明な IFD オフセットとエラーが返ってきます。

よくある壊れ方

  • 途中切れ。ここでの挙動は他の多くの形式と逆になります。書き手が IFD0 を画素データの後ろに置いていた場合、合法でよくある選択ですが、途中で切れた TIFF は走査行を全部残したままディレクトリだけを丸ごと失います。画像は完全に存在するのにファイルは開けません。復旧するには幅・高さ・ビット深度を推測し、ディレクトリを手で組み立て直すことになります。
  • IFD オフセットがファイル末尾より先を指している場合。ヘッダは完璧なのにリーダーには手がかりが何もなく、このファイルは TIFF ではありませんという、およそ役に立たない汎用メッセージが出ます。アップロードが途中で終わったスキャンや、誤って連結されたスキャンはたいていこの姿になります。
  • バイトオーダーのバイトが書き換わったり失われたりした場合。II を MM にひっくり返すとバージョン番号が 42 として読めなくなるので、ファイルは即座に拒否されます。バージョンは読めるまま別の場所で順序を取り違えると、ファイル中の幅・高さ・オフセットがすべて天文学的な数値になります。
  • 編集後に StripOffsets が古いまま残った場合。ディレクトリは走査行のストリップがどこにあるかを申告しており、そのタグを更新せずに画像データを書き換えたツールを通すと、ファイルは開き、寸法も正しく報告されるのに、ファイルの間違った場所から帯を描いてきます。絵が横方向のブロック単位で入れ替わっているので見分けはつきます。
  • タグの値がヘッダと重なっている場合。4 バイトを超える値は別の場所に置いてオフセットで参照するので、オフセット表に 1 つずれのある書き手はタグをヘッダ自身に向けてしまえます。ファイルは構造検証を通過し、メタデータはでたらめに読めます。

この形式の現在地

TIFF は届けるためではなく、残すために使う形式です。文書スキャンと保存用イメージングが何十年も前にこれで標準化したのは、1 ファイルに複数ページを収められ、二値スキャンを可逆な CCITT Group 4 で格納でき、他のリーダーを壊さずに機関ごとの目録が必要とする独自メタデータを付けられるからです。プリプレスと印刷は、JPEG では表現できない CMYK・特色・埋め込み ICC プロファイルのために手放しませんでした。写真の世界が残したのは、Adobe の DNG という RAW 形式が TIFF そのものだからです。現代のカメラの RAW ファイルは、すべて変装した TIFF ということになります。いちばん強く手放さなかったのは科学分野で、GeoTIFF は衛星画像や地図データのために座標参照系を追加し、OME-TIFF と BigTIFF は元の設計の 4 ギガバイト上限をはるかに超える顕微鏡スタックを運びます。一方でウェブの形式であったことは一度もありません。表示できるブラウザは存在しません。柔軟さは正直なところ負債でもあって、正しい TIFF は十数種の圧縮と十数種のカラーモデルのどれを使ってもよく、TIFF 対応をうたうソフトウェアの実態は、たいてい作者が出会った 2〜3 種類に対応しているという意味です。

TIFF ファイルをこのサイトで開く

どれもブラウザ内で動きます。ファイルが端末から出ることはありません。

関連する形式

TIFF と混同しやすい形式です。先頭バイトを見比べてください。

形式先頭バイト拡張子
BMP42 4D.bmp
PNG89 50 4E 47 0D 0A.png
JPEGFF D8 FF.jpg

よくある質問

ファイルのマジックナンバーとは何ですか?

ファイル先頭の数バイトで、名前が何であろうとその形式を示すものです。PNG は必ず 89 50 4E 47 で始まり、ZIP は 50 4B 03 04 で始まります。OS もブラウザも file コマンドも、拡張子を信用せずこのバイト列を読みます。だからファイル名を変えても中身の正体は変わりません。

マジックナンバーを自分で確認する方法は?

macOS や Linux なら xxd -l 16 ファイル名 で先頭 16 バイトが表示されます。Windows なら PowerShell で Format-Hex -Path ファイル名 -Count 16 です。あるいはこのサイトのファイル形式判別ツールにドロップすれば、ローカルでバイト列を読んで形式を教えてくれます。アップロードはありません。

2 つの形式が同じマジックナンバーを持つのはなぜ?

一方が他方の上に作られているからです。docx、xlsx、pptx、apk、jar、epub はすべて中身が ZIP アーカイブなので ZIP の署名で始まり、区別するには内部のエントリを見る必要があります。Java の class ファイルと macOS のユニバーサルバイナリはどちらも CA FE BA BE で始まり、直後のフィールドで見分けます。

マジックナンバーがまったくないファイルもある?

あります。XML、HTML、JSON、SVG、CSV といったテキストベースの形式には固定のバイト署名がないため、構造から判別します。先頭の <?xml 宣言、<svg 要素、あるいは { に続く引用符付きのキーなどです。これは確定ではなく推測なので、このリファレンスではそうした形式をプローブ判別として示しています。

マジックナンバーが一致すればそのファイルは安全?

いいえ。わかるのは形式であって、中身が無害かどうかではありません。正規の PDF や docx でも悪意のあるペイロードを含んでいることがあります。特に拡張子とバイト列が食い違うときに真の形式を知るのは有用な第一段階ですが、マルウェアスキャンではありません。

TIFF かもしれないファイルをお持ちですか?ファイル形式判別ツールで調べる — マジックナンバーをローカルで読み取ります。アップロードは一切ありません。またはすべての形式を見る。