Guias / Comandos e dados

Cabeças de Jogador por nome de usuário: como o componente de perfil funciona e por que as cabeças ficam em branco

Uma cabeça armazena um instantâneo da skin, não um vínculo ativo. Veja aqui o componente de perfil, por que uma cabeça antiga mostra a skin errada e como a consulta de UUID se encaixa nisso.

2026-06-30

Dar a cabeça de um jogador parece que deveria ser um único argumento. E é, mas o que fica armazenado não é o que as pessoas esperam, e isso explica a maioria das esquisitices relacionadas a cabeças.

O comando

/give @p player_head[profile="Notch"]

O componente profile substituiu o antigo SkullOwner do NBT. Trechos que usam {SkullOwner:"Notch"} são anteriores à 1.20.5 e não fazem mais nada agora.

O que realmente fica armazenado

Uma cabeça dada como profile="Notch" armazena apenas o nome. É um perfil dinâmico — a dica do item diz isso — e o cliente de cada jogador consulta o nome e busca a skin quando desenha a cabeça. Uma cabeça carrega um instantâneo fixo somente quando seu perfil inclui a própria textura:

"profile": {
  "name": "Notch",
  "id": [I; …],
  "properties": [{ "name": "textures", "value": "<base64>" }]
}

Duas consequências:

• Uma cabeça baseada em nome acompanha a skin atual do jogador. Ela é consultada de novo quando é desenhada; o cliente mantém uma skin consultada até ela ficar sem uso por cinco minutos. Só uma cabeça que carrega uma propriedade textures fica congelada em uma única skin.
• Onde ela é resolvida é a máquina de quem visualiza. Uma cabeça com uma propriedade textures embutida é renderizada sem nenhuma consulta. Uma cabeça baseada em nome depende de o cliente de cada observador conseguir alcançar a Mojang, não do modo online do servidor.

Por que uma cabeça fica em branco ou mostra o Steve

Em ordem de probabilidade:

1. O nome não foi resolvido para este cliente. A API da Mojang estava inacessível, ou a consulta ainda está pendente; a cabeça mostra uma skin padrão até que isso aconteça.
2. O nome não existe. A Mojang não retorna nada para contas excluídas ou que nunca foram registradas.
3. Ainda está resolvendo. A consulta roda em segundo plano, então uma cabeça pode mostrar o padrão por um momento depois de entrar em vista pela primeira vez.

Uma cabeça baseada em nome tenta de novo sozinha quando sua entrada de cache expira. Para congelar uma skin, em vez disso, dê a cabeça com sua propriedade textures — /fetchprofile name <name> resolve um jogador e oferece o componente completo para copiar, ou uma cabeça pronta para dar.

Cabeças personalizadas usam a textura, não um nome

Cabeças decorativas — móveis, comida, cabeças de criaturas de catálogos — não têm dono. Elas carregam apenas o valor de textura properties com um blob em base64 apontando para uma URL de textura. É por isso que elas são compartilháveis como um único comando give longo e por que nunca quebram quando um jogador muda de nome.

O base64 é decodificado em um pequeno JSON contendo um textures.SKIN.url em textures.minecraft.net. Nada mais nele importa para a renderização.

Formatos de UUID

Existem duas formas e elas não são intercambiáveis em todo contexto:

trimmed   069a79f444e94726a5befca90e38aaf5
dashed    069a79f4-44e9-4726-a5be-fca90e38aaf5

Comandos e NBT geralmente querem a forma com hífens ou um array de inteiros. APIs da web normalmente retornam a forma sem hífens. Converter entre elas é mecânico — insira hífens após 8, 12, 16 e 20 caracteres.

Dê uma cabeça a partir de um nome de usuário, navegue por catálogos de cabeças decorativas ou converta entre formatos de UUID nas Ferramentas de Cabeça de Jogador e Nome de Usuário.

Cabeças e nomes de jogador →