Anleitungen / Befehle & Daten

Spielerköpfe nach Benutzername: Wie die Profilkomponente funktioniert und warum Köpfe leer bleiben

Ein Kopf speichert einen Skin-Schnappschuss, keinen Live-Link. Hier ist die Profilkomponente, warum ein alter Kopf den falschen Skin zeigt und wie die UUID-Suche dazu passt.

2026-06-30

Einem Spieler einen Kopf zu geben klingt, als sollte es ein einziges Argument sein. Ist es auch, aber was gespeichert wird, entspricht nicht den Erwartungen – und das erklärt die meisten kopfbezogenen Merkwürdigkeiten.

Der Befehl

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

Die Komponente profile hat das alte SkullOwner-NBT ersetzt. Snippets, die {SkullOwner:"Notch"} verwenden, stammen aus der Zeit vor 1.20.5 und bewirken heute nichts mehr.

Was tatsächlich gespeichert wird

Ein Kopf, der als profile="Notch" vergeben wird, speichert nur den Namen. Es ist ein dynamisches Profil – das sagt auch der Tooltip des Gegenstands – und der Client jedes Spielers schlägt den Namen nach und lädt den Skin, wenn er den Kopf zeichnet. Ein Kopf trägt nur dann einen festen Schnappschuss, wenn sein Profil die Textur selbst enthält:

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

Zwei Konsequenzen:

• Ein namensbasierter Kopf folgt dem aktuellen Skin des Spielers. Er wird beim Zeichnen erneut nachgeschlagen; der Client behält einen nachgeschlagenen Skin, bis er fünf Minuten lang nicht verwendet wurde. Nur ein Kopf, der eine textures-Eigenschaft trägt, ist auf einen Skin eingefroren.
• Wo aufgelöst wird, ist der Rechner des Betrachters. Ein Kopf mit einer eingebackenen textures-Eigenschaft rendert ganz ohne Nachschlagen. Ein namensbasierter Kopf hängt davon ab, dass der Client jedes Betrachters Mojang erreicht – nicht vom Online-Modus des Servers.

Warum ein Kopf leer ist oder Steve zeigt

Nach Wahrscheinlichkeit geordnet:

1. Der Name wurde für diesen Client nicht aufgelöst. Mojangs API war nicht erreichbar, oder das Nachschlagen läuft noch; der Kopf zeigt einen Standardskin, bis es abgeschlossen ist.
2. Der Name existiert nicht. Mojang liefert nichts für gelöschte oder nie registrierte Konten zurück.
3. Wird noch aufgelöst. Das Nachschlagen läuft im Hintergrund, daher kann ein Kopf für einen Moment einen Standardskin zeigen, nachdem er erstmals ins Sichtfeld kommt.

Ein namensbasierter Kopf versucht es von selbst erneut, sobald sein Cache-Eintrag abläuft. Um stattdessen einen Skin einzufrieren, gib den Kopf mit seiner textures-Eigenschaft – /fetchprofile name <name> löst einen Spieler auf und bietet die vollständige Komponente zum Kopieren an, oder einen fertigen Kopf zum Vergeben.

Benutzerdefinierte Köpfe verwenden die Textur, nicht einen Namen

Dekorative Köpfe – Möbel, Essen, Mob-Köpfe aus Katalogen – haben keinen Besitzer. Sie tragen nur den Texturwert properties mit einem Base64-Blob, der auf eine Textur-URL verweist. Deshalb sind sie als einzelner langer Give-Befehl teilbar und gehen nie kaputt, wenn ein Spieler seinen Namen ändert.

Das Base64 dekodiert zu einem kleinen JSON, das eine textures.SKIN.url auf textures.minecraft.net enthält. Nichts anderes darin ist fürs Rendern von Bedeutung.

UUID-Formate

Es gibt zwei Formen, und sie sind nicht in jedem Kontext austauschbar:

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

Befehle und NBT wollen im Allgemeinen die Form mit Bindestrichen oder ein Integer-Array. Web-APIs geben üblicherweise die gekürzte Form zurück. Die Umwandlung ist mechanisch – Bindestriche nach 8, 12, 16 und 20 Zeichen einfügen.

Vergib einen Kopf anhand eines Benutzernamens, durchstöbere dekorative Kopf-Kataloge oder wandle zwischen UUID-Formaten um in den Player Head & Username Tools.

Spielerköpfe und Namen →