扩展名无法告诉你原理图格式 — 33 个 .schematic 文件中有 31 个是其他格式的猜测
五种格式，四种不同的方块打包方式，而 .schematic 扩展名被其中两种共享。嗅探 NBT 根目录比相信文件名更可靠，有实际证据支持。
市面上有五种原理图格式，而文件名只是一个提示，而非事实。 这里的查看器通过查看文件内部来决定文件的格式，这样做是有充分理由的。
五种格式，五种扩展名
| 扩展名 | 格式 |
|---|---|
.nbt | 原版结构 |
.schem | Sponge |
.schematic | Sponge — 默认 |
.litematic | Litematica |
.mcstructure | 基岩 |
问题出在 .schematic 这一行。这个扩展名被 经典 MCEdit 格式和 Sponge 格式共享，而文件经常被那些不知情或不在乎的人随意重命名。
根据真实语料库统计：在 33 个 .schematic 文件中，有 31 个是 MCEdit 格式，1 个是原版结构 格式，1 个是 Litematica 格式。因此，扩展名的默认猜测对于几乎所有文件都是错误的，并且 有两个文件根本不是 .schematic 格式——只是被错误命名了。
解决方法是嗅探 NBT 根目录，让文件实际的格式优先于它的名称：
- 存在
Regions键 → Litematica - 存在
palette和blocks→ 原版结构 - 否则进行 MCEdit 形状测试，然后回退到扩展名判断
四种打包相同方块的方式
这些格式在外观上没有区别。每种格式都以真正不同的方式存储方块数据，每种选择都有其后果：
原版 .nbt — 稀疏列表。 每个放置的方块一个条目，每个条目指定一个调色板索引。空气 简单地不存在，因此空心建筑成本较低。
Sponge .schem — 变长整数流。 调色板索引被打包为可变宽度的整数：每个字节七位有效载荷， 高位设置为继续。小型调色板每个方块占用一个字节；超过 127 个条目的调色板对于高索引开始占用两个字节。 密集，但自描述。
MCEdit .schematic — 平面字节数组。 每个方块一个字节，因此最多 256 种方块类型 ——这正是它需要一个 AddBlocks 侧数组的原因，该数组将第九位作为每个方块的半字节打包。 这是一种在方块状态出现之前的旧版数字 ID 格式，其 ID 通过一个 SchematicaMapping 复合标签解析，而不是名称。
Litematica .litematic — 位打包长整数。 索引以精确的 max(2, bits needed for the palette) 位打包，最低有效位优先，一个条目可能跨越两个长整数的边界。 一个 5 个条目的调色板每个方块使用 3 位；一个 300 个条目的调色板使用 9 位。
2 位的下限很重要：即使是两个方块的调色板也无法压缩到每个条目 2 位以下， 因此单色建筑并不像数学计算的那样小。
基岩是小端序
.mcstructure 在较低级别上是异类：基岩写入小端序 NBT，而所有 Java 格式都写入大端序。 这在任何格式解析发生之前就已经决定了——如果以错误的字节序读取字节，你不会得到错误的结构， 你会得到根本无法解析的垃圾。
这在实践中意味着什么
如果一个原理图无法在某个地方打开，第一个问题不是“文件是否损坏”，而是“这个文件是否与其名称相符”。 从下载页面获得的 .schematic 文件更有可能是 MCEdit 格式而不是 Sponge 格式， 而信任扩展名的工具会拒绝一个完全正常的文件。
当比较同一建筑的两个导出文件时，大小差异主要与编码有关，而不是内容—— 一个空心建筑的稀疏原版 .nbt 和相同建筑的位打包 .litematic 正在解决不同的问题。