海绵和结构方块并不是同一种文件
.schem、.litematic 和 Bedrock 的 .mcstructure 看起来可以互换，直到你转换之后发现所有箱子、实体和方块状态都消失了。
.schem 和 .litematic 都能保存建筑，而大多数玩家正是在两者之间转换时才发现，这两种格式对“建筑”究竟是什么从未达成一致。一种存储的是一个方块区域，另一种存储的是一段放置历史。把一座小镇从一种格式搬到另一种，房子能留下来，里面的东西却留不住。
每种格式究竟携带了什么
| 格式 | 运行平台 | 方块状态 | 方块实体 | 实体 |
|---|---|---|---|---|
.schem | Java、WorldEdit/Sponge | 是 | 是 | 是 |
.litematic | Java、Litematica | 是 | 是 | 是 |
.nbt 结构 | Java、结构方块 | 是 | 是 | 是 |
.mcstructure | Bedrock | 是 | 是 | 是 |
这些列看起来一模一样，而这就是陷阱所在。真正的差别在于调色板处理方式和坐标空间，而不是功能列表。
调色板才是脆弱的部分
上述每一种格式都把方块存储为指向调色板 (palette) 的索引——调色板是文件所用到的唯一方块类型列表，每个位置存一个指向该列表的数字。一个使用了几百种不同方块类型的建筑，其调色板就有那么大，而位置本身只是一堆整数。
这意味着，只有当读取方能够解析调色板中的每一个条目时，文件才是可读的。较新 Java 版本中加入的方块在 Bedrock 中根本没有对应物，因此 Java 转 Bedrock 时必须替换或丢弃它。空气是最常见的替代品，一面莫名其妙缺了方块的墙几乎总是这个原因，而不是文件损坏。
Java 和 Bedrock 对同一个方块的命名不同
这才是 Java 和 Bedrock 真正分道扬镳的地方。Bedrock 把方块状态写成 block_type 加一组键值状态；Java 则写成命名空间 ID 加状态映射。同一个实体方块，在一侧可能是 minecraft:oak_stairs[facing=east,half=bottom]，在另一侧却是一组顺序不同的状态。
楼梯、台阶、栅栏、墙、门和红石元件是最容易出问题的一批。转换后上下颠倒的楼梯是状态顺序不匹配，而不是文件有问题。
结构方块存储的东西和你想的不一样
结构方块保存为 .nbt 时写入的是一个包围盒，而这个盒子在每个轴向上都有硬性尺寸上限。比盒子更大的建筑不会被保存为单个文件——游戏会拆分它，或者直接拒绝。如果转换后的建筑缺了远端，先检查原来的盒子，再怀疑转换器。
在上述所有格式中，实体都是与方块分开存储的。物品展示框、盔甲架、画和生物都不是方块，只遍历方块调色板的转换器会把它们悄悄丢掉。
先预览，再信任
材料清单是最快的检查手段：如果转换后文件的方块数量与原文件对不上，那就说明有东西被替换了。图层预览能立刻看出这一点，一次一个水平切片，无需把建筑加载进世界。
在 .litematic、.schem、Java 结构 .nbt 和 Bedrock .mcstructure 之间转换，支持图层预览和材料清单，尽在原理图转换器。