先问输入是什么，再看十六进制结果
阅读区块链RLP资料，最容易出错的地方是把“值看起来一样”当成“输入类型一样”。RLP用于以太坊执行层的数据序列化，主要描述字节串与嵌套列表的结构。文档中的string指字节序列，不意味着它天然知道某种语言的文字、金额或日期。
因此，记录一个编码例子时，应同时写明输入是字节串、整数，还是列表。只抄一串十六进制，再让下一位读者猜业务含义，会把本来可以分开的两个问题混在一起：底层结构怎样读取，以及字段应当解释成什么。
空字节串与整数零，确实可以同码
长度为零的字节串编码为0x80；空列表编码为0xc0。按以太坊采用的整数约定，整数先写成不带多余前导零的大端字节序列，整数0使用空字节串表示，所以它的RLP编码也是0x80。不能把这三种输入写成“编码各不相同”。
单独含有一个零字节的字节串又是另一回事：它编码为0x00，而不是0x80。原因是值在0x00至0x7f之间的单个字节按自身编码。区分空串与零字节，需要看字节数量；区分空串与整数0，则还要知道上层要求的字段类型。
用两个短例子练习读长度
假设输入是包含0x01、0x02两个字节的一条字节串，编码为0x820102。前缀0x82说明后面有两个字节的串内容。若输入改成一个列表，列表内分别放单字节串0x01和0x02，编码则是0xc20102；前缀0xc2表示后面两字节属于列表的编码载荷。
两者后半段相同，但结构不同。列表前缀中的长度计算的是各子项编码后拼接起来的字节数，不是直接数列表有几个元素。以上均是手工推导的短例子；长数据还有其他长度规则，不能把这几条短编码公式无条件套用到任意大小。
能还原字节，不代表自动还原业务类型
pyrlp的教程展示了一个直观现象：整数编码后，直接做通用解码会先得到字节串；给出整数的序列化与反序列化规则，才能得到对应整数。这不是解码丢失文件，而是RLP本来就不为每个字段携带完整的高级类型说明。
同样，一份按固定顺序组织的业务记录，仍需在上层约定哪些位置是什么类型。RLP列表自身不会替应用保存“第一个字段叫发送方”这样的字段名。看到解码工具展示一串字节时，下一步应找对应结构定义，而不是按页面标签自行猜测。
核对资料时保留结构和约定两层
检查一份教程，可以把原始输入、期望编码和字段约定放在一起比对。若讨论的是整数，还要检查最短大端表示的要求；原始字节串可以包含前导零，并不表示这些字节作为整数编码时也一定有效。约定不同，合法性的判断层次也不同。
对陌生链上数据，先确认是否确实使用RLP及对应对象的结构，再继续解释业务。成功解出一个列表，只能说明完成了相应的编码解析，不能由此推出一笔交易已经被网络接受。把“格式可读”与“业务有效”分开，才能读准这些技术资料。