Loading article…
通信プロトコルにおいて、TLV（タイプ・長さ・値、またはタグ・長さ・値）は情報要素に使用される符号化方式です。TLVでエンコードされたデータストリームには、レコードタイプ、レコード値の長さ、そして値自体に関するコードが含まれます。
型と長さは固定サイズ（通常1～4バイト）であるか、サイズを知らなくても解析できる（LEB128、可変長数量を参照）が、値フィールドは可変サイズである。これらのフィールドは次のように使用される。
TLV表現を使用する利点には、以下のようなものがあります。
電話をかけるためのメッセージを想像してみてください。システムの最初のバージョンでは、次の構造が定義されています。
struct message { uint16_t tag ; uint16_t length ; char value [ length ]; } /* タグ */ #define T_COMMAND 0x00 #define T_PHONE_NUMBER_TO_CALL 0x10 /* コマンド値 */ #define C_MAKE_CALL 0x20通話を行う際、以下のデータが送信されます。
00 00 T_COMMAND 00 04 長さ = 4 00 00 00 20 C_MAKE_CALL 00 10 電話番号 00 08 長さ = 8 37 32 32 "722-" の 2D ASCII 34 32 34 36 ASCII で「4246」を表す
受信側システムは、そのメッセージが「722-4246」に電話をかけるように指示していることを理解します。
その後（バージョン 2で）、発信番号を含む新しいフィールドが追加されました。
#define T_CALLER_NUMBER 0x11次のようなメッセージが送信されます。
00 00 T_COMMAND 00 04 長さ = 4 00 00 00 20 C_MAKE_CALL 00 11 T_CALLER_NUMBER 00 0c 長さ = 12 36 31 33 「613-」の2D ASCII 37 31 35 "715-" の 2D ASCII 39 37 31 39 ASCIIコード「9719」 00 10 電話番号 00 08 長さ = 8 37 32 32 "722-" の 2D ASCII 34 32 34 36 ASCII で「4246」を表す
バージョン 2 システムからメッセージを受信したバージョン1 システムは 、まず要素を読み取りT_COMMAND、次に型の要素を読み取りますT_CALLER_NUMBER。バージョン 1 システムはを理解しないT_CALLER_NUMBERため、長さフィールド (つまり 12) を読み取り、12 バイト先へスキップして、システムがT_PHONE_NUMBER_TO_CALL理解できるを読み取り、メッセージの解析を続行します。
コアとなるTCP/IPプロトコル（特にIP、TCP、UDP）は、事前に定義された静的フィールドを使用します。
HTTP/1.1（およびその非標準化された前身）、FTP、SMTP、POP3、SIPなど、一部のアプリケーション層プロトコルは、RFC 2822に準拠したテキストベースの「フィールド：値」ペアを使用します。（HTTPはContent-Lengthヘッダーでペイロードの長さを表し、ヘッダーとペイロードは空行で、ヘッダー同士は改行で区切られます。）
ASN.1では、 TLVベースのエンコーディング規則（BER、DER）と、TLVベースではないエンコーディング規則（PER、XER、JSONエンコーディング規則）が規定されています。TLVベースの規則は、メッセージの構成要素を知らなくても解析できますが、TLVベースではない静的なPER規則は解析できません。XERはXMLを使用するため、メッセージの構成要素を知らなくても解析できます。JSONエンコーディング規則も同様です。
CSN.1は、TLV以外の意味論を用いたエンコード規則を記述しています。
最近では、XML はネットワーク内の異なるノード間でメッセージを実装するために使用されています。これらのメッセージは通常、 BEEPなどの行ベースのテキストコマンドで始まります。