海绵和结构方块并非同一种文件
一个 .schem、一个 .litematic 和一个基岩版的 .mcstructure 看起来可以互换，直到你转换之后发现所有箱子、实体和方块状态都消失了。差别在于调色板和坐标空间；结构方块保存的 .nbt 每轴最多只有 48 格。
一个 .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]，在另一侧则是 weirdo_direction 加 upside_down_bit——状态名和值都不同，而不是同一组东西换了顺序。
楼梯、台阶、栅栏、墙、门和红石元件是容易翻转的那些。转换后上下颠倒的楼梯是状态映射错误，而不是文件有问题。
结构方块存储的东西和你想的不一样
结构方块保存到 .nbt 时会写入一个边界框，而该框每条轴上限为 48 个方块。游戏不会拆分更大的建筑——框外的一切根本不在文件里。如果转换后的建筑缺了远端，先检查原始边界框，再怀疑转换器。
在所有这些格式中，实体都与方块分开存储。物品展示框、盔甲架、画和生物不是方块，只遍历方块调色板的转换器会悄悄丢掉它们。
信任之前先预览
材料列表是最快的检查手段：如果转换后文件的方块数量与原始文件不符，说明有东西被替换了。图层预览会立刻显示出来，一次一个水平切片，无需把建筑加载进世界。
在 .litematic、.schem、Java 结构 .nbt 和 Bedrock .mcstructure 之间转换，附带图层预览和材料列表，尽在 Schematic Converter。