類型長度值與定義的/結構化的長度值

Question

毫無疑問，數據的長度 - 值表示是有用的，但是對於其類型長度值有什麼優勢？

當然，使用LV需要預定義或結構化的表示，但這幾乎不是問題。實際上，我無法想到一個足夠好的案例，它不足以定義TLV。

在我的情況下，這是關於數據交換/協議。在任何情況下，雙方都必須知道該表示的處​​理方式，這樣就不需要顯式插入數據。任何想法什麼時候該類型將是有用的或必要的？

編輯
我應該指出，通用的解析器/處理器肯定會從類型信息中獲益，但這不是我的情況。

Answer 1

我能想到的唯一體面的原因是數據的通用處理器，主要用於調試或直接用戶演示。在數據中嵌入類型將允許處理器正確處理數據，而無需預先定義所有可能的結構。

Answer 2

在維基百科中提到了以下幾點。

可以安全地跳過在舊節點上接收到的新消息元素，並可以解析其餘消息。這類似於可以安全跳過未知XML標籤的方式;

示例： 想象一下打電話的消息。在一個系統中的第一版本，這可能使用兩個消息元素中， 「命令」 和 「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其理解，並且消息解析進行。

如果沒有類型字段，版本1分析器將不知道跳過callingNumber_c，而是調用錯誤的數字，並可能在消息的其餘部分引發錯誤。所以類型字段允許以忽略它的方式提供前向兼容性。