أدلة / الأوامر والبيانات

رؤوس اللاعبين حسب اسم المستخدم: كيف يعمل مكوّن الملف الشخصي ولماذا تصبح الرؤوس فارغة

يحتفظ الرأس بلقطة جلدية ثابتة، لا برابط حي. إليك مكوّن الملف الشخصي، ولماذا يُظهر رأس قديم الجلد الخطأ، وكيف يتناسب البحث عن UUID مع ذلك.

2026-06-30

قد يبدو إعطاء رأس لاعب أمرًا يتطلب وسيطًا واحدًا فقط. وهو كذلك بالفعل، لكن ما يُخزَّن ليس ما يتوقعه الناس، وهذا يفسّر معظم الغرائب المتعلقة بالرؤوس.

الأمر

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

استبدل المكوّن profile بيانات NBT القديمة SkullOwner. المقاطع التي تستخدم {SkullOwner:"Notch"} تعود لما قبل 1.20.5 ولا تفعل شيئًا الآن.

ما يُخزَّن فعليًا

الرأس المُعطى بصيغة profile="Notch" يخزّن الاسم فقط. إنه ملف شخصي ديناميكي — وهذا ما يذكره تلميح الأداة الخاص بالعنصر — ويبحث عميل كل لاعب عن الاسم ويجلب الجلد عند رسم الرأس. ولا يحمل الرأس لقطة ثابتة إلا عندما يتضمن ملفه الشخصي النسيج نفسه:

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

نتيجتان مترتبتان على ذلك:

• الرأس المعتمد على الاسم يتبع الجلد الحالي للاعب. يُعاد البحث عنه عند رسمه؛ ويحتفظ العميل بالجلد الذي بحث عنه حتى يمضي خمس دقائق دون استخدامه. ولا يُجمَّد الرأس على جلد واحد إلا إذا حمل خاصية textures.
• مكان تحديد الهوية هو جهاز المشاهد. الرأس الذي يحمل خاصية textures مضمّنة يُرسم دون أي بحث على الإطلاق. أما الرأس المعتمد على الاسم فيعتمد على وصول عميل كل مشاهد إلى Mojang، لا على وضع الاتصال بالإنترنت الخاص بالخادم.

لماذا يكون الرأس فارغًا أو يظهر ستيف

بحسب ترتيب الاحتمالات:

1. لم يُحدَّد الاسم لهذا العميل. تعذّر الوصول إلى واجهة Mojang البرمجية، أو أن البحث لا يزال معلّقًا؛ ويُظهر الرأس جلدًا افتراضيًا حتى يكتمل.
2. الاسم غير موجود. لا تُرجع Mojang شيئًا للحسابات المحذوفة أو التي لم تُسجَّل قط.
3. لا يزال قيد التحديد. يجري البحث في الخلفية، لذا قد يُظهر الرأس الجلد الافتراضي للحظة بعد ظهوره لأول مرة.

يعيد الرأس المعتمد على الاسم المحاولة من تلقاء نفسه بمجرد انتهاء صلاحية مدخل ذاكرته المؤقتة. ولتجميد جلد بدلًا من ذلك، أعطِ الرأس مع خاصية textures — يحلّ /fetchprofile name <name> ملف لاعب و يعرض المكوّن الكامل لنسخه، أو رأسًا جاهزًا لإعطائه.

الرؤوس المخصصة تستخدم النسيج، لا الاسم

الرؤوس الزخرفية — الأثاث والطعام ورؤوس الكائنات من الكتالوجات — ليس لها مالك. إنها تحمل قيمة النسيج properties فقط مع كتلة base64 تشير إلى رابط نسيج. ولهذا يمكن مشاركتها كأمر إعطاء طويل واحد، ولهذا لا تتعطل أبدًا عندما يغيّر لاعب اسمه.

تفكّ شيفرة base64 إلى JSON صغير يحتوي على textures.SKIN.url على textures.minecraft.net. ولا يهم أي شيء آخر فيه لأجل الرسم.

صيغ UUID

توجد صيغتان وهما غير قابلتين للتبادل في كل سياق:

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

الأوامر وبيانات NBT تريد عمومًا الصيغة ذات الشرطات أو مصفوفة أعداد صحيحة. أما واجهات الويب البرمجية فتُرجع عادةً الصيغة المقتطعة. والتحويل بينهما آلي — أدخل شرطات بعد 8 و12 و16 و 20 حرفًا.

أعطِ رأسًا من اسم مستخدم، أو تصفّح كتالوجات الرؤوس الزخرفية، أو حوّل بين صيغ UUID في أدوات رأس اللاعب واسم المستخدم.

أدوات رؤوس اللاعبين وأسمائهم →