速查 › 字型檔 .ffn

字型檔 .ffn

遊戲畫面上的每一個字都來自 data/fonts/fonts.big 裡的 12 個點陣字型。 這頁除了講格式，還會用這個檔把「孤兒資料到底怎麼產生的」完整證明一次 —— 它剛好留下了一組算得清清楚楚的證據。

先看規模

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

兩種檔頭代號，大小寫不一樣

把 12 個字型解開後看開頭四個位元組，只有兩種：

46 4E 54 46   =  FNTF
46 6E 74 46   =  FntF      ← 中間兩個字母是小寫

檔頭第 9-10 個位元組也跟著分群：FntF 那七個全部是 414， FNTF 那五個是 317 到 366 之間。 推測 看起來像是格式版本號，但本站沒有證實。

檔頭自己寫著檔案多大

第 5 到 8 個位元組是一個數字，跟解開後的實際長度比對：

12 個裡有 10 個完全相符。剩下兩個各多出 1,088 個位元組 —— 部分已解 兩個差距一模一樣，不像隨機出錯。本站後來把那 1,088 個位元組打開看，得到三件事：

還是不知道它是什麼，但至少知道它不是垃圾： 是兩塊各自不同、有結構的資料，接在宣告的長度後面。 仍未解

跟 FSH 圖片與音訊索引一樣， 這是又一個「格式自己帶著驗算方法」的例子。

12 個檔，只有 9 種內容

hrdbg_en.ffn
twc14_en.ffn      ← 這四個解開後
twc16_en.ffn         位元組完全一樣
twc18_en.ffn

孤兒資料是怎麼產生的：一個算得清楚的例子

前面說這個檔有 250,411 bytes 沒被目錄指向。 其中有三段大小完全相同：

[189,700 → 252,239)   62,539 bytes
[262,244 → 324,783)   62,539 bytes
[334,788 → 397,327)   62,539 bytes

三段一模一樣大，這不會是巧合。看看它們前面各接著什麼：

72,544 正好是這三個字型解壓後的大小。

所以整件事的經過是這樣：

原本            [────────── 未壓縮字型 72,544 bytes ──────────]

改過之後        [壓縮版 10,005][──── 原本資料的後半段 62,539 bytes ────]
                 ↑
                 目錄現在只指到這裡,後面那段沒人認領

中文字型走的是「日文」那個槽位

原版 12 個字型的檔名全部以 _en 結尾。 本站另外打開一份 2023 年的中文懶人包，同一個封裝檔長這樣：

⚠️ 這張表跟上面那張不要直接對數字，兩件事都不一樣： 上面那張量的是本站測試機那份 2022 年被改過的 fonts.big，欄位是解壓後大小； 這張量的是剛安裝好的原版與中文包，欄位是封裝檔內佔用。 所以同一個檔名在兩張表會出現兩個數字（Tw24_en.ffn 上面 4,048、這裡 5,751； au20b_en.ffn 上面 18,000、這裡 57,617）—— 差的不只是口徑，連檔案本身都被換過了，那正是本頁開頭「這一份被改過」在講的事。 同理，〈先看規模〉那個「解壓後合計 777,520」也是測試機那份，跟這一節的 204,523 不同口徑。

case 0、1 → "_en"    case 2 → "_sp"
case 3、4 → "_jp"    case 5 → "_es"

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

能改到什麼程度

📌 重點整理

• 一句話 遊戲畫面上每個字都來自 data/fonts/fonts.big 裡的 12 個點陣字型，本站把容器層全部解開（幾個、多大、壓縮與否、檔頭前 10 個位元組怎麼讀）；字圖集與字元表在另外兩頁也讀出來了，但沒有從零產生一份再寫回去的辦法，所以這頁能幫你判斷與替換，不能幫你造字。
• 大小寫代號就是壓縮開關 解開後開頭四個位元組只有兩種，FNTF 5 個全部沒壓縮、FntF 7 個全部有 QFS 壓縮，12 個檔零例外。檔頭第 5 到 8 個位元組自己宣告長度，12 個裡 10 個完全相符。
• 決定性的那一步 這個檔 397,327 個位元組裡有 250,411 沒被目錄指向，其中三段大小完全相同都是 62,539，而它們前面各接著 twc14／twc16／twc18 佔用的 10,005，10,005 ＋ 62,539 ＝ 72,544 正好是解壓後的大小。本站直接比對：三段逐位元組相同，62,539 個位元組一個不差。孤兒資料不是垃圾也不是損壞，是舊資料沒被覆蓋掉的那一部分。
• 12 個檔只有 9 種內容 hrdbg_en、twc14_en、twc16_en、twc18_en 四個都是 72,544 個位元組、內容一個位元組不差。名字看起來是 14／16／18 三種字級，裝的其實是同一份東西。
• 那兩個「多 1,088 個位元組」的檔，打開看過了 dflt_en 與 twn14_en 各比檔頭宣告多 1,088。那段不是填充（開頭是 ff ff ff 04、ff ff ff 05 這種規律遞增），其中一個帶著 EAGL64 標記，而兩個尾巴逐位元組比對 90.8% 不同，所以也不是同一塊資料複製兩份。從「沒解讀」進步到「知道它不是垃圾」。
• 中文走的是日文那個槽位 原版 12 個字型檔名全部以 _en 結尾，2023 年的中文包是 12 個 _jp ＋ 留著原本的 dflt_en，總量從 204,523 個位元組變成 1,683,191。2026-08-28 補上執行檔層證據：組檔名的那段程式（0x004FE860）取的語系後綴來自 0x004FE9BC 的跳表，只有 _en／_sp／_jp／_es 四種，裡面沒有中文，所以不是偏好，是只有這幾個位子可以借。
• 看檔名跟大小就知道你的遊戲能不能顯示中文 打開 data\fonts\fonts.big，全部是 _en、合計約 200 KB ＝ 沒裝中文字型；出現 _jp、合計超過 1 MB ＝ 裝過了；全部是 _en 卻遠超過 200 KB（例如 1.2 MB）也是裝過了 —— 那種包直接蓋掉英文槽位，檔名分不出來，要看大小。另外社群的中文包不只一份、動的槽位也不一樣（本頁表裡這份是 12 個 _jp ＋ 留著 dflt_en，〈中文版配大球場就跳出〉那一課量的那份是 12 個 _en 直接蓋掉英文），所以不同頁的字型總量對不起來是正常的。
• 本站沒驗的 字圖集與字元表讀得出來（見本頁「誠實邊界」的 2026-09-05 訂正），但本站沒有從零產生一份、再寫回去的辦法，所以做不出新字型、也加不了原本沒有的字；那 1,088 個位元組到底是什麼仍未解；檔頭第 9 到 10 個位元組「看起來像版本號」是推測；四個檔內容相同是誰、什麼時候做的無法確認；「為什麼借日文槽位」是推想，檔案裡沒有寫。還有一件事要記得：這份 fonts.big 檔案日期是 2022 年 11 月，不是 2005 年的原廠狀態，本頁描述的是它現在長什麼樣。

接下來

• 一個檔案裡的地層 —— 同樣的現象，在一個大 6.7 倍的檔案上
• BIGF 封裝格式 —— 為什麼改檔要用「接到檔尾」
• FEL 版面語法 —— 版面檔用 LF: 指定要載入哪個字型