Guías / Comandos y datos

Cabezas de jugador por nombre de usuario: cómo funciona el componente de perfil y por qué las cabezas se quedan en blanco

Una cabeza almacena una instantánea de la skin, no un vínculo en vivo. Aquí está el componente de perfil, por qué una cabeza antigua muestra la skin equivocada y cómo encaja la búsqueda de UUID.

2026-06-30

Dar la cabeza de un jugador suena a que debería ser un solo argumento. Lo es, pero lo que se almacena no es lo que la gente espera, y eso explica la mayoría de las rarezas relacionadas con las cabezas.

El comando

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

El componente profile reemplazó al antiguo NBT SkullOwner. Los fragmentos que usan {SkullOwner:"Notch"} son anteriores a 1.20.5 y ya no hacen nada.

Qué se almacena realmente

Una cabeza dada como profile="Notch" almacena solo el nombre. Es un perfil dinámico —la descripción del objeto lo indica— y el cliente de cada jugador busca el nombre y obtiene la skin cuando dibuja la cabeza. Una cabeza lleva una instantánea fija solo cuando su perfil incluye la textura en sí:

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

Dos consecuencias:

• Una cabeza basada en nombre sigue la skin actual del jugador. Se vuelve a buscar cuando se dibuja; el cliente conserva una skin buscada hasta que ha estado sin usarse durante cinco minutos. Solo una cabeza que lleva una propiedad textures está congelada a una skin.
• Donde se resuelve es la máquina del espectador. Una cabeza con una propiedad textures incorporada se renderiza sin ninguna búsqueda. Una cabeza basada en nombre depende de que el cliente de cada espectador llegue a Mojang, no del modo online del servidor.

Por qué una cabeza está en blanco o muestra a Steve

Por orden de probabilidad:

1. El nombre no se resolvió para este cliente. La API de Mojang era inaccesible, o la búsqueda sigue pendiente; la cabeza muestra una skin predeterminada hasta que se resuelva.
2. El nombre no existe. Mojang no devuelve nada para cuentas eliminadas o que nunca se registraron.
3. Todavía se está resolviendo. La búsqueda se ejecuta en segundo plano, así que una cabeza puede mostrar una predeterminada durante un momento después de aparecer por primera vez en pantalla.

Una cabeza basada en nombre se reintenta por sí sola una vez que caduca su entrada de caché. Para congelar una skin en su lugar, da la cabeza con su propiedad textures — /fetchprofile name <name> resuelve a un jugador y ofrece el componente completo para copiar, o una cabeza ya hecha para dar.

Las cabezas personalizadas usan la textura, no un nombre

Las cabezas decorativas —muebles, comida, cabezas de criaturas de catálogos— no tienen dueño. Llevan solo el valor de textura properties con un blob en base64 que apunta a una URL de textura. Por eso son compartibles como un único comando give largo y por eso nunca se rompen cuando un jugador cambia de nombre.

El base64 se decodifica a un pequeño JSON que contiene un textures.SKIN.url en textures.minecraft.net. Nada más en él importa para el renderizado.

Formatos de UUID

Existen dos formas y no son intercambiables en todos los contextos:

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

Los comandos y el NBT generalmente quieren la forma con guiones o un arreglo de enteros. Las API web normalmente devuelven la recortada. Convertir entre ellas es mecánico: inserta guiones después de 8, 12, 16 y 20 caracteres.

Da una cabeza a partir de un nombre de usuario, explora catálogos de cabezas decorativas o convierte entre formatos de UUID en las Herramientas de cabeza de jugador y nombre de usuario.

Cabezas y nombres de jugador →