Netty4.0中LengthFieldPrepender编码器学习心得（二）

Netty4.0中LengthFieldPrepender编码器学习心得（二）

本人这段时间都在持续学习Netty的相关知识，主要是依据李林峰的《Netty权威指南-V2》。

昨天刚整理了[]/article/11178060.html]解码器LengthFieldBasedFrameDecoder的相关学习知识。今天整理其对应的编码器原理知识。

从昨天的链接：“Netty作为服务端、java.net.Socket作为客户端”章节中发现，LengthFieldBasedFrameDecoder解码时，计算每个数据包的整体长度时，多增加了一部分。为什么呢？我们可从编码器中得到答案。

方面描述，数据包的结构如下：

|–Length(int)–|–Txt(bytes)–|

1-编码器初始化

打开LengthFieldPrepender的源码，找到对应的构造函数：

///实例化
new LengthFieldPrepender(4, false);

*上面的第2个参数若为true时，则编码时会将数据包的Length字段字节数叠加的到Length值中。

2-编码方法encode

该方法在158行，重点部分如下：

///159行，计算数据包的长度
int length = msg.readableBytes() + lengthAdjustment;
if (lengthIncludesLengthFieldLength) {
//叠加长度字段的字节数，但是解码器LengthFieldBasedFrameDecoder381行中，却没有相应的判断
length += lengthFieldLength;
}
///...省略
/// 169行，整理发送数据:ByteBuf out,待发送的缓存
switch (lengthFieldLength) {
case 1:
out.writeByte((byte) length);//先写入长度字段的值
break;
case 2:
//省略
}
out.writeBytes(msg, msg.readerIndex(), msg.readableBytes()); // 201行，再写入具体的报文内容

3-疑问

不知道Netty作者为什么这么做。但是若不注意上面的细节，使用LengthFieldBasedFrameDecoder、LengthFieldPrepender就会出现问题。

这个需要各位编码人员若要自定义数据结构，就需要将LengthFieldBasedFrameDecoder、LengthFieldPrepender类中对应地decode、encode方法进行逻辑修改了。