客户端怎样认出一个人：从服务器消息到人物资料与外观

01研究范围

你在画面上看见一个名字、一件武器和一位正在移动的人物，背后并不是服务器传来了一张完整图片。服务器先告诉客户端“谁在什么位置、朝向哪里、使用哪些外观编号”，客户端再到本地资源中寻找模型与图像。IKOK 的解析代码让这条对应关系变得可追溯，也解释了为什么“看见外观”与“知道完整人物属性”是两回事。

本篇依据 IKOK 已保存的解码与映射实现，以及 KOK 客户端 2.0.0.52 的离线资源整理。这里的编号与布局有明确版本范围，不据此断言 2001 年客户端或各服务器的所有消息都完全相同。

02先把通信、人物状态和画面分开

一条 TCP 连接传输的是连续字节流。一次接收可能只有半条游戏消息，也可能包含多条消息。IKOK 的实际接收入口会先保留尚未完整的字节，经过协议解码，再按消息头与内容长度拆分，最后交给对应的处理器。读取到一段文字，或在字节中发现某个熟悉的数字，并不足以确定它就是某个角色的属性。

拆分完成后，几种消息分别承担不同工作：

画面通常由这些状态共同组成。把某次“查看”的文字、自己的人物面板和附近人物的外观包混成一张表，会让字段看似齐全，实际上失去来源。

03名称、昵称与职业各有来源

MOB_IN 的内容起始处依次读取两字节 X、两字节 Y 和一字节方向；随后是以 NUL 结束的三个字符串：nick、名称和对象标识。三个字符串长度可变，所以后面的外观数据不能按某个固定的绝对字节位置硬取。

IKOK 在第三个字符串结束后，将余下完整的四字节组按大端整数保留为 mobTail。这种做法既提取已经认识的模型字段，也保留尚未完全解释的内容。中文长度变化时，只要字符串边界正确，后续字段仍能找到。

名称是人物本身的名称，nick 是另一项可自定义文字。两者不应互相替换。职业则来自当前角色的 0x000A 状态字符串，IKOK 将它写入自身人物的职业属性。附近人物的 MOB_IN 没有被解析出独立的结构化职业字段，因此不能仅凭它给所有路人标上职业。

例如，某个地图对象使用人形基础模型，只能说明它需要人形外观处理；穿着某职业常见的衣服，也不能把外形变成人物职业的证明。职业名出现在聊天、称号或描述中时，还要保留它原本的文字语境。

04人形尾字段怎样对应装备槽

当前 IKOK 的人形映射采用下面的对应表。方括号里的序号从零开始。

头、身体、副手、鞋、披风和主手这六个可见槽，已进入按槽位查表的实现。手套、项链和戒指在物品资料中存在，但当前这套人物外观结构没有给它们分配独立地图图层。物品存在、背包中有图标、穿上后有属性，并不必然意味着人物身上多画一层。

头脸组合尤其容易被过度解释：客户端确有头型、发型和材质资源，只能证明可选素材存在；要知道某个整数的哪几位选择哪一项，还需要独立对应证据。双持字段也一样，已有高可信解释的部分与尚未确定的高位标志应分别记录。

05读懂的是对应关系，不是所有玩法秘密

最有用的经验，是为每个结论留下完整的一条线：消息种类 → 字符串或整数边界 → 状态字段 → 本地资源 → 最终画面。中间任何一环只靠外观猜测，都不能倒推出装备属性、人物职业或服务器规则。

这也解释了换装研究为何要留意刷新时机：既有对应实验的记录指出，装备变动后，当前地图缓存不一定马上重建；换图后重新收到的 MOB_IN 才能作为新的完整外观对照。旧缓存不变，不能直接证明换装没有对应字段。

本文是对已有研究结论的整理，本次核对只读取静态代码与资源，没有接入游戏服务器或重演玩家通信。确认到哪里，就把对应关系写到哪里；未确定字段继续保留原值，不补成猜测的“完整协议”。