毫无疑问，数据的长度值表示是有用的，但是类型长度值比它有什么优势呢？
当然，使用 LV 需要预定义或结构化表示，但这几乎不是问题。实际上，我想不出一个足够好的案例，因为它的定义不够好，以至于需要 TLV。
就我而言，这是关于数据交换/协议的。在任何情况下，都必须知道要处理的双方都知道表示，这消除了在数据中显式插入类型的需要。关于该类型何时有用或必要的任何想法？
编辑
我应该提到通用解析器/处理器肯定会从类型信息中受益，但这不是我的情况。
问问题
1245 次
2 回答
1
我能想出的唯一正当理由是数据的通用处理器，主要用于调试或直接用户演示。将类型嵌入数据将允许处理器正确处理数据，而无需预定义所有可能的结构。
于 2012-07-05T18:02:32.530 回答
0
维基百科中提到了以下几点。
可以安全地跳过在旧节点接收到的新消息元素，并且可以解析消息的其余部分。这类似于可以安全地跳过未知 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 元素，然后读取类型为 callingNumber_c 的元素。
版本 1 系统不理解 ;callingNumber_c，因此读取长度字段（即前 8 个），系统向前跳过 8 个字节读取它理解的 phoneNumberToCall_c，并继续进行消息解析。
如果没有 type 字段，版本 1 解析器将不知道跳过 callNumber_c 而是调用错误的号码，并可能在消息的其余部分抛出错误。因此 type 字段允许以省略它的方式向前兼容。
于 2012-07-16T11:02:51.843 回答