速查 › 王朝存檔長什麼樣

王朝存檔長什麼樣

王朝模式的存檔是 .sav 檔。這頁講它的外形 —— 大小、有沒有加密、哪一段會變哪一段不會。 本站沒有解出裡面的欄位,但光是外形就已經看得出不少事。

這頁最好驗

下面第一個數字,你用檔案總管看一眼就能自己確認 —— 不用工具、不用命令列。

每個存檔都剛好一樣大

本站手上有 30 個王朝存檔(大聯盟 30 支球隊各一個)。 把它們的檔案大小列出來:

2,239,688 bytes  ×30

三十個檔,一種大小,一個位元組都沒差。

這代表它是固定長度的格式

不管你玩到第幾個球季、簽了幾個自由球員、傷兵名單多長, 檔案大小永遠一樣

意思是每一格資料都有固定的位置 —— 沒有用到的欄位就填 0, 不會讓檔案縮小。這種格式比較好改, 因為第 N 個位元組永遠代表同一件事。

檔名格式也一致:<球隊>_Franchise.sav,30 個全部符合。

沒有加密,也沒有壓縮

判斷一個檔有沒有被加密或壓縮,有一個很簡單的量法:看它的位元組有多「亂」

檔案類型亂度
加密過的 / 壓縮過的接近 8.0
這個存檔實測3.51

3.51 離 8.0 很遠。而且直接證據更明顯 —— 打開就看得到字

量到的結果
可讀字串(六個字以上)4,338 個
第一個可讀字串ANGELS_Franchise.sav
也找得到Angels / Los Angeles
0x00 佔全檔34.7%

存檔把自己的名字寫在裡面(30 個裡有 28 個跟磁碟上的檔名一字不差; CINCINNATI 裡面寫的是 CINCINATI_Franchise.sav、 OAKLAND 裡面寫的是 OAKLANDS_Franchise.sav —— 它記的是當年存檔時打的名字,不是磁碟上的檔名)。球隊名、城市名也都是明文。

不同球隊的存檔有多像

我們改過這一段

這一節原本只比對了一組存檔(ANGELS 對 ARIZONA), 卻寫成「後半 100 萬個位元組,三十個存檔一模一樣」。

那是從一組樣本推出來的全稱句,而且不成立。 把 30 個存檔的 435 組全部比一次之後: 位移 1,200,000 之後仍有差異的有 104 組, 全部組別裡最晚的差異落在位移 1,254,095

更麻煩的是,站上剛好挑到 435 組裡最不利的取樣: ANGELS 與 ARIZONA 正好同屬下面講的那個小群,兩者後半確實相同。

先看站上原本比的那一組(ANGELS 對 ARIZONA):

量到的這一組30 檔兩兩全比 435 組
不一樣的位元組 19,393
= 0.87%
3,331 ~ 24,533
= 0.15% ~ 1.10%
差異最早出現在位移 0位移 0
差異最晚出現在位移 1,188,087 位移 1,254,095
位移 120 萬之後這一組完全相同 435 組裡有 104 組不同

ANGELS 對 ARIZONA 的差異幾乎全部擠在前 50 萬個位元組裡 (19,393 個裡有 19,388 個);30 檔聯集則是 80.4%(26,123 個裡有 20,996 個)。 下面右邊那欄是把 30 個檔全部攤開,任何一個位移上只要有任兩檔不同就算一個

位移範圍ANGELS 對 ARIZONA30 檔聯集
0 – 10 萬4,9845,311
10 – 20 萬12,85413,606
20 – 30 萬1,1391,507
30 – 40 萬393529
40 – 50 萬1843
50 萬 – 110 萬0160
110 – 120 萬5947
120 萬以後04,020

一手發現:30 個存檔的後半分成兩群,而且群內完全相同

用位移 1,200,000 之後的內容做指紋,30 個存檔只分成兩群

幾個是哪些
4 ANGELS · ARIZONA · ATLANTA · BALTIMORE
26其餘全部

群內完全相同,群間不同。 104 = 4 × 26,正好是兩群之間的全部配對數。

為什麼會這樣分,本站不知道,也不猜。 只記錄量到的分群。

所以這個檔看起來分成兩半

前半(約 50 萬位元組):跟「你選哪一隊」有關的東西。
後半:差異變得很少,但不是沒有 —— 30 個存檔在這一段有兩種版本。

推測 後半可能是球員名單、賽程這類比較共通的東西。 本站沒有解出欄位,所以這只是從差異分佈推的。

2006 年是怎麼改賽程的

本站有一課教把整季賽程搬到任何年份, 做法是改資料檔

而 2006 年社群的做法完全不一樣 —— 那個工具的說明檔寫著:

它需要

遊戲要先開著。說明檔沒提, 但工具資料夾裡還留著一個只有一行的設定檔,裡面就是一個數字。

那個數字是記憶體位址

也就是說:它改的是「遊戲正在跑的那份資料」,不是硬碟上的檔案。

改完之後要照它說的「存到一個新的存檔格,再讀回來」—— 這樣改動才會落到 .sav 裡。

二十年前的做法跟現在的做法,解的是同一個問題, 路徑完全不同。那個工具是第三方作品,本站不提供也不轉載

王朝不是唯一一種存檔(2026-08-28 補)

本頁量的是王朝模式的存檔。本站後來拿到一批同一台機器上的其他存檔, 發現遊戲一共存五種,而每一種都有自己的固定大小

存檔種類每個檔的大小裝什麼
王朝模式(本頁上面量的)2,239,688整個王朝的進度
老闆模式2,319,560另一種長期模式
名單937,160一份可以單獨存取的名單
玩家檔案2,248個人設定
遊戲選項1,224音量、難度那些

五種各自固定,一個位元組都不差。 這跟本頁上面講的是同一個設計:存檔是定長的格子,不是寫多少存多少

玩家檔案幾乎整份是空白表格

兩個不同的玩家檔案(各 2,248 個位元組)逐位元組比: 只有 6 個位元組不一樣,而且全部集中在開頭 —— 99.73% 相同。

換句話說,那個檔幾乎整份是固定的範本, 真正屬於你的只有開頭那一小段(名字)。 2,248 個位元組裡,有 2,242 個對誰都一樣。

大檔裡有大片「不會變」的區域

把兩個老闆模式的存檔切成 20 段逐段比:

第 1–12 段每段有 6,830 到 110,210 個位元組不同真正在變的資料
第 13 段只差 502 個位元組 資料寫到位移 1,392,238 就停了
第 14–20 段(約後三分之一)完全相同 而且不是空白(那一段幾乎沒有 0)

所以那不是「保留空間」,是一塊兩份存檔都一樣的密實資料 —— 比較像是遊戲把某份參考表整個複製進每一個存檔。 已解 那是什麼,2026-08-29 解出來了 —— 它是填充,不是資料。細節與位元組樣本在下面「存檔的最後一大段不是資料,是填充」那一節。

名單存檔則相反:它有大片整段都是 0 的區域 (20 段裡有 6 段幾乎全零)——那才是真正的保留空位。 兩種「相同」是不一樣的東西,切段來看才分得出來。

⭐ 2026-08-29:存檔的最後一大段不是資料,是填充標記

本站上一輪量到「老闆模式存檔的後三分之一,兩份完全相同但不是空的」, 當時標成未解。現在解開了,而且答案適用於全部五種存檔。

那一段只有兩種位元組值

55 bb 55 bb 55 bb 55 bb 55 bb 55 bb 55 bb 55 bb
55 bb 55 bb 55 bb 55 bb 55 bb 55 bb 55 bb 55 bb

老闆模式其中一份那 927,322 個位元組裡,0x55 出現 463,661 次、 0xBB 出現 463,661 次 —— 剛好一半一半,完美規律

那不是空的(不是 0),也不是資料。它是填充標記 —— 跟微軟編譯器用 0xCD 標「未初始化記憶體」是同一類東西。

五種存檔全部都有,而且比例差很多

存檔種類檔案大小真正寫了 填充(位元組)填充佔比
王朝2,239,6881,254,142 985,54644.0%
老闆模式2,319,560 1,332,980 / 1,392,238986,580 / 927,322 40–43%
名單937,160935,772–936,222 938–1,3880.1%
玩家檔案2,2481,892 35615.8%
遊戲選項1,224976 24820.3%

兩件事因此說得通了

一、為什麼每種存檔都剛好一樣大。因為它是固定大小的緩衝區, 整塊先填成 55 BB,寫多少算多少,剩下的原樣留著。

二、為什麼「兩份完全相同但不是空的」。 那一段兩份當然相同 —— 兩份都沒寫到那裡。

⭐ 而比例本身也在說話:名單存檔用掉 99.9% 的空間,王朝存檔空著 44%。 名單是塞滿的,王朝留了很大的餘裕。

一個容易誤讀的細節

兩份老闆模式存檔的資料段長度不一樣(1,332,980 與 1,392,238)—— 所以那不是一條固定的分界線,是寫到哪算哪

相對地,遊戲目錄裡 30 個王朝存檔的資料段長度完全相同, 因為它們是同一個設定的全新存檔,還沒開始玩。

量法說明:從檔尾往前找連續的 55 BB。 驗過這個樣式不會在資料段裡大量出現 —— 老闆模式那份除了 927,322 位元組的尾段之外, 檔案中間最長的一段只有 24 個位元組(純粹巧合), 名單與玩家檔案的資料段裡也找得到這個樣式(名單 603–606 處、玩家檔案 123 處), 但最長只有 8 與 12 個位元組。所以尾段的長度是可信的。

這頁不能告訴你什麼

本站沒有解出存檔的欄位

知道「多大、沒加密、哪一段會變」, 但不知道第 N 個位元組代表什麼未解

所以本站沒有、也不會提供改存檔的教學或工具 —— 在不知道欄位的情況下改存檔,等於亂猜。

如果你要自己試:先複製一份存檔到別的資料夾。 存檔壞掉是整個王朝重來。

📌 重點整理

接下來