介紹了TLV數(shù)據(jù)封裝格式，那么下面再詳細(xì)介紹下其三大特點:

每個TLV結(jié)構(gòu)的第一部分為Type字段（通常為1-4字節(jié)），用于明確標(biāo)識數(shù)據(jù)的語義和編碼方式，前面在介紹該字段的時候有說明了一下。

但是該字段需要收發(fā)雙方約定好，這樣就誕生了類型映射表。

類型映射表：Type值通過預(yù)定義的協(xié)議規(guī)范或動態(tài)協(xié)商（如設(shè)備握手階段）確定，接收方根據(jù)Type值選擇對應(yīng)的解析邏輯。 若Type值與實際數(shù)據(jù)格式不匹配（例如Type聲明為整數(shù)但Value為字符串），接收方可直接報錯。 

這樣的話就無需外部元數(shù)據(jù)，數(shù)據(jù)本身攜帶類型信息，解析器無需依賴額外的協(xié)議文檔或配置文件，現(xiàn)在挺多高級一點的序列化工具都需要使用工具等，麻煩。

在兼容性方面，不同設(shè)備或協(xié)議版本可以通過擴(kuò)展Type定義（如預(yù)留私有Type范圍）實現(xiàn)兼容，舊設(shè)備可忽略未知Type。同樣你進(jìn)行協(xié)議升級的時候，，只需定義新Type值（如0x04表示PM2.5），舊設(shè)備可跳過未知字段，新設(shè)備解析新數(shù)據(jù)，當(dāng)前前提是你需要定義較多的type字段。

緊隨Type后的Length字段長度并不是固定的，通常為1-4字節(jié)夠了，它主要是用于聲明Value部分的字節(jié)長度。

例如：

當(dāng)然也可以更加靈活的編碼，Length字段的字節(jié)數(shù)可根據(jù)協(xié)議設(shè)計動態(tài)調(diào)整。

短數(shù)據(jù)（≤255字節(jié)）：Length用1字節(jié)表示；

長數(shù)據(jù)（如固件包）：Length用4字節(jié)表示

這樣一方面能夠節(jié)省避免固定長度字段的填充浪費，另一方面可以支持可變數(shù)據(jù)，以適應(yīng)物聯(lián)網(wǎng)場景中數(shù)據(jù)長度多變的需求（如傳感器數(shù)據(jù)、配置參數(shù)、日志文本）。

不知道大家平時用過流式傳輸沒，通過Length提前預(yù)知數(shù)據(jù)邊界，無需等待完整數(shù)據(jù)包，做到接收方可邊接收邊解析數(shù)據(jù)。

TLV整體以二進(jìn)制字節(jié)流傳輸，而非文本格式（如JSON、XML）。而且在協(xié)議約定中采用的是一種緊湊編碼規(guī)則，比如:

整數(shù)使用最小字節(jié)數(shù)（如0x7F以內(nèi)用1字節(jié)，超過則用2字節(jié)）；

浮點數(shù)采用IEEE 754標(biāo)準(zhǔn)壓縮；

枚舉值直接用單字節(jié)表示等等，可以做到無需轉(zhuǎn)換直接按字節(jié)偏移讀取數(shù)據(jù)，在資源受限平臺大家確實比較鐘愛。按照TLV的數(shù)據(jù)封裝自定義協(xié)議基本上能夠滿足大部分嵌入式應(yīng)用場景了。

      好了，今天就跟大家分享這么多了，如果你覺得有所收獲，一定記得點個贊~

推薦專輯  點擊藍(lán)色字體即可跳轉(zhuǎn)

?  MCU進(jìn)階專輯 

?  嵌入式C語言進(jìn)階專輯 

?  “bug說”專輯 

? 專輯|Linux應(yīng)用程序編程大全

? 專輯|學(xué)點網(wǎng)絡(luò)知識

? 專輯|手撕C語言

? 專輯|手撕C++語言

? 專輯|經(jīng)驗分享

? 專輯|電能控制技術(shù)

? 專輯 | 從單片機(jī)到Linux