NBT Format
このサイトを参考にしたり表を取っています
Contents
フォーマット
| Type ID(byte) | 名前の長さ(short) | 名前 | Payload | |
|---|---|---|---|---|
| デーコード結果 | 2 | 9 | shortTest | 32767 |
| 16進数上 | 02 | 00 09 | 73 68 6F 72 74 54 65 73 74 | 7F FF |
注意:TAG_Listの中にある場合はTypeIDと名前の長さ、名前がありません
TypeIDの種類
| Type ID | 名前 | Payload の大きさ(byte) | 説明 |
|---|---|---|---|
| 0 | TAG_End | 0 | TAG_Compoundの終わりを知らせる 名前の長さや、名前、Payloadは存在しない |
| 1 | TAG_Byte | 1 | 符号付きのbyte(8bit) |
| 2 | TAG_Short | 2 | 符号付きのshort(16bit) |
| 3 | TAG_Int | 4 | 符号付きのinteger(32bit) |
| 4 | TAG_Long | 8 | 符号付きのlong(64bit) |
| 5 | TAG_Float | 4 | 符号付きのIEEE-754に準拠したfloat(NaNもある) |
| 6 | TAG_Double | 8 | 符号付きのIEEE-754に準拠したdouble(NaNもある) |
| 7 | TAG_Byte_Array | integer(32bit)+中身 | 符号付きのbyte(8bit)の配列 初めに符号付きのinteger(配列の長さ)で その次からbyteの塊 |
| 8 | TAG_String | 符号なしshort(16bit)+byteの塊 | String(文字列) 文字列の形式 初めに文字列の長さ(読み込むbyte数)として 符号なしのshort(16bit)が送られる、次にその分byteを読み込む |
| 9 | TAG_List | byte(8bit)+integer(32bit) +中身 | 中身の名前がなく中身のTypeIDがすべて同じである 初めにTypeID(byte)で、 次に配列の長さ(integer)がある 中には名前、TypeIDがない(つまりPayloadやデータのみ) 注意: TAG_Compoundは、TypeIDの10はないけど最後のTAG_Endの0はある 長さが0以下の場合はTypeIDは0にするのが望ましい 解析する人は、長さが0以下の場合は任意のタイプを受け付けないといけない(よくわからんかった) |
| 10 | TAG_Compound | 知らん最後はTAG_Endで終わる | まとまり TAG_Listと違ってTypeIDや名前がある 長さなどはない(代わりにTAG_Endがある) また、中身がすべて同じ型じゃなくてもいい TAG_Endでこれが終わったことが分かる |
| 11 | TAG_Int_Array | integer(32bit)+中身 | 符号付きのinteger(32bit)の配列 初めに符号付きのinteger(配列の長さ)で その次からintegerの塊 |
| 12 | TAG_Long_Array | integer(32bit)+中身 | 符号付きのlong(64bit)の配列 初めに符号付きのinteger(配列の長さ)で その次からlongの塊 |
その他
NBTファイルは非圧縮かzlibかgzipで圧縮されている
ファイルの初めは無名(名前の長さが0)のTAG_Compound(typeID:10)で始まっている
Java版のNBTファイルの数値はすべてビッグエンディアンです
またBedrockエディションのNBTファイルはちょっと違います
(BedrockのNBTファイルを扱ったことはないので….)
Bedrockはこんな感じの仕様みたいです