データの長さ値表現が有用であることは間違いありませんが、type-length-value にはどのような利点があるのでしょうか?
もちろん、LV を使用するには、表現を事前定義または構造化する必要がありますが、それが問題になることはほとんどありません。実際、TLV が必要になるほど十分に定義されていない十分なケースは考えられません。
私の場合、これはデータ交換/プロトコルに関するものです。どのような状況でも、表現は処理される側の両方に知られている必要があります。これにより、データに型を明示的に挿入する必要がなくなります。タイプがいつ役立つか、または必要になるかについて何か考えはありますか?
編集
汎用パーサー/プロセッサは確かに型情報から恩恵を受けることに言及する必要がありますが、それは私の場合ではありません。
私が思いついた唯一の適切な理由は、主にデバッグまたは直接のユーザー表示のための、データの汎用プロセッサのためです。型をデータ内に埋め込むと、プロセッサは可能なすべての構造を事前に定義しなくても、データを正しく処理できます。
ウィキペディアに以下の点が記載されていました。
古いノードで受信された新しいメッセージ要素は安全にスキップでき、残りのメッセージは解析できます。これは、不明な XML タグを安全にスキップできる方法と似ています。
例: 電話をかけるメッセージを想像してください。システムの最初のバージョンでは、これは「command」と「phoneNumberToCall」の 2 つのメッセージ要素を使用する場合があります。
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 をスキップすることを認識せず、代わりに間違った番号を呼び出し、メッセージの残りの部分でエラーをスローする可能性があります。そのため、type フィールドは、それを省略しない方法で前方互換性を可能にします。