Protocol FAQ:zh-cn

有人一直问我们关于Minecraft: Java Edition的协议的问题,所以我们将尝试在本文档中解决一些最常见的问题.如果你仍然有问题,请加入我们的IRC频道,irc.libera.chat上的#mcdevs.

协议文档是否完整?

根据你的定义,完整!所有的数据包类型都是已知的,它们的布局也有记录.虽说缺少一些细枝末节,但制作功能性程序所需的一切都有了.我们还收集了Pre-release协议变化的信息,使我们能够快速记录新的版本.

客户端正常的登录顺序是什么?

关于与Mojang服务器的通信,请参阅认证.

建议的登录顺序如下,C代表客户端S代表服务端:

1. 客户端连接到服务端
2. C→S: 握手 State=2
3. C→S: 开始登录
4. S→C: 加密请求
5. 客户端验证
6. C→S: 加密响应
7. 服务端验证(此时CS的连接均为加密)
8. S → C: 设置压缩 (可选,启用压缩)
9. S → C: 完成登录
10. S → C: 加入游戏
11. S → C: Plugin Message: minecraft:brand with the server's brand (可选)
12. S → C: Server Difficulty (Optional)
13. S → C: Player Abilities (Optional)
14. C → S: Plugin Message: minecraft:brand with the client's brand (可选)
15. C → S: Client Settings
16. S → C: Held Item Change
17. S → C: Declare Recipes
18. S → C: Tags
19. S → C: Entity Status (for the OP permission level; see Entity statuses#Player)
20. S → C: Declare Commands
21. S → C: Unlock Recipes
22. S → C: Player Position And Look
23. S → C: Player Info (Add Player action)
24. S → C: Player Info (Update latency action)
25. S → C: Update View Position
26. S → C: Update Light (One sent for each chunk in a square centered on the player's position)
27. S → C: Chunk Data (One sent for each chunk in a square centered on the player's position)
28. S → C: World Border (Once the world is finished loading)
29. S → C: Spawn Position (“home” spawn, not where the client will spawn on login)
30. S → C: Player Position And Look (Required, tells the client they're ready to spawn)
31. C → S: Teleport Confirm
32. C → S: Player Position And Look (to confirm the spawn position)
33. C → S: Client Status (sent either before or while receiving chunks, further testing needed, server handles correctly if not sent)
34. S → C: inventory, entities, etc

What does the normal status ping sequence look like?

When a Notchian client and server exchange information in a status ping, the exchange of packets will be as follows:

1. C → S: Handshake with Next State set to 1 (Status)
2. Client and Server set protocol state to Status.
3. C → S: Request
4. S → C: Response
5. C → S: Ping
6. S → C: Pong
7. S → ❌: Server terminates connection to client

(Note that C is the Notchian client and S is the Notchain server).

离线模式

If the server is in offline mode, it will not send the Encryption Request packet, and likewise, the client should not send Encryption Response. In this case, encryption is never enabled, and no authentication is performed.

Clients can tell that a server is in offline mode if the server sends a Login Success without sending Encryption Request.

I think I've done everything right, but…

…my player isn't spawning!

After sending the common-sense packets (Handshake, Login Start, inventory, compass, and chunks), you need to finally send the player their initial position for them to leave the “Loading Map” screen.

Note that if the following steps are taken, a Minecraft client will spawn the player:

1. Do Handshake (see Protocol Encryption)
2. Send Spawn Position packet
3. Send Player Position And Look (clientbound) packet

While the above steps are sufficient for Minecraft 1.4.5, it is good form to send packets that inform the client about the world around the player before allowing the player to spawn.

…my client isn't receiving complete map chunks!

Main article: How to Write a Client

The standard Minecraft server sends full chunks only when your client is sending player status update packets (any of Player (0x03) through Player Position And Look (0x06)).

…all connecting clients spasm and jerk uncontrollably!

For newer clients, your server needs to send 49 chunks ahead of time, not just one. Send a 7×7 square of chunks, centered on the connecting client's position, before spawning them.

…the client is trying to send an invalid packet that begins with 0xFE01

The client is attempting a legacy ping, this happens if your server did not respond to the Server List Ping properly, including if it sent malformed JSON.

…the client disconnects after some time with a "Timed out" error

The server is expected to send a Keep Alive packet every 1-15 seconds (if the server does not send a keep alive within 20 seconds of state change to Play, the client will disconnect from the server for Timed Out), and the client should respond with the serverbound version of that packet. If either party does not receive keep alives for some period of time, they will disconnect.

...my client isn't sending a Login Start packet!

The Notchian client may group packets if the size of the packet and delay between the last packet are too small. To solve this issue, you must use the Packet Length to infer there is another packet by comparing it and the data length.

	The following information needs to be added to this page:
	Pseudo code example on how to parse a grouped packet?

How do I open/save a command block?

The process to actually open the command block window clientside is somewhat complex; the client actually uses the Update Block Entity (0x09) packet to open it.

First, the client must have at least an OP permission level of 2, or else the client will refuse to open the command block. (The op permission level is set with the Entity Status packet)

To actually open the command block:

1. C→S: Player Block Placement (0x1C), with the position being the command block that was right-clicked.
2. S→C: Update Block Entity (0x09), with the NBT of the command block.

And to save it, use the MC|AutoCmd plugin channel.