HEIF 檔案格式
High Efficiency Image Format，HEIF 容器的通用靜態影像設定檔。
- MIME 類型
- image/heif
- 副檔名
- .heif
- 分類
- 圖片
Magic number（檔案簽章）
| 0x00000004 | 66747970 | ftyp | ISO-BMFF 'ftyp' box |
| 0x00000008 | 6D696631 | mif1 | brand 'mif1' |
關於 HEIF 格式
HEIF 是 HEIC 所用容器的通用靜態影像設定檔，還能存放影像序列與輔助資料。它的 'ftyp' 品牌識別是 'mif1'。這個品牌識別的重點在它「沒說」的部分：跟 heic 或 avif 不同，它完全不主張裡面的圖是用哪種編碼壓的。mif1 檔案承諾的是結構 — 有一個 meta box、影像以 item 的形式存在、而且有指名一個主要 item — 至於編碼是什麼，要之後從每個 item 的類型與屬性去發現。這也是為什麼 mif1 除了自己就是個主要品牌識別之外，還會出現在幾乎每個 HEIC 和 AVIF 的相容品牌識別清單裡。
檔頭結構，一個位元組一個位元組看
| 位移 | 長度 | 欄位 | 意義 |
|---|---|---|---|
| 0 | 4 | ftyp box size | 檔案類型 box 的位元組長度，大端序，含這個欄位本身；一個主要品牌識別加兩個相容品牌識別是二十四。ISO-BMFF 檔案裡每個整數都是大端序，那兩個特殊大小在這裡也一樣適用：1 表示類型後面會有 64 位元的長度，0 表示這個 box 一路延伸到檔案結尾。 |
| 4 | 4 | Box type | 66 74 79 70。規格要求檔案類型 box 必須排第一，所以這是這個格式裡唯一位置可靠固定的欄位。它和 HEIC、AVIF、MP4、MOV、3GP 一字不差地共用，所以光靠它只能把檔案縮小到「某個容器家族」，再多就沒有了。 |
| 8 | 4 | Major brand | 6D 69 66 31 代表靜態影像或影像集合。對應影像序列的是 msf1，代表帶時間軸的內容，結構要求也是另一套。兩個品牌識別都沒有指名編碼，而這正是刻意的設計選擇，也是 HEIF 跟 HEIC、AVIF 分家的地方。 |
| 12 | 4 | Minor version | 純資訊用，慣例上全部是零位元組。它沒有任何結構意義，讀取端也不准拿它當作拒收檔案的理由。 |
| 16 | variable | Compatible brands | 每個品牌識別四個位元組，把 box 剩下的空間填滿。mif1 檔案就是在這裡告訴你它實際裝了什麼 — heic 代表 HEVC item，avif 代表 AV1 item，miaf 代表互通性設定檔 — 而讀取端只要看得懂清單裡任何一個品牌識別，就可以打開檔案。 |
| 24 | 4 | Next box size | 24 位元組的 ftyp 之後，下一個 box 標頭從這裡開始。整個檔案就是靠把每個 box 的大小加到目前位置來走訪的；沒有中央索引，長度一旦錯了也沒有辦法重新同步。 |
| 28 | 4 | Next box type | 通常是 6D 65 74 61 — meta — 有它，這個檔案才是影像檔而不是影片。真正做事的是它底下的子 box：pitm 指名主要 item，iinf 列出所有 item 和它們的四字元編碼類型，iloc 記錄每一個 item 的位元組落在哪裡，iprp 則掛上尺寸、旋轉與色彩資訊。 |
怎麼跟長得像的格式分開
| 容易搞混的 | 怎麼分 |
|---|---|
| HEIC | 位移 8 那四個位元組，沒有別的。68 65 69 63 是一個主張自己的 item 是 HEVC 的檔案；6D 69 66 31 只主張這個結構是 HEIF 影像檔。實務上，主要品牌識別是 mif1、相容清單裡有 heic 的檔案，裝的 HEVC 資料跟主要品牌識別是 heic 的完全一樣，所以轉檔工具應該兩份清單都讀，不要只憑主要品牌識別分支。 |
| AVIF | 這件事真的很麻煩，因為 AVIF 檔案會把 mif1 列進自己的相容品牌識別 — macOS 產出的 AVIF 位移 8 是 avif、位移 20 是 mif1。掃描整個 ftyp box 找 mif1 的偵測器，會把大部分 AVIF 標成 HEIF。只有位移 8 的主要品牌識別能說明這個檔案主打的是哪種格式，而 meta box 裡的 item 類型才說明實際用了哪種編碼：av01 是 AV1，hvc1 是 HEVC。 |
| Image sequences | 靜態影像的品牌識別是 mif1，序列的是 msf1，差一個位元組。msf1 檔案裝的是帶時間軸的影像，而且常常在 item 之外還有一套軌結構，只為靜態影像而寫的軟體會畫出第一格然後停住。副檔名一點忙都幫不上，因為兩種通常都寫成 .heif。 |
| MP4 | 位移 4 一模一樣，位移 8 才不同：影片是 isom、mp42 或 avc1，影像是 mif1。結構性的判別法是看最上層有哪些 box — 帶 item 的 meta box 代表這是一張圖，moov 加 trak box 代表這是一部影片 — 而一個 HEIF 在裝影像序列時，合法地可以兩者都有。 |
常見的壞法
- 讀取端沒有那個編碼。因為這個品牌識別不綁編碼，成功打開一個 mif1 檔案完全不代表解得開裡面的內容：裝著 AV1 item 的 HEIF 在只實作 HEVC 的軟體上會失敗，反過來也一樣。這種失敗看起來像檔案壞了，其實是能力缺口，讀一下位移 16 的相容品牌識別就找得出來。
- 截斷。meta box 通常排在影像資料前面，所以 item 的尺寸與屬性完好如初，它們指向的位元組卻不見了。讀取端會報出正確的尺寸然後什麼都畫不出來，或是退回去用內嵌的縮圖 item，看起來一切正常，直到你用原始解析度打開它為止。
- box 大小和它的酬載對不起來。走訪就只是不斷把長度加上去，所以一個大小錯了，剖析器就會把任意資料當成 box 標頭讀，然後放棄。錯誤訊息會指名它剛好落到的那四個位元組，而那裡通常離真正的損壞處很遠。
- item 位置指到檔案外面。iloc box 是各自獨立記錄每個 item 的位移與長度的，所以被馬虎的工具組出來或編輯過的檔案，可能列出一個起點超出檔案結尾的主要 item，而它的縮圖卻仍然讀得好好的。結果就是一個預覽正常、打開卻打不開的檔案。
- 從來沒有宣告主要 item。少了 pitm box，讀取端只能自己猜好幾個 item 裡哪一個才是那張圖，而不同的實作猜法不同 — 一個秀出照片，另一個秀出深度圖或 alpha 輔助影像。每個位元組都合法，檔案就只是顯示成別的東西。
這個格式現在還在用嗎
HEIF 這個品牌識別本身，多半是在某個工具想要這個容器、卻不想承諾用哪種編碼時才會遇到，實務上比建立在它之上的那兩種具名設定檔少見得多。它真正的意義是架構性的：HEIC 和 AVIF 都是 HEIF 檔案，而讓現代手機攝影運作起來的那整套機制 — 一個檔案裡多張影像、深度圖、alpha 輔助影像、HDR 增益圖、縮圖、非破壞性編輯清單、連拍序列，以及靠裁切或旋轉另一個 item、完全不必重新編碼就衍生出來的影像 — 都定義在這裡，不在那兩者裡面。單純的 mif1 檔案真正會出現的地方，是影像處理流程裡的交換或中間格式，以及連拍、堆疊這類影像集合 — 那種場合下，容器裝得下多張相關影像正是使用它的全部理由。拿它來交付則是錯的選擇：只宣稱 mif1 的檔案沒有瀏覽器打得開，要放到網路上就該用 AVIF、WebP 或 JPEG。把這個品牌識別當成一句關於結構的宣告，想知道裡面實際裝了什麼就去看相容品牌識別和 item 類型，出貨前先轉檔。
在這個站上打開 HEIF 檔
這些全部在你的瀏覽器裡跑，檔案不會離開你的電腦。
相關格式
容易和 HEIF 搞混的格式，可以比對它們的開頭位元組。