.nbt 结构文件存储的是调色板索引，而不是方块名称——这正是它如此小巧的原因
三个键就能承载一整座建筑：size、palette 和 blocks。每个方块都是一个指向调色板的整数，因此一个 32³ 的石头体积只需要一个字符串和 32,768 条小记录——每条包含一个位置和一个索引，从不包含名称。
一个 .nbt 结构文件——也就是结构方块保存、数据包附带的那种东西——从外部看要比它实际复杂得多。一座建筑所需的一切都放在少数几个顶层键里，而正是其中一个设计决策解释了这些文件为何如此小巧。
承载整座建筑的三个键
size [x, y, z] — a list of exactly three integers
palette [ { Name, Properties } … ] — every DISTINCT block state, once
blocks [ { pos, state, nbt } … ] — one entry per placed blockpalette 将每一种不同的方块状态各保存一次。 一个条目是一个 Name——即方块 id，比如 minecraft:oak_stairs——外加一个可选的 Properties 复合标签，用于存放它的方块状态，例如 facing: north 和 half: bottom。
blocks 从不重复名称。 每个条目包含三个整数组成的 pos 和一个 state，而 state 是指向调色板的索引，不是方块 id。朝北的橡木楼梯只作为字符串数据出现一次，此后每一个都只是一个小整数。
这就是全部的诀窍。一个 32 × 32 × 32 的纯石头体积只有一个调色板条目和 32,768 条由位置加索引组成的方块记录——而不是 32,768 份 minecraft:stone 这个词的副本。调色板随你用了多少不同的东西而增长，方块列表则随你建得多大而增长。这是两个截然不同的数字，而通常只有其中一个会很大。
两个值得在设计时考虑的结果
方块状态会撑大你的调色板，而不是方块列表。 橡木楼梯不是一个调色板条目——你实际用到的每一种朝向都各占一个。四个朝向、上半和下半、直形以及内角和外角：同一个方块可以占据十几个调色板槽位。因此，细节繁多的建筑调色板很大，而朴素的建筑则不然，与大小无关。
只有被保存的位置才会有条目。 方块列表是一个列表，而不是稠密的三维数组，不存在的条目就是不存在——本页的查看器用 -1 填充它的网格，并把缺失的坐标视为没有放置任何东西。但结构方块会像保存其他方块一样保存空气；只有结构空位会被略去。只有在你保存前用结构空位填满内部时，中空的建筑存储起来才更省。
nbt 是逐方块的，且可选
blocks 中的每个条目都可以携带自己的 nbt 复合标签，而大多数都没有。箱子的内容物、告示牌的文字、刷怪笼的生物和旗帜的图案就存放在这里——附着在单个方块上，而不是调色板上。
这个区别很重要：调色板数据是共享的，而方块数据不是。 两个箱子是一个调色板条目，因为它们是相同的方块状态——但每个箱子都在自己的 nbt 里保存自己的物品栏。改变方块状态，你动的是调色板；改变里面的东西，你动的是方块列表中的某一个条目。
一次读取一层
这里的查看器刻意做成二维的。要绘制第 y 层，它会遍历方块列表，保留 pos[1] 等于 y 的条目，再把每个条目的 state 拿到调色板里查。这就是全部的算法，而它值得了解，因为这也是你自己检查这类文件的方式：没有需要构建的空间索引，除了 gzip 外壳之外也没有任何解压缩。这个格式就是一份供你筛选的扁平列表。
这也意味着结构文件不会告诉你它属于世界中的哪里。size 是一个包围盒，而 pos 的值都相对于它的角落。放置是结构方块的事，不是文件的事。