ByteScope

HEIF ファイル形式

High Efficiency Image Format。HEIF コンテナの汎用静止画プロファイル。

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

マジックナンバー（ファイル署名）

0x0000000466747970ftypISO-BMFF 'ftyp' box
0x000000086D696631mif1brand 'mif1'

HEIF 形式について

HEIF は HEIC が使うコンテナの汎用静止画プロファイルで、画像シーケンスや補助データも保持できます。ftyp ブランドは mif1 です。このブランドの肝は、何を言っていないかにあります。heic や avif と違って、中の絵をどのコーデックで圧縮したかについて一切主張しません。mif1 ファイルが約束しているのは構造だけです。meta ボックスがあること、画像がアイテムとして入っていること、primary アイテムが指名されていること。コーデックはその後、各アイテムの型と属性から判明します。mif1 がそれ自体メジャーブランドでありながら、ほぼすべての HEIC と AVIF の互換ブランド一覧にも顔を出すのは、そのためです。

ヘッダーの構造（バイト単位）

オフセット長さフィールド意味
04ftyp box sizeファイルタイプボックスのバイト長をビッグエンディアンで表したもので、このフィールド自体を含みます。メジャーブランド 1 つと互換ブランド 2 つなら 24 です。ISO-BMFF ファイルの整数はすべてビッグエンディアンで、2 つの特別なサイズもここでも同じです。1 なら型の後ろに 64 ビット長が続き、0 ならボックスはファイル末尾まで伸びます。
44Box type66 74 79 70。ファイルタイプボックスは先頭に来ることが要求されているので、これがこの形式で唯一確実に固定されたフィールドです。HEIC・AVIF・MP4・MOV・3GP とそのまま共有しているため、これだけではコンテナのファミリーを絞れる以上のことは何も分かりません。
84Major brand静止画または画像コレクションなら 6D 69 66 31。画像シーケンス側の対応物は msf1 で、時間軸のあるコンテンツと、それに伴う別の構造要件を示します。どちらのブランドもコーデック名を出しません。それが HEIF を HEIC や AVIF から分ける、意図的な設計判断です。
124Minor version参考情報で、慣例的に全部ゼロバイトです。構造上の意味はなく、これを根拠にファイルを拒否することはリーダーに許されていません。
16variableCompatible brands1 ブランドあたり 4 バイトで、ボックスの残りを埋めます。mif1 ファイルが実際に何を含んでいるかを教えてくれるのはここで、HEVC アイテムなら heic、AV1 アイテムなら avif、相互運用プロファイルなら miaf が並びます。リーダーはこのリストの中に理解できるブランドがあれば、それを根拠にファイルを開いて構いません。
244Next box size24 バイトの ftyp の後で、次のボックスヘッダが始まる位置です。ファイル全体は各ボックスのサイズを現在位置に足しながら走査します。中央の索引はなく、長さを 1 つ間違えたあとに再同期する手段もありません。
284Next box type通常は 6D 65 74 61、つまり meta で、これがファイルをムービーではなく画像ファイルにしています。実際の仕事をするのはその子ボックスたちです。pitm が primary アイテムを指名し、iinf がアイテムと 4 文字のコーデック型を列挙し、iloc が各アイテムのバイト位置を記録し、iprp が寸法・回転・色情報を結び付けます。

似た形式との見分け方

紛らわしい形式見分け方
HEICオフセット 8 の 4 バイトだけで決まります。68 65 69 63 なら、アイテムが HEVC だと主張しているファイル。6D 69 66 31 なら、構造が HEIF 画像ファイルであることしか主張していません。実際には、メジャーが mif1 で互換ブランドに heic を持つファイルは、メジャーが heic のファイルとまったく同じ HEVC データを抱えています。変換ツールはメジャーブランドだけで分岐せず、両方のリストを読むべきです。
AVIF本当に厄介です。AVIF ファイルは互換ブランドに mif1 を並べるからで、macOS が作った AVIF はオフセット 8 が avif、オフセット 20 が mif1 になります。ftyp ボックス全体を走査して mif1 を探す検出器は、大半の AVIF を HEIF とラベル付けしてしまいます。ファイルが第一に何を名乗っているかを言うのはオフセット 8 のメジャーブランドだけで、実際に使われているコーデックを言うのは meta ボックス内のアイテム型、AV1 なら av01、HEVC なら hvc1 です。
Image sequences静止画のブランドが mif1、シーケンスのブランドが msf1 で、1 バイト違いです。msf1 のファイルは時間軸を持つ画像を抱え、アイテムと並んでトラック構造を持つことも多く、静止画しか想定していないソフトウェアは 1 フレーム目を描いて止まります。どちらも .heif という拡張子で書かれるのが普通なので、拡張子はまったく助けになりません。
MP4オフセット 4 は同一で、オフセット 8 が違います。動画なら isom・mp42・avc1、画像なら mif1 です。構造での判定はトップレベルのボックスが何かで、アイテムを持つ meta ボックスなら絵、trak ボックスを持つ moov ならムービーです。画像シーケンスを運ぶ HEIF は、正当に両方を持ちうる点にも注意してください。

よくある壊れ方

  • リーダーが持っていないコーデック。ブランドがコーデック非依存なので、mif1 ファイルが開けたところで中身をデコードできる保証にはまったくなりません。AV1 アイテムを抱えた HEIF は HEVC しか実装していないソフトウェアで失敗し、その逆も起きます。壊れたファイルのように見えて実体は機能の欠落で、オフセット 16 の互換ブランドを読めば見つかります。
  • 途中切れ。meta ボックスは通常画像データより前にあるので、アイテムの寸法と属性はそのまま残り、それが指しているバイトだけが消えます。リーダーは正しいサイズを報告して何も描かないか、埋め込みサムネイルのアイテムにフォールバックして、原寸で開くまで動いているように見せます。
  • ボックスサイズがペイロードと合っていない場合。走査は長さを足していくだけなので、サイズが 1 つ狂うとパーサは任意のデータをボックスヘッダとして読み、そこで諦めます。エラーメッセージはたまたま着地した 4 バイトの名前を挙げるので、実際の破損場所の近くであることはめったにありません。
  • アイテムの位置がファイルの外を指している場合。iloc ボックスは各アイテムのオフセットと長さを独立に記録するので、雑なツールが組み立てたり編集したりしたファイルは、サムネイルは完璧に読めるのに primary アイテムだけ末尾より先から始まっている、という状態になりえます。結果はプレビューは正しく出るのに開けないファイルです。
  • primary アイテムが宣言されていない場合。pitm ボックスがないと、リーダーは複数のアイテムのどれが絵なのかを推測するしかなく、実装ごとに推測が割れます。写真を出すものもあれば、深度マップやアルファ補助画像を出すものもあります。バイトはすべて正しく、ファイルはただ別のものとして表示されます。

この形式の現在地

HEIF をそれ自体のブランドとして目にするのは、たいていコーデックを決め打ちせずにコンテナだけ使いたいツールの出力で、この上に築かれた 2 つの名前付きプロファイルに比べれば実際に出会う機会はずっと少なめです。本当に重要なのは設計上の位置づけです。HEIC も AVIF も HEIF ファイルであり、今のスマートフォン写真を成り立たせている仕組み、つまり 1 ファイルに複数画像、深度マップ、アルファ補助画像、HDR ゲインマップ、サムネイル、非破壊の編集リスト、バーストのシーケンス、そして再エンコードなしに他のアイテムを切り抜いたり回転したりして作る派生画像は、どちらか一方ではなくここで定義されています。素の mif1 ファイルが実際に登場するのは、画像処理パイプライン内の交換形式や中間形式として、そしてバーストやスタックのように、関連する多数の絵を 1 つに収められること自体が使う理由になる画像コレクションの場面です。配信には向きません。mif1 しか名乗らないファイルを開けるブラウザはありませんし、ウェブに出すものは AVIF・WebP・JPEG のいずれかであるべきです。ブランドは構造についての表明だと考え、中身を知るには互換ブランドとアイテム型を見て、出荷前に変換してください。

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

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

関連する形式

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

形式先頭バイト拡張子
HEIC66 74 79 70.heic
AVIF66 74 79 70.avif
MP466 74 79 70.mp4

よくある質問

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

ファイル先頭の数バイトで、名前が何であろうとその形式を示すものです。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 でも悪意のあるペイロードを含んでいることがあります。特に拡張子とバイト列が食い違うときに真の形式を知るのは有用な第一段階ですが、マルウェアスキャンではありません。

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