纸条有纸的边缘。字节流没有替你画好的纸边。
当两段文字挨在一起到达，接收方怎样知道哪里结束、哪里开始？在加重试之前，我们先让一条消息能被明确识别和完整还原。
在 V1 房间输入含中文与一个表情的文字，点击“生成 V1 信封到工作台”，再编码演练。观察 JSON 文本的 Unicode 码位数与 UTF-8 字节数。
这两个数经常不同。一个汉字通常占多个 UTF-8 字节；码位数也不等于所有情况下的可见字形数量。我们的长度头必须说明实际有多少正文字节。
你可以试着把码位数误填到长度头，先预测接收器会切在哪里，再运行。它可能在一个字符中间截断，也可能取得不完整 JSON，错误发生的位置需要看实际输入。
4 字节长度头（大端） | 指定长度的 UTF-8 JSON 正文“大端”是双方对字节顺序的约定。长度 5 写成十六进制是 00 00 00 05；接收方先读这四个字节，才知道本条正文需要多少字节。
四字节长度头并不是唯一选择。定长记录、分隔符与转义也可以形成协议，各有代价。本课程选这个格式，是为了让双方能明确处理不完整头、不完整正文和连续两帧。
本版正文上限为 2048 字节。一个很大的长度声明不能让接收端无条件分配无限内存；格式约定也包含资源边界。
发送侧的步骤是：检查消息字段 → 生成 JSON 文本 → 用 UTF-8 编码 → 取得编码后的长度 → 构造长度头 → 拼接。
工作台显示的统计来自当前实际使用的编码器。JSON 可以有不同空白或转义写法，只要仍满足协议并还原同一内容；两端不应依靠偶然的排版猜长度。
把两条同方向的消息放进数组，运行一次。帧可以直接粘在一起，接收方仍应得到两条独立消息。再改变传入分块大小，结果不应因此变成乱码或一条长消息。
这里的分块是教学字节接口的边界，不直接等于 TCP 数据包。底座 HTTP 自己已有一层消息组织，我们是在应用模型中学习并实现这一层约定。
在教材 practice/student.py 补上 pack(message)。可先复用已有的 payload_bytes(message) 获得经过字段检查的 UTF-8 正文，再独立写出长度头和拼接。
你需要向接收端搭档说明：头有几字节、采用什么字节序、长度指什么、最大允许多少、正文格式是什么。只说“我发过去的是 JSON”还不够。
暂时不会 Python 的读者，可以先在工作台构造信封、填写长度并解释失败；再按需查 函数工具箱 与 JSON 工具箱，完成实现层练习。
用参考接收器读取自己的编码结果，核对普通文本、中文和表情内容。记录一次错误长度实验，说明它为什么失败。
长度与 JSON 检查并不提供密码学来源证明，也不能阻止所有恶意篡改；字段中的 from 还不能代替未来的信任体系。我们的新增承诺是：在本版规则下，接收器知道该按什么边界解释这批字节。