前一時間折騰了一下手機方面的開發，用的是NOKIA智能手機，NOKIA網站有一個很方便的開發包Nokia_PC_Connectivity_API_3.2。
這個開發包帶有VB.NET,C#,VC的文件系統，設備管理，內容存取的開發例子。試了試可以正常收發短信，但彩信只可以看到條目標題，時間，看不了內容，了解一下，在Content Access API 3.2里的CA_MMS_DATA。這個結構體中，重要的BYTE* pbData 沒有相關說明，例子里也沒有解析。
這幾天把手機的pbData數據異了一些出來，網上查了一下，發現是彩信的PDU編碼格式就到網上找了一下，相關開發入門的例子和協議，竟發現不好找。亂七八糟的。說什么的都有。因為自已的手機碼是使用移動的就找了一下關於移動的相關文件，很快就找到《中國移動多媒體消息系統（MMS）接口規范》。了解一下整個MMS流程。
多媒體消息業務涉及的系統接口
整個MMS業務環境通過WAP網關與移動網相連，各接口協議都是HTTP或SMTP等通用的Internet協議。其中：
MM1：MMS用戶代理（MMS手機上的應用程序，如瀏覽器）和MMS代理/服務器（MMSC）之間的參考點，基於WAP和HTTP實現；
MM2：MMS中繼和MMS服務器之間的參考點，一般是MMSC內部的接口；
MM3：MMS服務中心和外部消息系統間的參考點，基於IP實現，如與Email服務器相連，則采用SMTP協議；
MM4：MMS服務中心和另一個MMSE中的MMS服務中心間的參考點，基於SMTP實現；
MM5：MMS服務中心和HLR間的參考點，非必須；
MM6：MMS服務中心和MMS用戶數據庫間的參考點，可以是內部接口或外部接口；
MM7：MMS服務中心和MMS增值業務應用之間的參考點，基於IP實現；
MM8：MMS服務中心和計費系統間的參考點。
看了一下，再加之前面找的一些亂七八糟的資料，了解到開發彩信有兩個種要的開發接口，一個是MM1接口，和MM7接口。
MM1是以終端設備方式（手機終端、GPRS modem），MM7是以SP增值業務方式接入.
說明自已手機異出的數據是MM1接口的協議上的mms pdu數據。
MMS PDU 的解碼
MMS PDU 的具體編碼規則在：WAP-209-MMSEncapsulation-20020105-a.pdf或在OMA-MMS-ENC-V1_2-20050301-A.pdf上有介紹。
MMS PDU被封裝在WSP/PDU之中 作為WSP的消息體進行傳輸，並采用WAP/WSP協議作為傳輸內容的二進制編碼（binary encoding）機制，進行消息的封裝（Encapsulation）。
在OMA-TS-MMS-ENC-V1_3-20080128-C.pdf文檔所在規范中，詳細定義了每個PDU所涉及的Header域和值，以及為它們分配的二進制碼的一一對應關系。采用此二進制編碼規范，節約了無線領域的帶寬資源，並最優化其在空中傳播的數據量。
具體對應關系請參閱相關文檔。
MMS 編碼必須遵循無線會話協議（ Wireless Session Protocol，以下簡稱 WSP）。
WSP使用一種與 HTTP/1.1相同的語法描述數據的組織結構，具體可參考 RFC[2068]。
HTTP/1.1使用 ASCII字符編碼來傳輸數據，而 WSP為降低傳輸帶寬，將 HTTP/1.1中的一些著名域對應的字符串定義為一個字節，並在對這些緊湊格式編碼時加上 0x80，使著名域的編碼大於 127（擴展 ASCII字符），從而將它們與普通 ASCII字符區別開。因此 MMS信息頭的基本編碼格式為：“域編碼”＋“內容”，詳情請參考表 1。編碼順序如下：消息類型、事務 ID、版本號必須依次排在最前面，而 MMS信息體內容類型則應該排在 MMS信息頭的最后。
MMS PDU頭域分析和頭域編碼
每個MMS PDU都是由MMS頭域和MMS消息體組成，MMS PDU中的頭域由客戶端指定，一些頭域也可以被分發代理修改或補充，分發代理使用這些頭域信息生成MM通知以及構造接收MM的PDU中的相關頭域，連同消息實體一同送往接收方，消息體跟在頭域之后。大多數MMS PDU只含有頭域，它們起到建立和維持通信的作用，消息體只用在M-Send.req和M-Retrieve.conf PDU中。
MMS頭域根據WAP-209協議和RFC2387的規定，由一系列的域組成，這些域定義了PDU的各種屬性，包括PDU類型，接受方，發送方，發送時間等，頭域中的域名分為可選項和必選項。在編碼MMS頭域時，X-Mms-Message-Type ,X-Mms-Transaction-ID和X-Mms-MMS-Version必須位於MMS頭的開始，並且按照前面所列的順序。Content-Type必須在MMS頭域的最后，其后為消息體，其它域的順序可以隨意安排。
參考表 1
| Name | Assigned Number |
| Bcc | 0x01 |
| Cc | 0x02 |
| X-Mms-Content-Location | 0x03 |
| Content-Type | 0x04 |
| Date | 0x05 |
| X-Mms-Delivery-Report | 0x06 |
| X-Mms-Delivery-Time | 0x07 |
| X-Mms-Expiry | 0x08 |
| From | 0x09 |
| X-Mms-Message-Class | 0x0A |
| Message-ID | 0x0B |
| X-Mms-Message-Type | 0x0C |
| X-Mms-MMS-Version | 0x0D |
| X-Mms-Message-Size | 0x0E |
| X-Mms-Priority | 0x0F |
| X-Mms-Read-Report | 0x10 |
| X-Mms-Report-Allowed | 0x11 |
| X-Mms-Response-Status | 0x12 |
| X-Mms-Response-Text | 0x13 |
| X-Mms-Sender-Visibility | 0x14 |
| X-Mms-Status | 0x15 |
| Subject | 0x16 |
| To | 0x17 |
| X-Mms-Transaction-Id | 0x18 |
| X-Mms-Retrieve-Status | 0x19 |
| X-Mms-Retrieve-Text | 0x1A |
| X-Mms-Read-Status | 0x1B |
| X-Mms-Reply-Charging | 0x1C |
| X-Mms-Reply-Charging-Deadline | 0x1D |
| X-Mms-Reply-Charging-ID | 0x1E |
| X-Mms-Reply-Charging-Size | 0x1F |
| X-Mms-Previously-Sent-By | 0x20 |
| X-Mms-Previously-Sent-Date | 0x21 |
| X-Mms-Store | 0x22 |
| X-Mms-MM-State | 0x23 |
| X-Mms-MM-Flags | 0x24 |
| X-Mms-Store-Status | 0x25 |
| X-Mms-Store-Status-Text | 0x26 |
| X-Mms-Stored | 0x27 |
| X-Mms-Attributes | 0x28 |
| X-Mms-Totals | 0x29 |
| X-Mms-Mbox-Totals | 0x2A |
| X-Mms-Quotas | 0x2B |
| X-Mms-Mbox-Quotas | 0x2C |
| X-Mms-Message-Count | 0x2D |
| Content | 0x2E |
| X-Mms-Start | 0x2F |
| Additional-headers | 0x30 |
| X-Mms-Distribution-Indicator | 0x31 |
| X-Mms-Element-Descriptor | 0x32 |
| X-Mms-Limit | 0x33 |
如HEX數據：8C 80 8D 90 85 04 4CA72474
8C—表示X-Mms-Message-Type
80— m-send-req
8D— X-Mms-Version
90— MMS Version值1.0
85— 表示date
04— 表示date的數據長度
4CA72474 -表示date的數據Little-endian，從1970年開始到現在的秒數
96—subject主題
89— 表示From
97— 表示From
From=0x89+長度+ 0x80+地址+0x00（收到時解碼用） 還有發送時用的格式：0x89, 0x01, 0x81 以0x81為標記的占位符,發送時自動插入發送號碼From=0x97+內容+0x00
CC =0x82+號碼+0x00
subject=0x98+長度+字符集+字符串+0x00;//（常為用Utf8長度+2）+0xEA+內容+0x00
...
以上分析的就是一個典型的MMS PDU消息格式，按上面參考表 1配合WAP-209文檔說明，很輕松的就解碼了