毫无疑问，数据的长度值表示是有用的，但是类型长度值比它有什么优势？
当然，使用 LV 需要预先定义或结构化表示，但这几乎不是问题。实际上，我想不出一个足够好的案例，因为它的定义不够好，以至于需要 TLV。
就我而言，这是关于数据交换/协议的。在任何情况下，都必须知道要处理的双方都知道表示，这消除了在数据中显式插入类型的需要。关于该类型何时有用或必要的任何想法？
编辑
我应该提到，通用解析器/处理器肯定会从类型信息中受益，但这不是我的情况。
【问题讨论】：
标签： protocols data-representation tlv
我能想到的唯一正当理由是数据的通用处理器，主要用于调试或直接用户演示。将类型嵌入数据将允许处理器正确处理数据，而无需预定义所有可能的结构。
【讨论】：
维基百科中提到了以下几点。
可以安全地跳过在旧节点接收到的新消息元素，并且可以解析消息的其余部分。这类似于可以安全跳过未知 XML 标记的方式；
示例： 想象一条信息来拨打电话。在系统的第一个版本中，这可能使用两个消息元素，一个“command”和一个“phoneNumberToCall”：
command_c/4/makeCall_c/phoneNumberToCall_c/8/"722-4246" 这里 command_c、makeCall_c 和 phoneNumberToCall_c 是整数常量，4 和 8 分别是“值”字段的长度。
稍后（在版本 2 中）可以添加一个包含主叫号码的新字段： command_c/4/makeCall_c/callingNumber_c/8/"715-9719"/phoneNumberToCall_c/8/"722-4246"
从版本 2 系统接收消息的版本 1 系统将首先读取 command_c 元素，然后读取类型为 callNumber_c 的元素。
版本1系统不理解;callingNumber_c 因此读取长度字段（即前 8 个），系统向前跳过 8 个字节进行读取 它理解的phoneNumberToCall_c，并进行消息解析。
如果没有 type 字段，版本 1 解析器将不知道跳过 callNumber_c 而是调用错误的号码，并可能在消息的其余部分抛出错误。因此 type 字段允许以省略它的方式向前兼容。
【讨论】：