速查 › 大頭照 portrait.big

大頭照 portrait.big

名單畫面上每位球員的那張照片，全部裝在一個 253.6 MB 的封裝檔裡。它用的圖片格式叫 FSH，是 EA 自家的容器 —— 結構單純到可以用加法驗證你有沒有讀懂。

先說清楚這頁的數字是從哪一份遊戲量的

本頁的項目數、檔案數、覆蓋率，量的是一台裝過台灣模組的遊戲。剛安裝好的原版數字小很多 —— 例如臉皮 504 對 894、大頭照 1,487 對 6,638、語音號碼 1,673 對 4,343。

容器結構兩邊一樣（BIGF 目錄、QFS 壓縮、SHPI、後面那 96 個位元組的附掛區塊），那是遊戲程式決定的；會變的是「有幾個」，還有像素格式 —— 剛安裝好的原版 2,391 張圖全部是 0x7D（ARGB32）128×128，這台機器的 7,544 個項目裡則有 5,250 張是 0x61（DXT3）256×256。完整對照見原版與這台機器差在哪。

先看規模

項目	數字	備註
檔案大小	253.6 MB	`data/frontend/portrait.big`
目錄項目數	7,544 筆	檔名全部是 `.fsh`；其中 2 筆只有 1 個位元組不是圖，真正的圖是 7,542 張
目錄涵蓋率	100.0%	孤兒 0 bytes。跟 ingame.big 的 7.4% 完全不同
壓縮	7,542 個	除了 2 個異常項，其餘全部是 QFS
每張圖的解壓後大小	65,680 bytes	絕大多數一模一樣，原因見下

⚠️ 2026-09-05 訂正：孤兒那一格原本寫「只有 0.1 MB」。那 128,266 bytes 就是檔頭 16 加上目錄 128,250 —— 目錄本身不是孤兒。照本站統一的定義算，這台機器的 portrait.big 孤兒是 0 bytes，一個位元組都沒有。跟臉皮那頁 2026-08-28 訂正的是同一件事，本頁當時漏掉了。

上面每個數字都是把 portrait.big 現場解開數出來的，不是引用他人資料。

FSH 檔頭：16 bytes，看得懂

把任何一張大頭照解壓後，開頭長這樣：

53 48 50 49  90 00 01 00  01 00 00 00  47 33 35 37
│            │            │            └ 目錄代號 "G357"
│            │            └───────────── 這個檔裡有幾張圖 = 1
│            └────────────────────────── 整個檔多大 = 65,680
└─────────────────────────────────────── "SHPI"

又一個可以自己驗算的格式

第 5 到 8 個位元組寫的「整個檔多大」，跟你手上這個檔的實際長度應該完全相同。

本站把 7,542 張全部算過：7,538 張完全相符。剩下 4 張多出 4 或 8 個位元組（1907、5566、5816、5826），是檔尾補齊用的。

跟音訊索引的加總法一樣：對不上就是你哪裡讀錯了。

兩種格式，大小卻一模一樣

檔頭後面接著影像記錄，開頭一個位元組是格式代號。7,542 張圖只用到兩種：

我們改過這一段：原版只用一種

下面這張表量的是本站測試機。拿剛安裝好的原版重量： 1,487 張大頭照 100% 都是 0x7D 128×128，一張 0x61 都沒有。

也就是說下面表格裡那 5,250 張 0x61 256×256，用的是 EA 在這個倉庫裡沒有用過的格式與尺寸。 是誰換的、什麼時候換的，本站不知道。未解

同一件事也發生在臉皮那邊，方向一樣。完整對照見原版與這台機器差在哪。

代號	張數	尺寸	像素資料	每個像素
0x61	5,250	256 × 256	65,536 bytes	1 byte
0x7D	2,292	128 × 128	65,536 bytes	4 bytes

兩邊都剛好 65,536 bytes

這不是巧合可以解釋的數字。同樣一塊 64 KB：

想要四倍解析度（256×256）→ 每個像素只能用 1 個位元組
想要完整色彩（4 個位元組 = 紅綠藍加透明度）→ 解析度只能到 128×128

而且代號與尺寸完全一一對應：5,250 張 0x61 全部是 256×256， 2,292 張 0x7D 全部是 128×128，沒有任何一張交叉。

這裡要誠實

0x61 那 5,250 張一個位元組只能表示 256 種顏色，照理說檔案裡要附一份調色盤。但本站把整個檔翻過，找不到調色盤。

「1 個位元組一個像素、又不需要調色盤」這件事，跟顯示卡用的區塊壓縮貼圖格式的行為一致。已解 0x61 的像素編碼已經解開了 —— 每 4×4 像素一個 16 位元組的區塊，前 8 個位元組是透明度。算式與驗證見圖片的像素怎麼排。

能確定的是：想自己寫轉檔工具的話，0x7D（128×128、每像素 4 bytes）是唯一一個結構已經完全清楚的格式。

EA 在每一張圖裡留了一句話

影像資料結束後，每個檔案還剩 96 個位元組。SHPI 目錄沒有登記這一段，但它確實存在，而且內容是可以讀的文字：

69 50 00 00 40 00 10 00 ...
EAGL64 metal bin attachment for runtime texture management

檢查	結果
`portrait.big` 裡含這段文字的檔案	7,539 / 7,542
`models.big` 裡含這段文字的檔案	2,332 / 2,332

兩個封裝檔、將近一萬個圖片檔，只有三個例外。

⭐ 2026-08-28：那 96 個位元組不是「沒人登記的殘料」，是格式的正規第二段

本站原本只寫「目錄沒有登記這一段」。那句話字面上對（SHPI 目錄確實只登記圖片），但容易讓人以為它是垃圾資料。它其實是 FSH 格式規定的附掛區塊，而且是圖片記錄自己的長度欄位指過去的。

順著那個長度欄位一路走，剛安裝好的原版 portrait.big 2,391 張圖：

鏈	張數	圖片之後合計
`0x7D` 圖片 → `0x69` 附掛文字 80 bytes → `0x70` 結束	2,389	80 + 16 = 96
同上，中間多一塊 `0x7C` 256 bytes	2	352

0x69 那 80 個位元組就是上面那句 EAGL64 …； 0x70 是一個長度為 0 的結束標記，佔 16 個位元組的表頭。 80 + 16 = 96，正好是本站原本量到的數字。

這些代號在一份 2002 年的 FSH 工具說明書裡有名字： 0x6F 與 0x69／0x70 是附掛文字、 0x2A 是 32 位元調色盤（見圖片的像素怎麼排，本站就是靠這條把 0x7B 的調色盤找出來的）。

未解那 2 張多出來的 0x7C（256 bytes，portrait.big 裡只有 2653.fsh 與 2663.fsh）不在那份說明書的清單裡，內容看起來是一串 32 位元整數。本站不知道那是什麼。

⚠️ 上面那個「只有」只算 portrait.big 裡面。 0x7C 不是這個封裝檔專有的：data\igshapes\igcrsr.fsh 也帶著一塊，但長度是 576 不是 256。三份剛安裝好的原版與本站測試機量到的鏈完全一樣： 0x7D → 0x69（80）→ 0x7C（576）→ 0x70（16）。同一個資料夾裡那份 igcrsr.fsh.bak 則是 0x7D → 0x7C → 0x70，少了 0x69 那塊 —— 這也順便證明了下面那句：兩塊是各自獨立的東西。

⚠️ 像素怎麼排那頁一度把這條筆記整條撤回，說「代號其實是 0x69、長度 80、而且每張圖都有」。撤回錯了，那頁已經改回來。 0x69／80 bytes 確實每張都有，但它跟 0x7C 是兩塊不同的東西： 2026-08-29 拿三份剛安裝好的原版（英文版、中文版、PK 版）逐項走過附掛鏈，各 2,391 張圖都是 2,389 張沒有、只有 2653.fsh 與 2663.fsh 這 2 張有，三份完全一致。那頁掃不到是因為量的是測試機，測試機上這兩張已經被換過（檔案大小與 md5 都跟原版不同），換進去的那一份沒有帶著 0x7C。

我們改過這一段：那三個例外是怎麼回事

這頁上線時這裡寫的是「沒有一個例外」，數字寫成 7,542 / 7,542。重新解過一次，實際是 7,539 / 7,542。

不含那句話的三個是 4174.fsh、4215.fsh、4901.fsh，它們寫的是 EAGL64 mel bin attachment for runtime texture management —— metal 少了 ta 兩個字母。

光看長度抓不出來。少掉的兩個字母後面補了一組 CRLF（0D 0A），所以那一段仍然是 96 個位元組、整個檔仍然是 65,680 個位元組。這也是為什麼原本沒被發現。

後來查出來這不是 EA 的錯字。那三個檔在剛安裝好的原版裡根本不存在 ——原版整套安裝的 6,392 個帶這句話的圖檔，全部是 metal，一個 mel 都沒有。

⚠️ 2026-08-25 訂正：這個數字原本寫 6,370，少算了 22 個。原因是本站當時的掃描只走封裝檔裡面，漏掉 22 個沒有裝進封裝檔、自己就是圖檔的檔案。（2026-09-05 訂正：這裡原本把那 22 個全寫成 data\misc\textures\ 底下的，實際是那個資料夾 18 個、data\igshapes\ 底下 3 個，再加上 data\frontend\feonlyln.big —— 它名字叫 .big，裡面卻不是封裝檔而是一張 SHPI 圖片。合計 22 個，總數 6,392 不變。）結論不受影響（那些也全部是 metal），但「整套安裝」這四個字當時沒做到。

對照組：同一套查法在原版裡查得到 2118.fsh、0502.fsh、a2653.fsh，所以不是查法失靈。三份原版安裝(英文、官方繁中、光碟那份)的 portrait.big 逐位元組完全相同，三份都沒有這三個檔。

是哪一次改動造成的，本站不知道。那組 CRLF 的來由同樣沒有證據。未解

站上原本把 SSH／TTX 也當成 EA 的錯字，那兩個同樣被原版推翻了。目前確認是 EA 自己留下的只剩 iamge。

EAGL 這個代號不只出現在圖片裡。實測 anims.big（動畫檔）內含 486 處 EAGL 字樣，其中包括 EAGL_TOOLLIB_VERSION 這種一看就是工具鏈版本記號的字串。推測看起來是 EA 內部一整套繪圖／工具函式庫的名字，但本站沒有查證它的正式全名。

還有一句更好玩的

FSH 檔頭往後數幾個位元組，藏著 Buy ERTS 這四個字。 7,542 張大頭照，每一張都有。

ERTS 是 Electronic Arts 當年在那斯達克的股票代號。推測這看起來是工程師留的玩笑，但本站沒有查證出處。

檔名怎麼對到球員

命名型態	數量	說明	證據
0000.fsh ～ 9999.fsh	6,638	四位數編號	已解對到球員資料檔的 `playerattrib_audioid`
st00.fsh ～ st63.fsh	64	另一組序列	未確認全部是 128×128
aada.fsh 這類四個字母	840	四個小寫字母的編碼	實測從 `aada` 到 `ogdh`；已解見下方「840 這個數字不是巧合」
a2653.fsh	2	頭尾各一的 1 位元組項目（原版 17 個封裝檔都有）	實測見下方「一個異常項」

6,638 ＋ 840 ＋ 64 ＋ 2 ＝ 7,544，正好是全部項目，沒有漏掉的類型。

想換某一位球員的照片：現在做得到了

「哪個編號屬於哪位球員」已經解開了。 球員資料檔的 playerattrib_audioid 就是這個四位數（本站測試機排在第 16 欄，剛安裝好的原版是第 17 欄，欄號會因名冊而異），同一個號碼同時決定大頭照與播報語音，詳見兩套球員編號。

✓ 補上了本頁原本寫著「真正卡住的不是哪個編號，是把圖壓縮回區塊格式那一半沒有做」。那一半做完了：作法是把解碼的每一步倒過來寫，再拿遊戲裡現成的 20 張圖解出來、壓回去、跟原圖比對，看得見的像素中位數 99.32% 完全相同，透明度零誤差。逐步流程見換球員大頭照那一課。

⚠️ 本頁上線時寫「本站沒有解出編號與球員的對應關係」，那是後來被推翻的。舊說法保留在這裡當紀錄 —— 這一頁前後被自己推翻兩次，兩次都保留原文。

我們查過但走不通的一條路

球員資料檔 attrib.dat 有一欄叫 playerattrib_photo（本站測試機第 17 欄，原版第 18 欄），名字看起來就是答案。

實測後不是：本站測試機上它只有 0、1、2 三種值（198 / 2,908 / 141 位球員），是旗標不是編號，對不到 portrait.big 那 6,638 個四位數檔名。

不過同一張表裡的playerattrib_face 這一欄是通的 —— 它指向 3D 臉皮，命中率 99.9%，詳見模型與臉皮那頁。而 playerattrib_audioid 指向大頭照與播報語音（兩套球員編號）。兩條線現在都通了。

那個「異常項」其實是 EA 的封裝慣例

掃描時發現 a2653.fsh 這個名字在目錄裡出現兩次，而且兩筆的資料長度都只有 1 個位元組 —— 不可能是一張圖。

我們改過這一段

這裡原本把它當成「這份檔案被動過」的痕跡。 拿剛安裝好的原版一掃，它是 EA 自己的做法。

原版整套安裝的封裝檔裡有 17 個是同樣的結構，而且下面四個條件全部成立、零例外：

⚠️ 2026-08-25 訂正：原本寫「224 個封裝檔」。data\ 底下副檔名是 .big 的檔確實有 224 個，但其中只有 207 個真的是 BIGF 封裝檔（8 個開頭是 SCHl 音訊容器、1 個是 SHPI 圖片、8 個沒有可辨識的開頭）。這 17 個是從那 207 個裡數出來的。

同一個名字在目錄裡出現剛好兩次
兩筆的長度都不超過 3 個位元組
第一筆是目錄裡 offset 最小的那一項
第二筆的 offset ＋長度剛好等於整個檔案的長度

換句話說，這兩筆把資料區從頭尾夾起來。那 17 個檔是 awards、bkgnds、bpattrac、bpitems、 bppromos、bpsetup、bpticket、bpupgrad、 bpvendor、coopplyr、coopstad、coopteam、 coopunis、fields、portrait、stadiums、 uniforms。

它是做什麼用的，本站不知道。 只記錄這個結構在原版就存在，而且在 17 個檔裡形狀完全一致。未解

「絕不整包重新打包」那條鐵律仍然成立，但理由要換一個： 不是因為檔案裡有可疑的殘留，而是因為你不知道自己會弄掉什麼 —— 像這種夾在頭尾的 1 位元組項目，重新打包很容易就跟著不見。

每一張圖裡都藏著同一句話

把任何一張大頭照解開，看它的檔頭：

2118.fsh 解開後的前 32 個位元組
偏移  0   SHPI          ← 這是一個圖片倉庫
偏移  4   檔案長度
偏移  8   圖片數（1）
偏移 12   G357          ← 目錄代號
偏移 16   目錄：一張圖 8 個位元組
偏移 24   Buy ERTS      ← 這裡
偏移 32   第一張圖的資料

目錄結束在偏移 24，第一張圖從偏移 32 開始。中間那 8 個位元組，剛好就是 Buy ERTS 這八個字元。

剛安裝好的原版 2,391 張，一張不差

本站把剛安裝好的原版 portrait.big 裡全部 2,391 個圖片倉庫解開，逐一檢查目錄與第一張圖之間那段空隙（本頁開頭那台裝過模組的機器是 7,542 個，同樣一個例外都沒有）：

空隙的內容	幾次
Buy ERTS	2,391
其他任何東西	0

量法：解開每一個項目 → 確認開頭是 SHPI → 目錄結束位置 = 16 + 圖片數 × 8 → 跟第一張圖的偏移之間那一段，整段取出來比。

它不是只有大頭照才有

⚠️ 下面這張表量的是剛安裝好的原版（英文版），不是本頁開頭那台裝過模組的機器。同一套數法在測試機上是 portrait.big 7,542、models.big 1,061、 logos.big 154、feonly.big 12、igonly.big 6、fonts.big 8；只有 initstaz.big、ingame.big、frontend.big 這三個跟原版一樣。

封裝檔	出現次數
frontend\portrait.big	2,391
models.big	671
frontend\logos.big	128
frontend\feonly.big	8
frontend\igonly.big	3
fonts\fonts.big	2
initstaz.big	2
frontend\ingame.big	0
frontend\frontend.big	0

⚠️ 這是直接在封裝檔上數字串的結果，所以只數得到沒有壓縮的那些。原版 models.big 的 2,671 個項目全部是 QFS 壓縮的（測試機那份是 4,211 個，一樣全部壓縮），那 671 次是壓縮後恰好還看得見的殘影，不是「models.big 只有 671 張圖有」。要精確的數字得逐一解壓 —— 本站只在 portrait.big 做了這件事。未做

那句話是什麼意思

本站量得到的只有「那八個位元組就是這串字」。 它為什麼在那裡、是誰放的、是不是刻意的，檔案裡沒有寫。未解

一個站外的背景知識（不是本站量到的）： ERTS 是 Electronic Arts 當年在那斯達克的股票代號。本站把這件事寫在這裡當脈絡，但不主張那句話的用途 —— 它可能是簽名、可能是對齊用的填充剛好被填了字、也可能是別的。

能確定的是：那八個位元組在每一張大頭照裡，躺在你硬碟上超過二十年了。

840 這個數字不是巧合

那 840 個四字母檔名（aada.fsh 到 ogdh.fsh） 不是隨便取的，是一張完整的網格。

把每一位的字母集合列出來：

第幾碼	用到哪些字母	幾種
第 1 碼	a b c d e f g h i j k l m n o	15
第 2 碼	a b c d e f g	7
第 3 碼	d	1 固定不變
第 4 碼	a b c d e f g h	8

15 × 7 × 1 × 8 = 840

把所有可能的組合列出來跟實際檔名比對： 缺 0 個、多 0 個、重複 0 個。 而且每一個首字母底下剛好 56 個檔，一個不差。

三個軸各是什麼

拿這三個數字去對球員資料檔的欄位：

這一碼	幾種	對到哪一欄	那一欄幾種
第 1 碼	15	罐頭臉（901–915）	15 ✅
第 2 碼	7	髮色	宣告 7 種實際用到 6 種
第 4 碼	8	鬍子	8 ✅

三個軸全部精準對上。

⚠️ 2026-08-26 訂正：這裡原本寫「兩個軸精準對上，第三個對上『宣告的種類數』但不是『實際用到的』」。那是拿本站測試機量的 —— 台灣名冊只用到 6 種髮色。 剛安裝好的原版把 7 種都用滿了（0 到 6），所以第 2 碼跟髮色是完全對上的。

所以這 840 張是拼出來的通用大頭照 —— 沒有專屬照片的球員，遊戲用「罐頭臉 × 髮色 × 鬍子」組出一個檔名去拿圖。

原本三件還沒解，現在剩兩件

一、第 3 碼為什麼固定是 d，本站不知道。它看起來是一個「只有一種選項」的軸。未解
二、「第 1 碼的 a 就是 901」這個對應順序是推測。種類數對得上，但本站沒有解圖比對確認順序。推測
三、~~髮色是 7 還是 6~~ —— 2026-08-26 解開了：原版的髮色實際用滿 7 種，跟檔名軸一致。原本會看到 6 種，是因為量的是台灣名冊。已解

模組有先後順序：一批 2010 年的大頭照包實測

裝模組的人常以為每個模組都是獨立的 —— 不是。本站手上有一批 2010 年的社群大頭照包，一支球隊一包，可以用來把這件事量出來。

可以解開的包數	17（另一包沒下載完）
合計不重複的大頭照編號	885 個
136 組兩兩比較裡，編號有重疊的	只有 1 組（9 個編號）

幾乎不重疊，代表它們設計上就是要一起裝的。但關鍵在下一張表：

那 885 個編號，在哪裡有格子	遊戲裡的編號總數	最大編號	885 個裡有幾個
剛安裝好的原版	1,487	5043	249（28.1%）
裝過台灣名冊模組的機器	6,638	9999	777（87.8%）

在剛安裝好的遊戲上，這批包有七成的圖沒有地方可以放。 原版的編號只落在 0、1、2、5 這四個千位段，最大 5043；而這批包的編號散在 0 到 9 千段，其中 470 個直接超過原版的最大編號。

這代表什麼

那批大頭照包預設你已經裝了一個把 portrait.big 撐大的名冊模組。 它們是接在別人後面的，不是獨立的。

當年沒有人會寫「先裝 A 再裝 B」，因為在那個社群裡大家本來就都裝了同一套底。二十年後單獨拿一包來裝的人，看到的會是「圖沒出現」或「裝了沒反應」， 而那不是包壞了，是缺了它依賴的東西。

怎麼自己判斷：把包裡的檔名（四位數字）跟你遊戲裡 portrait.big 的目錄比一遍。對不上的比例太高，就是順序不對。

這條規則可以推廣

大頭照只是最好量的例子。同樣的依賴關係也存在於臉皮、球衣、語音 —— 任何「照編號放進既有封裝檔」的模組，都預設那個編號已經有格子。

本站在臉皮那頁量過同一件事的另一面：原版只有 504 張臉皮（這台機器是 894 張），而社群名冊指到的編號遠遠超過那個範圍。兩邊是同一個現象。

📌 重點整理

一句話 名單畫面上每位球員的照片全裝在 253.6 MB 的 portrait.big 裡，用的是 EA 自家的 FSH 格式，結構單純到可以用加法驗證你有沒有讀懂。
規模，還有那個巧妙的 64 KB 7,544 個項目、目錄涵蓋率 100%（孤兒 0 bytes），每張解壓後宣告的大小都是 65,680 bytes（實際長度 7,538 張分毫不差，4 張因檔尾補齊多出 4 或 8 個位元組）。兩種格式的像素資料都剛好 65,536 bytes：0x61 是 256 × 256 每像素 1 byte（5,250 張），0x7D 是 128 × 128 每像素 4 bytes（2,292 張），代號與尺寸完全一一對應，沒有任何一張交叉。
但原版只用一種 剛安裝好的原版 1,487 張大頭照 100% 都是 0x7D 128 × 128，一張 0x61 都沒有。也就是說測試機上那 5,250 張，用的是 EA 在這個倉庫裡從沒用過的格式與尺寸。
藏在每張圖裡的兩段字 檔頭與第一張圖之間那 8 個位元組是 Buy ERTS，逐一檢查剛安裝好的原版 2,391 個圖片倉庫零例外（這台機器那 7,542 個同樣零例外）；圖片資料後面那 96 個位元組寫著 EAGL64 metal bin attachment for runtime texture management。後者 2026-08-28 查清楚不是沒人登記的殘料，而是 FSH 規定的附掛區塊，由圖片記錄自己的長度欄位指過去：0x69 的 80 bytes 加上 0x70 結束標記的 16 bytes，正好 96。
840 個四字母檔名是一張完整網格 第 1 碼 15 種、第 2 碼 7 種、第 3 碼固定、第 4 碼 8 種，15 × 7 × 1 × 8 = 840，缺 0 個、多 0 個、重複 0 個，每個首字母底下剛好 56 個。三個軸分別對到罐頭臉 15 種、髮色 7 種、鬍子 8 種，所以這些是沒有專屬照片的球員拼出來的通用大頭照。
這一頁被自己推翻好幾次，原文全部保留 上線時寫「含那句話的沒有一個例外，7,542／7,542」，實際是 7,539／7,542，那三個檔寫成 mel 而且後面補了一組 CRLF，長度一模一樣所以光看長度抓不出來；上線時寫「本站沒有解出編號與球員的對應關係」，後來被推翻，那就是 playerattrib_audioid，而且連把圖壓回去的那一半都做完了，可見像素中位數 99.32% 完全相同、透明度零誤差；髮色原本寫「宣告 7 種實際只用 6 種」，那是量台灣名冊，原版把 7 種用滿；a2653.fsh 那個異常項原本當成「這份檔被動過」的痕跡，其實是 EA 自己的封裝慣例。另有兩處口徑訂正：帶那句話的原版圖檔 6,370 改成 6,392（漏掉 22 個沒進封裝檔、自己就是圖檔的檔案：data\misc\textures\ 18 個、data\igshapes\ 3 個，再加上名字叫 .big 其實是一張圖的 feonlyln.big），「224 個封裝檔」改成 207 個真的是 BIGF。
模組是有先後順序的 一批 2010 年的社群大頭照包 17 包、885 個不重複編號，兩兩比較 136 組只有 1 組重疊，設計上就是要一起裝。但那 885 個編號在剛安裝好的原版只有 249 個（28.1%）有格子，在裝過台灣名冊的機器上是 777 個（87.8%），其中 470 個直接超過原版最大編號 5043。單獨拿一包來裝看到「沒反應」，多半不是包壞了，是缺了它依賴的底。
本站沒驗的 0x61 那批是誰換的、什麼時候換的未解；那三個 mel 出自哪一次改動、那組 CRLF 哪裡來的都沒有證據；portrait.big 裡多出來的 2 張 0x7C（256 bytes，三份剛安裝好的原版都是同樣那兩張）不在說明書清單裡，不知道是什麼，data\igshapes\igcrsr.fsh 那塊 0x7C 長 576 同樣不知道是什麼；把資料區頭尾夾起來的那兩筆 1 位元組項目做什麼用不知道；st00 到 st63 那 64 張未確認；四字母第 3 碼為什麼固定不知道，「第 1 碼的 a 就是 901」只是推測；Buy ERTS 與 EAGL 的用途和正式全名本站不主張；models.big 那 671 次只是壓縮後看得見的殘影，精確數字未做。

接下來

模型與臉皮 models.big —— 894 張 3D 臉皮，用的是同一套 FSH
QFS 壓縮 —— 每一張 FSH 外面包的那一層
BIGF 封裝格式 —— 怎麼安全地把圖放回去