Difference between revisions of "Protocol FAQ:zh-cn"

From wiki.vg
Jump to navigation Jump to search
 
(9 intermediate revisions by the same user not shown)
Line 16: Line 16:
 
# 服务端验证(此时CS的连接均为加密)
 
# 服务端验证(此时CS的连接均为加密)
 
# '''S''' → '''C''': [[Protocol#Set Compression|设置压缩]] (可选,启用压缩)
 
# '''S''' → '''C''': [[Protocol#Set Compression|设置压缩]] (可选,启用压缩)
−
# '''S''' → '''C''': [[Protocol#Login Success|完成登录]]
+
# '''S''' → '''C''': [[Protocol#Login Success|登录完成]]
 
# '''S''' → '''C''': [[Protocol#Join Game|加入游戏]]
 
# '''S''' → '''C''': [[Protocol#Join Game|加入游戏]]
 
# '''S''' → '''C''': [[Protocol#Plugin Message (clientbound) |插件信息]]: [[Plugin channel#minecraft%3Abrand|<code>minecraft:brand</code>]]包含服务器的类型(可选)
 
# '''S''' → '''C''': [[Protocol#Plugin Message (clientbound) |插件信息]]: [[Plugin channel#minecraft%3Abrand|<code>minecraft:brand</code>]]包含服务器的类型(可选)
Line 26: Line 26:
 
# '''S''' → '''C''': [[Protocol#Declare Recipes|合成表]]
 
# '''S''' → '''C''': [[Protocol#Declare Recipes|合成表]]
 
# '''S''' → '''C''': [[Protocol#Tags|标签]]
 
# '''S''' → '''C''': [[Protocol#Tags|标签]]
−
# '''S''' → '''C''': [[Protocol#Entity Status|实体状态]] (为{{Minecraft Wiki|Server.properties#op-permission-level|OP权限级别}};见[[Entity statuses#Player]])
+
# '''S''' → '''C''': [[Protocol#Entity Status|实体状态]] (不是{{Minecraft Wiki|Server.properties#op-permission-level|OP权限级别}},这个才是[[Entity statuses#Player]])
 
# '''S''' → '''C''': [[Protocol#Declare Commands|命令]]
 
# '''S''' → '''C''': [[Protocol#Declare Commands|命令]]
 
# '''S''' → '''C''': [[Protocol#Unlock Recipes|解锁合成表]]
 
# '''S''' → '''C''': [[Protocol#Unlock Recipes|解锁合成表]]
Line 33: Line 33:
 
# '''S''' → '''C''': [[Protocol#Player Info|玩家信息]] (更新延时动作)
 
# '''S''' → '''C''': [[Protocol#Player Info|玩家信息]] (更新延时动作)
 
# '''S''' → '''C''': [[Protocol#Update View Position|更新视线位置]]
 
# '''S''' → '''C''': [[Protocol#Update View Position|更新视线位置]]
−
# '''S''' → '''C''': [[Protocol#Update Light|更新光照]] (One sent for each chunk in a square centered on the player's position)
+
# '''S''' → '''C''': [[Protocol#Update Light|更新光照]] (在以玩家位置为中心的正方形中,每个区块都发送一次.)
−
# '''S''' → '''C''': [[Protocol#Chunk Data|区块数据]] (One sent for each chunk in a square centered on the player's position)
+
# '''S''' → '''C''': [[Protocol#Chunk Data|区块数据]] (在以玩家位置为中心的正方形中,每个区块都发送一次.)
−
# '''S''' → '''C''': [[Protocol#World Border|世界边界]] (Once the world is finished loading)
+
# '''S''' → '''C''': [[Protocol#World Border|世界边界]] (一旦世界完成了加载)
−
# '''S''' → '''C''': [[Protocol#Spawn Position|出生位置]] (“家”出生点,不是客户端登录时的位置)
+
# '''S''' → '''C''': [[Protocol#Spawn Position|出生位置]] ("家"出生点,不是客户端登录时的位置)
 
# '''S''' → '''C''': [[Protocol#Player Position And Look (clientbound)|玩家位置和朝向]] (必须,告诉客户端已经准备好生成了)
 
# '''S''' → '''C''': [[Protocol#Player Position And Look (clientbound)|玩家位置和朝向]] (必须,告诉客户端已经准备好生成了)
 
# '''C''' → '''S''': [[Protocol#Teleport Confirm|传送确认]]
 
# '''C''' → '''S''': [[Protocol#Teleport Confirm|传送确认]]
Line 43: Line 43:
 
# '''S''' →  '''C''': 物品栏、实体...
 
# '''S''' →  '''C''': 物品栏、实体...
  
−
== What does the normal status ping sequence look like? ==
+
== 正常状态的ping顺序是什么样子的? ==
−
When a Notchian client and server exchange information in a status ping, the exchange of packets will be as follows:
+
当Notchian客户端和服务端在ping状态中交换信息时,数据包的交换情况如下:
  
−
# '''C''' → '''S''': [[Protocol#Handshake|Handshake]] with Next State set to 1 ([[Protocol#Status|Status]])
+
# '''C''' → '''S''': [[Protocol#Handshake|握手]] State=1
−
# Client and Server set protocol state to [[Protocol#Status|Status]].
+
# 服务端将协议State设置为1
−
# '''C''' → '''S''': [[Protocol#Request|Request]]
+
# '''C''' → '''S''': [[Protocol#Request|请求]]
−
# '''S''' → '''C''': [[Protocol#Response|Response]]
+
# '''S''' → '''C''': [[Protocol#Response|响应]]
 
# '''C''' → '''S''': [[Protocol#Ping|Ping]]
 
# '''C''' → '''S''': [[Protocol#Ping|Ping]]
 
# '''S''' → '''C''': [[Protocol#Pong|Pong]]
 
# '''S''' → '''C''': [[Protocol#Pong|Pong]]
−
# '''S''' → ❌: Server terminates connection to client
+
# '''S''' → ❌: 服务端终止与客户端的连接
−
 
 
−
(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 [[Protocol#Encryption Request|Encryption Request]] packet, and likewise, the client should not send [[Protocol#Encryption Response|Encryption Response]]. In this case, encryption is never enabled, and no authentication is performed.
+
如果服务端处于离线模式,则不会发送[[Protocol#Encryption Request|加密请求]]数据包并且客户端也不会发送[[Protocol#Encryption Response|加密响应]]数据包.在这种情况下,加密永远也不会被启用,也不进行认证.
  
−
Clients can tell that a server is in offline mode if the server sends a [[Protocol#Login Success|Login Success]] without sending [[Protocol#Encryption Request|Encryption Request]].
+
客户端可以判断出服务端是否处于离线模式,如果服务端直接发送了[[Protocol#Login Success|登录完成]]数据包而不发送[[Protocol#Encryption Request|加密请求]]数据包,则是离线模式,反之.
  
−
== I think I've done everything right, but… ==
+
== 我觉得我做好了,但是... ==
−
=== …my player isn't spawning! ===
+
=== ...我的玩家没有生成! ===
−
After sending the common-sense packets ([[Protocol#Handshake|Handshake]], [[Protocol#Login Start|Login Start]], [[Protocol#Window Items|inventory]], [[Protocol#Spawn Position|compass]], and [[Protocol#Chunk Data|chunks]]), you need to finally send the player their [[Protocol#Player Position And Look|initial position]] for them to leave the “Loading Map” screen.
+
在完成了基本操作之后([[Protocol#Handshake|握手]]、[[Protocol#Login Start|登录开始]]、[[Protocol#Window Items|物品栏]]、[[Protocol#Spawn Position|出生位置]]、[[Protocol#Chunk Data|区块]]),你需要发送玩家的[[Protocol#Player Position And Look|初始位置]]来让它们离开"Loading Map"界面.
  
−
''Note that if the following steps are taken, a Minecraft client will spawn the player:''
+
''请注意,如果采取以下步骤,Minecraft客户端将生成玩家:''
−
# Do Handshake (see [[Protocol Encryption]])
+
# 握手([[Protocol Encryption|协议加密]])
−
# Send [[Protocol#Spawn Position|Spawn Position]] packet
+
# 发送[[Protocol#Spawn Position|出生位置]]数据包
−
# Send [[Protocol#Player Position And Look (clientbound)|Player Position And Look (clientbound)]] packet
+
# 发送[[Protocol#Player Position And Look (clientbound)|玩家位置和朝向]]数据包
  
−
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.
+
虽然上述步骤对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]]''
+
''主要内容: [[How to Write a Client|如何写一个客户端]]''
  
−
The standard Minecraft server sends full chunks only when your client is sending player status update packets (any of [[Protocol#Player|Player (0x03)]] through [[Protocol#Player Position And Look|Player Position And Look (0x06)]]).
+
标准的Minecraft服务端只有在你的客户端发送玩家状态更新数据包时才会发送完整的数据块(any of [[Protocol#Player|玩家(0x03)]] through [[Protocol#Player Position And Look|玩家位置和朝向(0x06)]]).
  
−
=== …all connecting clients spasm and jerk uncontrollably! ===
+
=== ...所有连接的客户端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.
 
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 ===
+
=== ...客户端正试图发送一个以0xFE01开头的无效数据包. ===
 
The client is attempting a [[Server_List_Ping#1.6|legacy ping]], this happens if your server did not respond to the [[Server List Ping]] properly, including if it sent malformed JSON.
 
The client is attempting a [[Server_List_Ping#1.6|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 ===
+
=== ...客户端在一段时间后断开连接,并出现"Timed out"错误 ===
 
The server is expected to send a [[Protocol#Keep Alive (clientbound)|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.
 
The server is expected to send a [[Protocol#Keep Alive (clientbound)|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 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.
  
−
{{Need Info|Pseudo code example on how to parse a grouped packet?}}
+
{{Need Info|关于如何解析分组数据包的伪代码示例?}}
  
−
== 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 [[Protocol#Update Block Entity|Update Block Entity (0x09)]] packet to open it.
 
The process to actually open the command block window clientside is somewhat complex; the client actually uses the [[Protocol#Update Block Entity|Update Block Entity (0x09)]] packet to open it.
  
 
First, the client must have at least an {{Minecraft Wiki|Server.properties#op-permission-level|OP permission level}} of 2, or else the client will refuse to open the command block.  (The op permission level is set with the [[Protocol#Entity Status|Entity Status]] packet)
 
First, the client must have at least an {{Minecraft Wiki|Server.properties#op-permission-level|OP permission level}} of 2, or else the client will refuse to open the command block.  (The op permission level is set with the [[Protocol#Entity Status|Entity Status]] packet)
  
−
To actually open the command block:
+
要想真正打开命令方块:
  
 
# '''C'''→'''S''': [[Protocol#Player Block Placement|Player Block Placement (0x1C)]], with the position being the command block that was right-clicked.
 
# '''C'''→'''S''': [[Protocol#Player Block Placement|Player Block Placement (0x1C)]], with the position being the command block that was right-clicked.

Latest revision as of 02:13, 4 January 2022

有人一直问我们关于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: 插件信息: minecraft:brand包含服务器的类型(可选)
  12. S → C: 服务器难度 (可选)
  13. S → C: 玩家的能力 (可选)
  14. C → S: 插件信息: minecraft:brand包含客户端的类型(可选)
  15. C → S: 客户端设置
  16. S → C: 手持物品的变化
  17. S → C: 合成表
  18. S → C: 标签
  19. S → C: 实体状态 (不是OP权限级别,这个才是Entity statuses#Player)
  20. S → C: 命令
  21. S → C: 解锁合成表
  22. S → C: 玩家位置和朝向
  23. S → C: 玩家信息 (添加玩家的动作)
  24. S → C: 玩家信息 (更新延时动作)
  25. S → C: 更新视线位置
  26. S → C: 更新光照 (在以玩家位置为中心的正方形中,每个区块都发送一次.)
  27. S → C: 区块数据 (在以玩家位置为中心的正方形中,每个区块都发送一次.)
  28. S → C: 世界边界 (一旦世界完成了加载)
  29. S → C: 出生位置 ("家"出生点,不是客户端登录时的位置)
  30. S → C: 玩家位置和朝向 (必须,告诉客户端已经准备好生成了)
  31. C → S: 传送确认
  32. C → S: 玩家位置和朝向 (确认生成位置)
  33. C → S: 客户端状态 (在接收区块前或接收区块时发送,需要进一步测试,如果没有发送,服务端会正确处理.)
  34. S → C: 物品栏、实体...

正常状态的ping顺序是什么样子的?

当Notchian客户端和服务端在ping状态中交换信息时,数据包的交换情况如下:

  1. C → S: 握手 State=1
  2. 服务端将协议State设置为1
  3. C → S: 请求
  4. S → C: 响应
  5. C → S: Ping
  6. S → C: Pong
  7. S → ❌: 服务端终止与客户端的连接

离线模式

如果服务端处于离线模式,则不会发送加密请求数据包并且客户端也不会发送加密响应数据包.在这种情况下,加密永远也不会被启用,也不进行认证.

客户端可以判断出服务端是否处于离线模式,如果服务端直接发送了登录完成数据包而不发送加密请求数据包,则是离线模式,反之.

我觉得我做好了,但是...

...我的玩家没有生成!

在完成了基本操作之后(握手、登录开始、物品栏、出生位置、区块),你需要发送玩家的初始位置来让它们离开"Loading Map"界面.

请注意,如果采取以下步骤,Minecraft客户端将生成玩家:

  1. 握手(协议加密)
  2. 发送出生位置数据包
  3. 发送玩家位置和朝向数据包

虽然上述步骤对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.

...我的客户端没有收到完整的地图区块!

主要内容: 如何写一个客户端

标准的Minecraft服务端只有在你的客户端发送玩家状态更新数据包时才会发送完整的数据块(any of 玩家(0x03) through 玩家位置和朝向(0x06)).

...所有连接的客户端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.

...客户端正试图发送一个以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.

...客户端在一段时间后断开连接,并出现"Timed out"错误

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.

...我的客户端没有发送登录开始数据包!

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.

Huh.png The following information needs to be added to this page:
关于如何解析分组数据包的伪代码示例?

如何打开/保存命令方块?

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)

要想真正打开命令方块:

  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.

Retrieved from "https://wiki.vg/index.php?title=Protocol_FAQ:zh-cn&oldid=17247"