Guias / Comandos e dados

A extensão não revela o formato do schematic — 31 de 33 arquivos .schematic eram o palpite de outra coisa

Cinco formatos, quatro maneiras diferentes de empacotar blocos, e o .schematic é compartilhado por dois deles. Farejar a raiz NBT vence confiar no nome do arquivo, com evidências contadas.

2026-08-01

Existem cinco formatos de schematic em circulação, e o nome do arquivo é uma pista, não um fato. O visualizador aqui decide o que um arquivo é olhando dentro dele, e há um motivo mensurável para isso.

Cinco formatos, cinco extensões

A linha problemática é a .schematic. Essa extensão é compartilhada pelo formato MCEdit clássico e pelo do Sponge, e os arquivos são renomeados por pessoas que não sabem ou não se importam.

Contado em um corpus real: de 33 arquivos .schematic, 31 eram MCEdit, um era uma estrutura vanilla e um era um Litematica. Ou seja, o palpite padrão da extensão erra para quase todos eles, e dois arquivos não eram .schematic em sentido algum — apenas estavam com o nome errado.

A solução é farejar a raiz NBT e deixar o que o arquivo é vencer o que ele é chamado:

• uma chave Regions → Litematica
• palette e blocks → estrutura vanilla
• caso contrário, o teste de forma do MCEdit, e então recorre à extensão

Quatro maneiras de empacotar os mesmos blocos

Os formatos não diferem só na aparência. Cada um armazena os dados de bloco de uma maneira genuinamente diferente, e cada escolha tem uma consequência:

Vanilla .nbt — uma lista. Uma entrada por posição salva, cada uma indicando um índice da paleta. O ar é armazenado como qualquer outro bloco; só o vazio estrutural fica de fora, então uma construção oca só é barata se o interior foi preenchido com vazio antes de salvar.

Sponge .schem — um fluxo varint. Índices de paleta empacotados como inteiros de largura variável: sete bits de carga útil por byte, com o bit alto ligado para continuar. Paletas pequenas custam um byte por bloco; uma paleta com mais de 127 entradas começa a custar dois bytes para os índices altos. Compacto, mas autodescritivo.

MCEdit .schematic — um array plano de bytes. Um byte por bloco, ou seja, no máximo 256 tipos de bloco — e é exatamente por isso que ele tem um array lateral opcional AddBlocks que adiciona mais quatro bits de id como um nibble por bloco, fazendo os ids chegarem a 4.095. Esse é um formato legado de ids numéricos, de antes dos estados de bloco: seus ids são números, resolvidos por um composto SchematicaMapping quando o Schematica gravava um, e pela tabela de ids vanilla da 1.12 caso contrário.

Litematica .litematic — longs empacotados em bits. Os índices são empacotados com exatamente max(2, bits needed for the palette) bits cada, começando pelo bit menos significativo, e uma entrada pode atravessar a fronteira entre dois longs. Uma paleta de 5 entradas usa 3 bits por bloco; uma de 300 entradas usa 9.

O piso de 2 bits importa: nem mesmo uma paleta de dois blocos comprime abaixo de 2 bits por entrada, então uma construção monocromática não é tão pequena quanto a matemática sugere.

Bedrock é little-endian

.mcstructure é o diferente em um nível mais baixo: o Bedrock grava NBT little-endian, enquanto todo formato Java grava big-endian. Isso é decidido antes de qualquer análise de formato acontecer — leia os bytes com o endianness errado e você não obtém uma estrutura errada, obtém lixo que não é analisado de forma alguma.

O que isso significa na prática

Se um schematic não abre em algum lugar, a primeira pergunta não é "o arquivo está corrompido", mas "esse arquivo é o que o nome dele diz". Um .schematic vindo de uma página de download tem muito mais chance de ser MCEdit do que Sponge, e uma ferramenta que confia na extensão vai rejeitar um arquivo perfeitamente bom.

E ao comparar duas exportações da mesma construção, as diferenças de tamanho são principalmente sobre codificação, não conteúdo — um .nbt vanilla com vazio de uma construção oca e um .litematic empacotado em bits da mesma coisa estão resolvendo problemas diferentes.

Visualizador 3D de schematics →