指南 / 建筑与资源

纤细还是经典：游戏读取你的账号，而工具只能从 24 个像素里猜

游戏从账号的皮肤设置中读取纤细或经典模型，而不是从 PNG 文件里读。只拿到一张裸 PNG 的工具，只能靠纤细手臂留下的两列空白来猜。另外还有完整的 UV 映射表，以及为什么旧版 64×32 皮肤会被镜像。

2026-08-01

皮肤 PNG 里没有任何东西写着“纤细”。没有标志位，也没有文件名约定——游戏也从不查看像素来判断。它从你的账号附加到皮肤上的 model 设置中获取模型（也就是你上传皮肤时做的选择），而一个没有皮肤的档案会从 18 款默认皮肤中获得一款，9 款纤细、9 款经典，由 UUID 决定。

只有拿到裸 PNG 的工具——编辑器、材质包构建器、查看器——才不得不推断模型，而它的做法是查看一个特定的 2 × 12 矩形，并数一数其中到底有多少像素存在。

判定方法

sample  x 54–55, y 20–31        — 2 wide, 12 tall = 24 pixels
count   pixels with alpha > 0
slim    if fewer than 6 are opaque

经典手臂宽 4 像素；纤细手臂宽 3 像素。纤细手臂的各面被压缩得窄了一像素，所以侧面和背面会向左移，手臂区域的最后两列，即 x 54–55，就被留空了。在 Mojang 自家的默认皮肤上，那个矩形在全部九款纤细皮肤上都是 24 个像素中 0 个不透明，在全部九款经典皮肤上都是 24 个中 24 个——二十四个像素足以分辨。

阈值是 24 个中的 6 个，而不是 1 个——这一列必须有四分之一被填满，才算作经典。这个容差很重要：一款纤细皮肤即使在死列里有几个零散像素，仍然会被读作纤细，而这正是你想要的，因为那些零散像素几乎总是编辑失误，而不是有意为之。

这也意味着失败模式很安静。如果你画了一款经典皮肤，但只是轻微用到那几列——一条细轮廓、几个阴影像素——你就可能低于 6，被自动判定为纤细，白白损失一像素的手臂宽度，而且没有任何解释。如果一款皮肤在工具里出来的模型不对，那几列就是该检查的地方——而在游戏里，该检查的是你账号上的设置。

完整的 UV 映射

皮肤的每一部分都是一个固定矩形，而每一部分在整张图的别处都有一个叠加层：

六个叠加层中有五个恰好距其基础 16 像素——但方向并不相同。 三个原始部位是向下 16。左臂和左腿是后来加入的，被挤进下半部分，那里下方没有空间，于是改为向侧面 16——而且彼此方向相反。

帽子是唯一一个完全不是 16 距离的：它在向右 32，与头部同一行。

所以“叠加层在基础下方”这条规则只对整张图的一半成立。复制一个基础矩形并向下偏移来找到它的叠加层，对身体、右臂和右腿有效，而对另外三个会悄悄落到错误的部位上。

在纤细皮肤上，每个 4 宽的手臂矩形都会被读作 3 宽。正面不会移动，但它们之后的一切都会：侧面和背面各自向左移一像素，而背面窄了一像素，这正是 x 54–55 被留空的原因。

旧版 64 × 32 根本没有左侧

1.8 之前的皮肤是 64 × 32——整张图的下半部分根本不存在，而左臂和左腿就住在那里。没有任何东西可以从中绘制它们。

解决办法是镜像：右腿 (0, 16) 被复制到 (16, 48)，右臂 (40, 16) 被复制到 (32, 48)，两者都水平翻转。这就是为什么旧皮肤完全对称，而现代皮肤不必如此——不对称是 64 × 32 格式唯一无法表达的东西，而你转换的任何旧皮肤都会被强加对称性，不管它愿不愿意。

128 × 128 的编辑器文件是同一套布局，两倍大小

Java 接受 64 × 64 或旧版 64 × 32，拒绝其他任何尺寸。本站的 Bedrock 皮肤编辑器以 128 × 128 工作，不接受其他任何尺寸——但那个文件是同一套 UV 布局以两倍分辨率绘制的，每个部位都是 Java 坐标的两倍，而不是另一种格式。

壁垒在工具里，而不在布局里。每个编辑器构建的纹理管线都按自己的数字设定尺寸，所以两者都打不开对方的文件，而一张 128 × 128 的 PNG 交给 Java 会被拒绝，而不是以一半大小显示。转换就是机械式的 2× 缩放，这就是为什么皮肤编辑器把两者当作独立的构建，而不是同一块画布。

头像制作器 →