本站文本内容除另有声明外,均在知识共享 署名-非商业性使用-相同方式共享 3.0 协议下提供。(详情…本站文本内容除另有声明外,均在知识共享 署名-非商业性使用-相同方式共享 3.0 协议下提供。(详情…中文Minecraft Wiki是完全公开的。请勇于扩充与修正内容!中文Minecraft Wiki是完全公开的。请勇于扩充与修正内容!Minecraft中文Wiki微博正在更新!或许有兴趣去看看Minecraft中文Wiki微博正在更新!或许有兴趣去看看想与其他用户进行编辑上的沟通?社区专页正是为此创建的。想与其他用户进行编辑上的沟通?社区专页正是为此创建的。翻译或创建页面之前,不妨看看译名标准化Wiki条例页面。翻译或创建页面之前,不妨看看译名标准化Wiki条例页面。需要管理员的协助?在管理员告示板留言也许可以帮到您。需要管理员的协助?在管理员告示板留言也许可以帮到您。

區域文件格式

出自 Minecraft Wiki
前往: 導覽搜尋

區塊文件格式為在Minecraft 1.3中為存儲區塊所引入的一種文件格式。其中每32×32個區塊就會成為一組存儲進一個獨立的區域文件。可以這麼認為,區域為整個文件系統的一部分,其中頭文件用於確定每一個文件的位置、扇區則為所分配的大小。整個系統基於MCRegion[1],這是一個由Scaevolus編寫的MOD。(他的Optifine項目也同樣很有名。)MCRegion格式幾乎未發生變化,除了向其中添加隨時間戳更新的區塊列表。Jahkob宣稱這一全新的格式相比於之前的系統而言速度提高到7倍。[2]

在Minecraft 1.2中,區域文件被Anvil文件格式所取代;但是Anvil文件格式只對區塊格式做出修改,只會將區域文件的文件名由「.mcr」修改為「.mca」。

區域文件[編輯 | 編輯原始碼]

區域文件的位置[編輯 | 編輯原始碼]

區域文件位於目錄下名叫「region」的子文件中,並以r.x.z.mcr的命名方式進行命名(其中x和z為區域的坐標)。為了計算某一區塊所屬的區域的坐標,將區塊坐標除以32即可。

在Java中:

   int localX = (int)floor(chunkX / 32.0);
   int localZ = (int)floor(chunkZ / 32.0);

在對位進行操作時(移位):

   int localX = chunkX >> 5
   int localZ = chunkZ >> 5

舉例來說,坐標為(30, -3)的區塊位於(0,-1)的區域中;而坐標為(70, -30)的區塊位於(2,-1)的區域中。

結構[編輯 | 編輯原始碼]

區域文件以 8kB 文件頭開頭,其中包含了該區域文件所包括的區塊信息(最後更新的時間以及方位等)。區塊坐標為(x,z)的區塊在所在區域中的位置可以按如下方式找到:在區域文件中偏移4 * ((x mod 32) + (z mod 32) * 32) 字節即可。針對於x或z可能為負的情況,在計算其模數後需要以31減去其絕對值。在區塊信息之後4096位元組為時間戳。文件的剩餘部分包含了1024個區塊的信息,並以大量的未使用空間點綴其間。


字節 0 - 4095 4096 - 8191 8192...
描述 位置 (1024 個實體) 時間戳 (1024 個實體) 區塊和未使用空間

區塊的位置[編輯 | 編輯原始碼]

區域中所包含的區塊的位置信息由4位元組組成,分為兩部分:前三個字節為自文件開始的4KB區段中的偏移信息(高位優先),剩餘的一個字節為區塊的長度(也在4KB區段中,四捨五入)。區塊的總大小最大為1MB。如果區塊並未包含在所對應的區域文件中(如該區塊還未生成或還未遷移),則該部分會全部為零。

字節 0 1 2 3
描述 偏移 區段數

偏移為2的區塊會在世界戳列表結束後開始。

區塊的時間戳[編輯 | 編輯原始碼]

時間戳列表的入口地址為獨立的四字節高位優先的整值變量,代表了該區塊的最後修改時間。

字節 0 1 2 3
描述 時間戳

區塊數據[編輯 | 編輯原始碼]

區塊數據以一個長度為四字節的(高位優先的)數據開頭,代表了區塊以字節計的實際大小(包括偏移4處的壓縮類型在內)。之後的一個字節表示區塊數據的壓縮方法。剩餘的數據為壓縮的區塊數據。

字節 0 1 2 3 4 5...
描述 長度(以字節計) 壓縮類型 壓縮後的數據(數據長度為偏移0處記錄的長度值減1)

當前有兩種壓縮方法:

數值 方法
1 GZip (RFC1952) (在實際中未得到應用)
2 Zlib (RFC1950)

未經壓縮的數據已NBT格式進行保存,詳細的信息請參見區塊格式詞條頁面。如果使用第一種壓縮算法,壓縮後的文件與Alpha區塊文件的磁碟目錄相同。值得注意的是在官方客戶端中使用的是第2種壓縮算法。

數據遷移與level.dat[編輯 | 編輯原始碼]

Minecraft在轉換至新版本時的介面樣子。

在Beta 1.3中會在載入世界之前將任何"較早"版本的區塊轉換至區域文件之中,而不是在隨著遊戲的進行逐漸進行轉換。在轉化的過程中,level.dat會更新TAG_Int("version(版本)")至19132版本。Beta 1.3同時也引入了一種新的世界命名空間,TAG_String("LevelName")。也引入了在玩家複合標籤(TAG_Compounds),(單人遊戲為level.dat,多人遊戲為[player name].dat)中新的標籤,TAG_Byte("Sleeping"),這一標籤用於確定玩家是否在睡覺。其值非真(1)即假(0)。 在版本beta 1.8中添加了TAG_Int("GameType");在版本beta 1.9中添加了TAG_byte("hardcore")。

level.dat中的其他部分未作改變。

另見[編輯 | 編輯原始碼]

外部連結[編輯 | 編輯原始碼]

另見[編輯 | 編輯原始碼]