Guides / Commands & Data

通过用户名获取玩家的头颅：个人资料组件的工作原理及头颅变空白的原因

头颅存储的是皮肤快照，而非实时链接。本文将介绍个人资料组件、为何旧头颅会显示错误的皮肤，以及 UUID 查询如何融入其中。

2026-06-30

给予一个玩家的头颅听起来应该只需要一个参数。确实如此，但实际存储的内容却与人们的预期不同，这也解释了大多数与头颅相关的奇怪现象。

命令

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

profile 组件取代了旧的 SkullOwner NBT。使用 {SkullOwner:"Notch"} 的代码片段是 1.20.5 之前的版本，现在已无效。

实际存储的内容

头颅不存储用户名并在之后获取皮肤。当头颅被创建时，服务器会将名称解析为 UUID 和一个纹理快照，并将其烘焙到物品中：

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

由此产生两个结果：

• 一年前制作的头颅会显示当年的皮肤。 玩家更改皮肤不会更新世界中已有的头颅。这不是一个 bug，也没有刷新机制。
• 头颅可以离线工作。 一旦烘焙完成，渲染头颅就不需要 Mojang API 调用，这就是为什么头颅在离线模式服务器上仍然有效，而 /give ... profile="Name" 在那里无法解析的原因。

为什么头颅会变空白或显示史蒂夫的皮肤

按可能性排序：

1. 名称未解析。 离线模式服务器，或者在命令运行时 API 无法访问。没有可烘焙的内容，因此你会得到一个默认头颅。
2. 名称不存在。 Mojang 不会为已删除或从未注册的账户返回任何内容。
3. 区块未重新加载。 头颅是异步解析的；偶尔你需要移开视线再看回来。

等待很少有帮助——如果个人资料在创建时没有烘焙，它就会保持空白。重新给予头颅即可。

自定义头颅使用纹理，而非名称

装饰性头颅——家具、食物、目录中的生物头颅——没有所有者。它们只携带 properties 纹理值，其中包含一个指向纹理 URL 的 base64 blob。这就是为什么它们可以作为单个长给予命令共享，以及为什么当玩家改名时它们永远不会损坏。

base64 解码后会得到一个包含 textures.SKIN.url 的小 JSON，位于 textures.minecraft.net。其中其他内容对渲染无关紧要。

UUID 格式

存在两种形式，它们并非在所有上下文中都可互换：

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

命令和 NBT 通常需要带连字符的形式或整数数组。Web API 通常返回不带连字符的形式。它们之间的转换是机械性的——在第 8、12、16 和 20 个字符后插入连字符即可。

在玩家头颅与用户名工具中，你可以通过用户名获取头颅、浏览装饰性头颅目录，或在 UUID 格式之间进行转换。

玩家头颅与用户名工具 →