本文主题：编码和解码，或者说是数据从一种特定协议的格式到另一种的转换。这些任务通常由编解码器组件处理

Netty 提供了多种组件，简化了为支持广泛协议而创建自定义编解码器的过程。

若你正在构建一个基于 Netty 的邮件服务器，那就会发现 Netty 对于编解码器的支持对于实现 POP3、IMAP 和 SMTP 协议来说是多么宝贵！

0 什么是编解码器

每个网络应用程序都必须定义

如何解析在两个节点之间来回传输的原始字节如何将其和目标应用程序的数据格式做相互转换

这种转换逻辑由编解码器处理，编解码器由编码器和解码器组成，它们每种都可将字节流从一种格式转换为另一种。

它们的区别是什么?

若将消息看作对于特定应用程序具有具体含义的结构化的字节序列 — 它的数据。那

编码器就是将消息转换为适合于传输的格式(最可能的就是字节流)对应的解码器则是将网络字节流转换回应用程序的消息格式

因此，编码器操作出站数据，解码器处理入站数据。

接下来让我们研究一下 Netty 所提供的用于实现这两种组件的类。

1 Netty解码

Netty 的解码器类：

将字节解码为消息

ByteToMessageDecoder 和 ReplayingDecoder将一种消息类型解码为另一种MessageToMessageDecoder

解码器负责将入站数据从一种格式转到另一种，所以 Netty 解码器实

现了 ChannelInboundHandler 也很自然。

什么时候会用解码器?

每当需为 ChannelPipeline 中的下一个 ChannelInboundHandler 转换入站数据时。

得益于ChannelPipeline 的设计，可以将多个解码器连接在一起，以实现任意复杂的转换逻辑，这也是 Netty 是如何支持代码的模块化以及复用的一个很好的例子。

案例代码

2 抽象解码器 ByteToMessageDecoder2.1 示例

Netty 提供抽象基类：ByteToMessageDecoder，将字节解码为消息(或另一个字节序列)。

由于你不可能知道远程节点是否会一次性发送一个完整消息，所以该类会缓冲入站数据，直到它准备好处理。

ByteToMessageDecoderAPI

假设你接收了一个包含简单 int 的字节流，每个 int 都需要被单独处理

在这种情况下，你需要从入站ByteBuf中读取每个 int，并将它传递给ChannelPipeline 中的下一个 ChannelInboundHandler

为了解码这个字节流，你要扩展 ByteToMessageDecoder类(原子类型的 int 在被添加到 List 中时，会被自动装箱为 Integer)

每次从入站 ByteBuf 中读取 4 字节，将其解码为一个 int，然后将它添加到一个 List 中

当没有更多的元素可以被添加到该 List 中时，它的内容将会被发送给下一个 Channel- InboundHandler

ToIntegerDecoder类扩展了ByteToMessageDecoder

虽然ByteToMessageDecoder可以很简单地实现这种模式，但是你可能会发现，在调用 readInt()前不得不验证所输入的 ByteBuf 是否具有足够的数据有点繁琐

在下一节中， 我们将讨论 ReplayingDecoder，它是一个特殊的解码器，以少量的开销消除了这个步骤2.2 源码解析

下面开始解析解码流程的源码：

2.2.1 累加字节流

其中的cumulator 为

看一下这个MERGE_CUMULATOR

2.2.2 调用子类 decode 方法进行解析

进入该方法查看源码

2.2.2 将解析到的 ByteBuf 向下传播

注意到上图中的如下代码段：

编解码器中的引用计数

对于编码器和解码器，一旦消息被编码或解码，它就会被 ReferenceCountUtil.release(message)调用自动释放。

若需要保留引用以便稍后使用，可调用 ReferenceCountUtil.retain(message)，这会增加该引用计数，从而防止该消息被释放。

3 固定长度解码器4 行解码器4.1 定位行尾

4.2 非丢弃模式

找到换行符

找不到换行符

4.3 丢弃模式

找到换行符

找不到换行符

参考：

《Netty实战》

推荐阅读：

刷Github时发现了一本阿里大神的算法笔记！标星70.5K