什么是白話彩信協議

本篇內容介紹了“什么是白話彩信協議”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

通知

第一步既然也是短信協議，我們先回顧一下短信協議的組成，是這個樣子的：

包含UDH和UD，那彩信通知中UDH和UD的值是什么呢？

先說UDH，其包含2個端口信息（wap-push:2948，wap-wsp:9200），這兩個端口是IANA注冊的端口，我們后面說，現在我們只需要知道，要存下這兩個端口需要4個字節（每個端口2字節），我們正好有IEI為0x05（Application port addressing scheme, 16 bit address），表示IED包含的是16位的端口信息，那我們通知的UDH是這樣的：

2948的16進制為0x0B84，9200的16進制為0x23F0，所以最后UDH就是：0x05 0x04 0x0B 0x84 0x23 0xF0

接著我們再來說UD，我們前面提到了，我們通知中會帶上彩信文件的地址，當手機收到通知時，會去該地址下載彩信文件，所以，彩信的地址必然在我們UD中，哪還有哪些東西需要包含在UD中呢？

不知道大家有沒有注意過彩信在手機中展示是什么樣的呢？彩信肯定會有圖片、視頻這些主要信息，不過還會發送人、主題、彩信大小這些信息。那在我們通知中需要包含上面哪些信息呢，實際上以上就是我們彩信文件所包含的全部信息，不過通知中是不需要圖片、視頻這些主要信息的，不然還要通知干什么呢，那剩下的就是通知中需要帶上的信息了，包括發送人、主題、彩信大小。

好了，我們知道了UD中需要存哪些信息，接下來，我們就來看下UD的具體組成

老規矩，在這之前，介紹個概念

WSP(Wireless Session Protocol): 這是一種基于HTTP1.1的一種協議，有自己的編碼方式

我們前面說UDH的時候提到，有2個端口信息(wap-push, wap-wsp)，這倆個端口恰好對應我們彩信的兩個過程，可以把它們當做目的地和源地，我們UD也正是用WSP編碼方式存儲的，這里簡單的說一下WSP是怎么編碼的

WSP編碼其實可以看做key-value編碼，key的編碼又有2種，一種可以當做是內置的key，一種是自定義的key

內置key的有對應的一個字節內容代表，自定義key會用專門的字符串編碼方式進行編碼，value和自定義key一樣，如果是字符串會用專門的字符串編碼方式進行編碼，數字則會用專門的數字編碼方式進行編碼

我們UD組成也包含信息頭和信息體，這個信息頭和信息體就不是短信中的UDH和UD了，而是WSP的信息頭和信息體

信息頭

WSP信息頭很簡單，包含一個TID和一個PDU TYPE，各占一個字節，TID不用去關心它，我們只需要關心當pdu_type=6時，就表示這是一個wap-push就OK了

比如，我們假設TID=0那么WSP頭就為：0x00 0x06

信息體

這里我們再介紹一個概念

MMSEP(Multimedia Messaging Service Encapsulation Protocol): 彩信封裝協議，是基于WSP協議

MMSEP也包含信息頭和信息體，還記得我們之前說通知和彩信文件的內容差不多嗎？其實彩信文件和通知相同的部分就是MMSEP的信息頭，多出來的圖片、視頻就是MMSEP的信息體了，其實通知就是一個信息體為空的MMSEP

MMSEP信息頭會指定一個content_type，content_type也是根據專門的字符串編碼方式進行編碼，比如彩信通知的content_type為：application/vnd.wap.mms-message，MMSEP的content_type和普通content_type不太一樣，MMSEP的content_type能帶參數，并一起參與編碼，彩信通知的content_type就帶有一個參數X-Wap-Application-ID=x-wap-application:mms.ua

這里我們簡單看一下content_type結果：0x22 0x61 ... 0x00 0xAF 0x84

我們大概解釋一下這串編碼，還記得前面說的WSP編碼方式嗎？X-Wap-Application-ID這個key是內置的，用0xAF表示，x-wap-application:mms.ua同樣，用0x84表示。那再來看前面的，因為application/vnd.wap.mms-message不是內置的key，所以得按照特殊字符串編碼方式編碼，第一位表示長度0x22，后面0x61 ... 0x00 就是編碼內容了（這里就省略了）

我們接著看，MMSEP信息頭里面除了我們之前提到的發送人、主題、彩信大小外，還會有一些其它信息，我們挨個介紹一下

version: 表示使用的WSP編碼版本

message_type: 表示彩信類型

transaction_id: 表示事物ID

message_class_id: 表示彩信分類ID

expiry: 表示彩信有效期

subject: 表示標題

location: 表示彩信文件地址(我們前面提到，WSP是基于HTTP的協議，這里可以是一個HTTP地址)

from: 表示發送人

這里我們特別解釋一下message_type，message_type代表了這個是一種什么類型的彩信，比如message_type=2表示這是一個通知，message_type=4表示這是一個彩信文件

那到這里，我們的通知UD剩下的部分也知道了，就是這個樣子：

這里大多數key都是內置的，我舉幾個例子，比如

0x8D90 0x80表示這是version，0x90表示值為1.0；

0x8A80表示msg_class_id=personal；

0x8C82表示message_type=2；

0x98表示transaction_id，0x88 表示expiry，0x89表示from，0x8E表示size，0x83表示location，0x96表示subject；

這里沒有例出的值的key，它們的值就需要用特殊的字符串或者數字編碼了

到這里，我們通知的部分就介紹完了，整個通知大概就是：0x05 0x04 0x0B 0x84 0x23 0xF0 0x00 0x06 0x22 0x61 ... 0x00 0xAF 0x84 0x8D90 0x8A80 0x8C82 0x98 ... 0x88 ... 0x89 ... 0x8E ... 0x83 ... 0x96 ...

這里補充一點，可能你也注意到了，從最終結果來看，既然我們彩信通知和普通文本短信一樣，而且我們編碼出來的東西很可能超過了短信字節的限制，那同樣也會有可能出現一個通知分為多條發送的情況，這種情況下，我們不能省略必要的信息，能做的可能就是將location(uri)縮短了

最后，我們從協議的層面來看下通知是什么樣子的：

彩信文件

前面我們說通知的時候提到了，彩信文件其實就是比彩信通知多了圖片、視頻的信息，從協議來看就是比彩信通知（信息部分MMSEP header）多了信息體，其實信息體里就是放的圖片、視頻，彩信文件就是這個樣子：

前面我們已經介紹過了MMSEP header，那我們彩信文件里只是部分header的值不同，其它都與通知時一樣的，下面我把不同的取值給你列出來

content_type: application/vnd.wap.multipart.related或application/vnd.wap.multipart.mixed

message_type: 之前也提到過，如果是彩信文件message_type=4

date: 表示彩信生成時間，不同于通知的expiry，彩信文件中是date

“什么是白話彩信協議”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！