速查 › 封裝格式

BIGF 封裝格式

遊戲裡幾乎所有資源都裝在 .big 檔裡 —— 本站測試機的 data\ 底下，2026-09-05 數是 400 個（檔頭真的是 BIGF 的 383 個）；剛安裝好的原版是 224 個（BIGF 207 個；多出來的是後來裝的球場、大頭照與備份包）。 它是 EA 自家的封裝格式，結構出乎意料地簡單：一個 16 bytes 檔頭、一份目錄、然後是資料。 但寫回去有一個會毀檔的陷阱，本頁最後一節專講這件事。

檔頭：16 bytes

+0x00  4 bytes   magic「BIGF」
+0x04  4 bytes   檔案總大小      ← 多數是 little-endian，但有例外，見下
+0x08  4 bytes   項目數量        big-endian
+0x0C  4 bytes   目錄區結束位置    big-endian ← 不是第一筆資料的位置,見下

目錄：每個項目一筆

接在檔頭後面，每筆長度不固定（因為檔名長度不一）：

4 bytes   資料位置(offset)    big-endian
4 bytes   資料長度(size)      big-endian
N bytes   檔名                latin-1,以 \0 結尾,沒有長度前綴

目錄結束後有一段 8 bytes 的尾標（L234 + 4 bytes 旗標）， 之後才是實際資料區。（資料區沒有固定的對齊規則。原版 207 個封裝檔裡，第一筆資料落在 128 倍數上的只有 8 個 —— misc.big 剛好是其中之一。不要拿它推論通則。）

用 Python 讀目錄

# 完整可用版本見任一教學附的腳本,這裡是最小示範
import struct

data = open('ingame.big', 'rb').read()
assert data[:4] == b'BIGF'
count = int.from_bytes(data[8:12], 'big')     # 項目數:big-endian
pos = 16
for _ in range(count):
    offset, size = struct.unpack('>II', data[pos:pos+8])
    pos += 8
    end = data.find(b'\x00', pos)             # 檔名到 \0 為止
    name = data[pos:end].decode('latin-1')
    pos = end + 1
    print(f'{name:<32} {offset:>10} {size:>10}')

「孤兒資料」是什麼，以及本站怎麼算它

封裝檔裡常常有目錄沒有指向的位元組。本站叫它孤兒資料。 算法只有一個定義：

孤兒 ＝ 檔案總長 − 檔頭 16 − 目錄長度 − 目錄指到的長度總和

關鍵是那個「減目錄長度」。 目錄本身也是沒有人指向它的位元組，但它不是孤兒 —— 它是這個格式必要的一部分。少減它會多算一點點。

用同一個定義重算一次

下面全部是用上面那個定義量出來的，換算方式一致，可以互相比較：

同一個檔名，兩份檔案，比例差 2,200 倍。 （92.590% 除以 0.04234% 是 2,187；上表那一欄四捨五入成 0.04%，拿捨入後的數字去除會多算成 2,300。） 所以站上任何一個孤兒數字，都要先問量的是哪一份 —— 「92.6%」講的是本站測試機那一份，不是這個格式的性質。 剛出貨的原版幾乎沒有孤兒（中位數 0.00%）， 孤兒是後來一次次用安全改法疊出來的。

⚠️ 站上另一處寫「剛安裝好的原版孤兒只有 0.9%」， 那句用的是舊算法（把檔頭與目錄算進去）量 ingame.big。 換成現在的定義是 0.04%。已一併訂正。

實測數據

讀寫 round-trip 測試（讀進來原樣寫回，比對是否位元組相同）：294 / 294 全數通過。 另做過注入測試：frontend.big 196 項加一項變 197，重新開啟驗證檔名與內容皆正確。

⚠ 最重要的一節：寫回去的方式

讀取很單純，寫回才是會毀檔的地方。直覺做法是「把所有項目讀出來、改完再重新打包」—— 這會出事。

正確做法：接到檔尾

不要重排任何東西，只做三件事：

• 把新的資料接在檔案最後面
• 改目錄中該項目的 8 個位元組（新的位置與長度）
• 改檔頭的 4 個位元組（檔案總大小，先讀一次確認是哪一種位元組順序，見下方訂正卡）

原始資料區一個位元組都不動。檔案會變大一點，但什麼都不會遺失。

data[field:field+8] = struct.pack('>II', new_offset, len(payload))  # 目錄:BE
data[4:8]          = struct.pack('<I', len(data))                  # 檔頭:LE

每個前端封裝檔的頭尾各有一個 1 位元組的標記（2026-08-28 量的）

把剛安裝好的原版 data\frontend\ 底下每個裝圖片的封裝檔攤開來數， 會看到一件一開始像是壞掉的事：目錄裡有一個名字出現兩次。

17 個封裝檔，17 個都是這樣，零例外，而且官方英文版與官方繁體中文版完全相同。

封裝檔裡面還有封裝檔

有兩個檔解開之後，裡面裝的是另一個封裝檔：

兩個都是外層只裝一個項目，那個項目是 QFS 壓縮的，解開就是一個完整的 BIGF。 外層檔名結尾是 z，內層是原本的名字 —— initstaz 裝 initstay、 initprgz 裝 initpurge。 為什麼要這樣包，檔案裡沒有寫

initstay.big 的前幾個項目
models/bat.o          12,768
models/brknbat.o      17,536
models/ball.o          5,680
models/hibody.ord    786,336
misc/…

怎麼自己看一遍

python mvp_fel_toolkit.py "你的遊戲資料夾" --big data\initstaz.big --entries

會印出：

封裝檔內共 1 個項目:

  名稱                                             大小  內容是什麼(看檔頭認的)
  ----------------------------------------------------------------------------
  initstay.big                            1,212,663  QFS → BIGF(裡面又有 34 個項目)
  ----------------------------------------------------------------------------
  合計 1,212,663 bytes

--entries 跟 --list 的差別： --list 只看版面檔，--entries 每個項目都列， 而且會解開來看檔頭認出它是什麼。 工具在介面萬用工具那一課。

其他變體

• BIG4 —— EA 其他遊戲用的 little-endian 變體。MVP 2005 一個都沒有：剛安裝好的原版整套 1,191 個檔全部掃過檔頭，BIG4 命中 0 次；本站測試機那邊也是整棵資料夾逐檔掃（2026-09-05 掃到 4,974 個檔，這個數字會隨你自己放進去的模組變動），一樣 0 次。看到別的教學提到 BIG4，那是別的遊戲。
• *hdr.big —— 名字看起來像，但要分兩種。原版 13 個 *hdr.big 裡，8 個根本不是 BIGF（bdcsthdr、chanthdr、hsfxhdr、plchthdr、rallyhdr、pahdr、pbphdr、stdmhdr），是另一種 EA 格式；另外 5 個是貨真價實的 BIGF 封裝檔（名字只有三個 —— pnamehdr、tnamehdr、stdnmhdr，前兩個各在兩個資料夾裡出現一次，裡面裝的是 .hdr 項目）。一樣是那句老話：看檔頭，不要看檔名。

📌 重點整理

• 一句話 .big 是 EA 自家的封裝格式，一個 16 位元組檔頭加一份目錄就讀得完，真正會毀檔的是寫回去，只能把新資料接到檔尾，整包重新打包會靜靜地丟掉東西。
• 同一個檔頭混著兩種位元組順序 總大小是 little-endian，項目數與目錄結束位置是 big-endian。misc.big 的第 4 個位元組起是 7E 03 00 00，當 big-endian 讀是 2,114,125,824（2 GB，明顯錯誤），當 little-endian 讀是 894，正是該檔真實大小。
• 最重要的一個數字 測試機的 ingame.big 有 2,665,562 個位元組，47 個項目加起來只有 195,999，剩下 2,468,068（92.59%）目錄根本不指向。用重新打包的方式存檔，實測會變成 198,071 個位元組，47 個項目一個不少、內容檢查全過、不會有任何錯誤訊息。正確做法只有三件事：資料接到檔尾、改目錄那 8 個位元組、改檔頭那 4 個位元組。
• 訂正一：+0x0C 不是「資料起始位置」。它是目錄區結束之後的位置（檔頭 ＋ 目錄 ＋ 8 個位元組尾標），原版 207 個封裝檔 207／207 全中；但它不等於第一筆資料真正的位置，只有 18／207 相同，其餘中間隔著填充，最多差 119。要找資料請讀目錄裡那一筆自己的 offset。
• 訂正二：little-endian 不是通則。這台機器當時 295 個封裝檔裡 288 個 little-endian、7 個 big-endian、0 個兩種都對不上（2026-09-05 那個資料夾又被動過之後重量是 384 個裡 374／10／0，結論沒變），而那 7 個的時間戳全部落在 2012 年以後；出廠期那 146 個檔一個 big-endian 都沒有（2026-09-05 重跑是出廠期 175 個、2012 年以後 199／10，一樣掛零）。同一台機器上留著同一個檔名的 dodgnite.big，封存原廠球場那份是 2004-12-24、little-endian，遊戲現在用的球場模組那份是 2013-10-19、big-endian，同樣 88 個項目只有這一欄不同。寫回去之前先讀一次，原檔是哪一種就照哪一種寫。
• 訂正三：本站自己混用過兩種孤兒算法。同一個檔出現過 2,468,068 與 2,469,563 兩個數字，差的 1,495 正好是 16 ＋ 1,479（檔頭與目錄算不算進孤兒），已統一成「不算」那個定義；站上另一處寫的原版孤兒 0.9% 也換算成 0.04%。另外原本寫的「撈得出 156 種舊版畫面代號、現行只有一個 HUDLEFT」：156 只是口徑不同（整片沒被指向的位元組一起掃），讀得出整段文字的那 13 個區塊是 143 種、每一種現行版本都還在，錯的是「舊版」兩個字；而 fes_hudleft.fel 有 26 個。
• 前端封裝檔頭尾各有一個 1 位元組的書擋 目錄第一筆與最後一筆同名、各 1 個位元組，最後那筆的位置正好等於檔長減一，17 個封裝檔零例外，官方英文版與繁中版相同。拿檔名當鍵建字典會靜靜地少一筆，本站量 bkgnds.big 先得到 106、跟先前記的 107 差一個，追下去才發現。球場那 87 個封裝檔沒有這個結構，所以它是前端的慣例不是格式規定。
• 本站沒驗的 initstaz／initprgz 這兩個「封裝檔裡面還有封裝檔」為什麼要這樣包，檔案裡沒有寫；而「重建工具得先把資料夾造出來，名稱才對得起來」是推論，本站量到的只有內層 45 個項目名稱全部帶路徑這個事實，某個特定工具怎麼處理並沒有測。

接下來

• QFS / RefPack 壓縮 —— 封裝檔裡的項目常常還包一層壓縮
• FEL 版面檔 —— 解開壓縮後的介面腳本
• 實戰：換賽程年份 —— 用到本頁全部知識的完整流程