本文章介紹的是NBT檔案格式。關於NBT標籤的具體使用和功能，請見「教學/NBT指令標籤」。關於NBT以及JSON的語法和用法，請見「教學/NBT與JSON」。NBT（二進制命名標籤，NamedBinary Tags）格式是一種由眾多的標籤所組成的樹狀資料結構。在Minecraft中，其被廣泛用於向存檔檔案中儲存資料。所有的標籤都有一個獨立的數字ID和名稱，以及一個負載。
另一種玩家更熟悉的是字串形式的NBT，通常在指令裡使用。這種格式常被稱為SNBT（字串化的二進制命名標籤，Stringified NBT）。
SNBT格式[]
SNBT，也被稱為資料標籤，在Java版指令中很常見。它的簡單表示方法為使用花括號將一對鍵值對括起來。在指令中，資料標籤常被用以描述複雜的實體資料。
資料標籤可以包含零個或多個屬性值對，它們以逗號分隔，被一對花括號包覆。每個屬性值對又由標籤名和標籤值構成，名和值之間用冒號連接。實際上，對於很多值來說，可能其自身就是一個包含眾多屬性值對的複合標籤，這使得資料標籤能對分層資料結構進行描述。
- 示例：
{name1:123,name2:"sometext1",name3:{subname1:456,subname2:"sometext2"}}
標籤name1,name2,name3的所在層級為「第一層」，name3標籤下的subname1,subname2的所在層級為「第二層」。
需要注意的是，JSON格式是與之不同的另一種格式；因此，對於任何嵌入到NBT中的JSON（比如原始JSON文字），都必須包含在 字串類型的標籤中。
資料類型[]
SNBT標籤具有不同的類型，可以描述不同性質的資料，其書寫格式也因此有所差異。
| 類型 | 描述 | SNBT格式 | SNBT示例 |
|---|---|---|---|
| Byte | 字節型，為一個8-bit整數，範圍是-128到127（閉區間）。 | <数字>b或<数字>B
|
34B、-20b
|
| Boolean | 布林型。NBT本身並沒有布林型資料類型，但是byte值0和1可以分別表示true和false。
|
true、false
|
true
|
| Short | 短整型，為一個16-bit整數，範圍是-32,768到32,767（閉區間）。 | <数字>s或<数字>S
|
31415s、-27183s
|
| Int | 整型，為一個23-bit整數，範圍是-2,147,483,648到2,147,483,647（閉區間）。 | <整数>
|
31415926
|
| Long | 長整型，一個64-bit整數，範圍是-9,223,372,036,854,775,808到9,223,372,036,854,775,807（閉區間）。 | <数字>l或<数字>L
|
31415926l
|
| Float | 單精度浮點數類型，為一個32-bit單精度浮點數字，範圍是-3.4E+38到+3.4E+38。
參見IEEE floating point以取得詳細資訊。 |
<数字>f或<数字>F
|
3.1415926f
|
| Double | 倍精度浮點數類型，為一個64-bit倍精度浮點數字，範圍是-1.7E+308是+1.7E+308。
參見IEEE floating point以取得詳細資訊。 |
<十进制数字>、<数字>d或<数字>D
|
3.1415926
|
| String | 字串類型，為一個字元序列。 | 字串使用引號包圍。對字串來說，僅當其只包含0-9、A-Z、a-z、_、-、。和+字元，並且不與其他資料類型混淆的情況下（例如，使用/data modify設定某標籤值為123b時，若不指定引號，則會設定為byte類型數字），引號可以省略。引號可以是一個單引號'或者是雙引號"。透過使用\轉義字元，可以對字串中的引號進行嵌套。
|
|
| List | 串列類型，為一個包含標籤的有序串列。其中的標籤必須為同一個類型，類型由串列中的第一個標籤決定。 | 用方括號將以逗號分隔的無名標籤括起來（即僅包含值）。
|
[3.2,64.5,129.5]
|
| Compound | 複合標籤類型，為一個包含屬性值對的有序串列。
其中的每個標籤可以為任意類型。 |
用花括號將以逗號分隔的帶名標籤括起來。
鍵名（標籤名）若僅含
|
{X:3,Y:64,Z:129}
|
| Byte Array | 字節型陣列類型，為一個8-bit整數有序串列。注意，[B;1b,2b,3b]和[1b,2b,3b]被視為不同的類型，後者為 list。
|
B;位於串列內的首位置，其後緊隨以逗號分隔的byte型數字。標籤應該被方括號括起來。
|
[B;1b,2b,3b]
|
| Int Array | 整型陣列類型，一個32-bit整數有序串列。注意，[I;1,2,3]和[1,2,3]被視為不同的類型，後者為 list。
|
I;位於串列內的首位置，其後緊跟以逗號分隔的int型數字。標籤應該被方括號括起來。
|
[I;1,2,3]
|
| Long Array | 長整型陣列類型，為一個64-bit整數有序串列。注意[L;1l,2l,3l]和[1l,2l,3l]被視為不同的類型，後者為 list。
|
L;位於串列內的首位置，其後緊跟以逗號分隔的long型數字。標籤應該被方括號括起來。
|
[L;1l,2l,3l]
|
NBT對象[]
當遊戲執行時，處於正在載入的區塊中的實體和方塊都儲存在記憶體中。這種情況下，它們沒有以NBT的形式被儲存，而只是程式對象。
在進行NBT操作時，遊戲會先從實體/方塊實體生成程式化的NBT對象，然後解析SNBT為NBT對象，最後基於提供的NBT對象來修改實體/方塊，或者轉化NBT對象為SNBT。
生成NBT對象[]
當從實體/方塊生成NBT時，實體/方塊的屬性將被加入到程式化的NBT對象中。
注意，不是所有的屬性都會被加入。比如，標識一個玩家是否會打開一個儲物箱的值將不會被加入到NBT對象中。
值被加入時到對象時，其資料類型也應該是確定的。比如，要加入一個命名空間ID作為值，會先將其轉換為一個字串。
當退出遊戲或者自動儲存時，這些NBT對象也將會以nbt檔案的形式儲存到遊戲檔案中。所以，對於各處的標籤來說，不管是NBT標籤所描述的資料結構還是每個標籤的資料類型，基本上與遊戲存檔檔案中的相同。這些資料類型也在其他文章或指令中被描述過，它們都被期望擁有相同的的屬性名稱（區分大小寫）：
| 對象 | 例子 |
|---|---|
| 方塊實體 | 儲物箱、熔爐、指令方塊、生怪磚、告示牌等。 |
| 物品 | 在物品欄中的物品（包括附魔、物品描述、自訂名稱等說明資訊）。 |
| 物品和經驗球 | 地面上的物品。 |
| 生物 | 苦力怕、牛、村民等。 |
| 投射物 | 火焰彈、被投擲的藥水等。 |
| 交通工具 | 船、礦車等。 |
| 動態方塊 | 點燃的TNT、下落的沙/礫石/混凝土粉末/鐵砧。 |
| 其他實體 | 煙火、畫和物品展示框。 |
轉換為SNBT[]
當嘗試用/data get等指令取得一個程式化的NBT對象時，此對象將會被轉換為一個SNBT。
除了 整型，其餘類型數字在被轉換後，都帶有字母尾綴（小寫字母b、s、f、d和大寫字母L）。比如，3s是轉換後的short，3.2f是轉換後的float，等等。
字串被轉換後總是被單雙引號包圍。
對於其他資料類型，請在上文的#資料類型表格中查看相關介紹。
從SNBT轉換[]
當SNBT被遊戲解析時，它將會被轉換為一個程式化的NBT對象。
對於帶有字母後綴（B、S、L、F、D，或者它們的小寫字母）的數字，將被解析為相應的資料類型。比如，對short為3s（或3S），對float為3.2f（或3.2F）。若沒有指定尾綴，則有小數點的數字會將被當做double，而無小數點的32-bit大小內的數字將被當做int，剩餘情況下，都將當做string。
包含字面量的方括號將被視作串列，除非使用一個識別碼：[I;1,2,3]為整型陣列，[L;1L,2L,3L]為長整型陣列，而[1L,2L,3L]是串列，其中裝有長整型數字。
true和false將分別被轉換為1b和0b。
基於NBT對象修改實體/方塊[]
基於程式化的NBT對象修改實體/方塊並不是一個簡單的過程。在改變實體/方塊屬性前，需要解析所有指定的標籤。注意，只有某些特定屬性被修改。比如，當使用/data指令來修改一個方塊實體時，它的座標是不能改變的。
若某屬性需要的值為一個命名空間ID，並得到了一個 string標籤，則該字串將會轉換為一個命名空間ID。
若某屬性需要的值為一個JSON文字，並得到了一個 string標籤，則該字串將被解析為JSON文字對象。
若某屬性需要一個布林值，並得到了一個數值類型的標籤，那麼如果該數值非0，就會先將其四捨五入，然後再將其轉換為byte型數字，並設該屬性為真。
若某屬性需要一個布林值，但得到了一個非數值類型的標籤，那麼此屬性將為假。
若某屬性需要某數值類型的數字作為其值，但得到一個與之所需類型不符的數值類型標籤（錯誤的標籤），那麼其值將被四捨五入後再轉換為所需要的類型。
若某屬性需要某數值類型的數字作為其值，但得到一個非數值類型的標籤，那麼該屬性將被賦值為0。
若某屬性需要一個字串作為其值，但得到一個非字串類型的標籤，那麼該字串將變為一個空串。
若某屬性需要一個串列，或是某類型的陣列，但其標籤類型與需要的類型不符（錯誤的標籤），則它將得到一個空串列/陣列。
若某屬性需要一個複合標籤，但卻得到了一個非複合標籤，則它最終會得到一個空複合標籤。
二進制格式[]
NBT檔案是經過了壓縮的複合標籤，其中包含名稱以及標籤ID。壓縮包中必須包含一個作為首字節的複合標籤。在Minecraft中，有一些檔案可能是未壓縮的，但在大多數情況下，檔案仍遵循Notch的原始說明使用GZip壓縮。
標籤的定義[]
每個標籤在資料樹中都是獨立的一部分。標籤的第一個字節為標籤類型（ID），後兩個字節是名稱的長度（以兩個字節的大端序無符號整數記錄），最後是UTF-8格式字串儲存的標籤名稱（註：TAG_End沒有名稱，不包含第二部分的兩個字節，故名稱被定義為空）。雖然Minecraft自己不會儲存有空格的標籤名稱，但是實際上名稱允許包含空格。根據標籤類型的不同，名稱部分後的部分就是標籤的「負載」。下表所示為在19133標籤版本中二進制命名標籤格式中所有13個已知的標籤類型及它們對應的SNBT格式：
| 圖示 | 描述 | SNBT格式 |
標籤類型與ID | 負載 | 儲存容量 |
|---|---|---|---|---|---|
| – | 用於標記 複合標籤的結尾。本標籤無任何名稱所以只有一個零字節。 | – | TAG_End（0） | 無 | N/A |
布林值，對應Java中的boolean。
|
|
TAG_Byte（1） | 1位元組 / 8位元，有符號 | -27到27-1（-128到127） | |
有符號的整值資料類型，對應Java中的byte。
|
| ||||
有符號的整值資料類型，對應Java中的short。
|
|
TAG_Short（2） | 2位元組 / 16位元，有符號，大端序 |
-215到215-1（-32,768到32,767） | |
有符號的整值資料類型，對應Java中的int。
|
|
TAG_Int（3） | 4位元組 / 32位元，有符號，大端序 |
-231到231-1（-2,147,483,648到2,147,483,647） | |
有符號的整值資料類型，對應Java中的long。
|
|
TAG_Long（4） | 8位元組 / 64位元，有符號，大端序 |
-263到263-1（-9,223,372,036,854,775,808到9,223,372,036,854,775,807） | |
有符號的浮點資料類型，對應Java中的float。
|
|
TAG_Float（5） | 4位元組 / 32位元，有符號，大端序 |
資料精度根據數值而定，見單精度浮點數 | |
有符號的浮點資料類型，對應Java中的double。
|
|
TAG_Double（6） | 8位元組 / 64位元，有符號，大端序 |
資料精度根據數值而定，見倍精度浮點數 | |
儲存byte的陣列。
|
|
TAG_Byte_Array（7） |
|
根據JVM的不同，陣列成員最大數量可能在231 - 9和231 - 1（2,147,483,639和2,147,483,647）之間。 | |
不包含空結束符的UTF-8字串，對應Java中的String。
|
|
TAG_String（8） |
|
可解釋為UTF-8字串的最多65,535個字節（見變種UTF-8；ASCII字元均為1位元組，大多數中文字元為3位元組） | |
| 一個標籤串列，其成員沒有標籤ID和標籤名稱。 |
|
TAG_List（9） |
|
由於JVM的限制以及ArrayList的實現問題，串列成員最大數量為231 - 9（2,147,483,639）。另外， List和 Compound標籤的嵌套深度不能超過512。 | |
| 一系列完整的標籤資訊，包括ID、名稱以及負載等。任意兩個標籤都不能有相同的名稱。 |
|
TAG_Compound（10） |
|
不像串列，Compound標籤內的標籤數量沒有硬性限制（不過仍受JVM分配的記憶體限制）。另外， List和 Compound標籤的嵌套深度不能超過512。 | |
儲存int的陣列。
|
|
TAG_Int_Array（11） |
|
根據JVM的不同，陣列成員最大數量可能在231 - 9和231 - 1（2,147,483,639和2,147,483,647）之間。 | |
儲存long的陣列。
|
|
TAG_Long_Array（12） |
|
根據JVM的不同，陣列成員最大數量可能在231 - 9和231 - 1（2,147,483,639和2,147,483,647）之間。 |
複合標籤的串列常以嵌套遞歸的方式出現。另外還需注意，在一個包含List的List中，每個List可以包含不同類型的資料。
在Minecraft中的應用[]
NBT檔案格式在Minecraft的應用十分不一致。在某些情況下，空串列可能表示為字節標籤串列而不是正確標籤類型的串列，或者在較新的Minecraft版本中表示為一系列的End標籤（這會導致較舊的NBT工具出現錯誤）。另外，幾乎所有的根標籤的名稱都是空字串，並包含唯一一個複合標籤儲存實際的資料和名稱，如下所示：
- 在Minecraft NBT結構中最常看到的根標籤。
- SomeName: 在根標籤下的唯一一個標籤——這一標籤擁有名稱和實際的資料。
另一點值得注意的是，儘管Notch最初所述允許在標籤名稱中出現空格，甚至是在例子中也出現了包含空格的標籤名稱，但是Minecraft目前並沒有使用帶有空格的標籤名稱。字母大小寫的使用也不一致，包含「小駝峰（camelCase，即首個單詞小寫，而後的單詞首字母全部大寫）」、「大駝峰（PascalCase，即所有單詞的首字母都大寫）」和「蛇形（snake_case，即所有單詞小寫，以下劃線分割）」三種不同的命名法。
應用[]
- level.dat以壓縮後的NBT格式儲存。
- <player>.dat以壓縮後的NBT格式儲存。
- idcounts.dat以壓縮後的NBT格式儲存。
- map_<#>.dat以壓縮後的NBT格式儲存。
- servers.dat以未壓縮的NBT格式儲存多人伺服器清單。
- 區塊以壓縮後的NBT格式儲存區域檔案。
- scoreboard.dat以壓縮後的NBT格式儲存。
- 儲存的結構以壓縮後的NBT格式儲存。
官方軟件[]
Mojang已經公佈了Java中的NBT示例類檔案，並將其作為Region至Anvil格式轉換器原始碼的一部分使用。[2]自Java版1.13起，Minecraft內建了SNBT和壓縮後的NBT檔案的轉換器，且通常與官方伺服器端一同發佈。[3]
來自Minecraft的資料生成器能夠將輸入資料夾中擴展名為.snbt的未壓縮字串化NBT檔案轉換為輸出資料夾中擴展名為.nbt的GZip壓縮NBT格式檔案，反之亦然。
原版資料生成器可以將任何GZip壓縮的NBT格式轉換為SNBT格式。只需將檔案的擴展名（如level.dat）變更為level.nbt並將其放入輸入資料夾，然後生成器將對GZip壓縮的NBT資料進行解碼。
歷史[]
最早的已知NBT格式版本是Java版Beta 1.3中引入的19132；隨著Anvil檔案格式的引入，增加了一個整型陣列變數，版本號也隨之更新至19133。NBT標籤的歷史最早可以追溯到Indev，當時只有0到10這11個標籤可用。
關於「NBT格式」的歷史，請見各版本頁面。
關於「NBT格式」的歷史，請見各版本頁面。
關於「NBT格式」的歷史，請見各版本頁面。
關於「NBT格式」的歷史，請見各版本頁面。
關於「NBT格式」的歷史，請見各版本頁面。
關於「NBT格式」的歷史，請見各版本頁面。
關於「NBT格式」的歷史，請見各版本頁面。
外部連結[]
- wiki.vg上的NBT條目
- NBTExplorer，一個用於查看和編輯NBT檔案的工具
- webNBT，一個線上的查看和編輯NBT檔案的工具
參考[]
 Java版
| |||||||
|---|---|---|---|---|---|---|---|
| 版本 | |||||||
| 開發週期 |
| ||||||
| 技術 |
| ||||||
| 多人遊戲 | |||||||
| 遊戲訂製 | |||||||
語言