1。cmpp3.0 超長簡訊
1、長短資訊：是指超過70個漢字，140個位元組的資訊內容。
最近在做乙個某地市公司運營商的gprs導引專案的時候，運營商要求將對使用者的提示簡訊息（超過140個位元組）傳送到使用者手機，在使用者的手機上一次全顯示。
上網搜尋了一些相關的資料，現在將實現總結如下:
1.1.1.1 cmpp_submit訊息定義（sp--->smg）
欄位名位元組數
屬性描述
msg_id
unsigned integer
資訊標識。
pk_total 1
unsigned integer
相同msg_id的資訊總條數，從1開始。
pk_number 1
unsigned integer
相同msg_id的資訊序號，從1開始。
registered_delivery
unsigned integer
是否要求返回狀態確認報告：
0：不需要；
1：需要。
msg_level
unsigned integer
資訊級別。
service_id
octet string
業務標識，是數字、字母和符號的組合。
fee_usertype
unsigned integer
計費使用者型別字段：
0：對目的終端msisdn計費；
1：對源終端msisdn計費；
2：對sp計費；
3：表示本欄位無效，對誰計費參見fee_terminal_id字 段。
fee_terminal_id
octet string
被計費使用者的號碼，當fee_usertype為3時該值有效，當fee_usertype為0、1、2時該值無意義。
fee_terminal_type
unsigned integer
被計費使用者的號碼型別，0：真實號碼；1：偽碼。
tp_pid
unsigned integer
gsm協議型別。詳細是解釋請參考gsm03.40中的9.2.3.9。
tp_udhi 1
unsigned integer
gsm協議型別。詳細是解釋請參考 gsm03.40中的9.2.3.23,僅使用1位，右對齊。
msg_fmt 1
unsigned integer
資訊格式：
0：ascii串；
3：簡訊寫卡操作；
4：二進位制資訊；
8：ucs2編碼；
15：含gb漢字。。。。。。
msg_src
octet string
資訊內容**(sp_id)。
feetype
octet string
資費類別：
01：對「計費使用者號碼」免費；
02：對「計費使用者號碼」按條計資訊費；
03：對「計費使用者號碼」按包月收取資訊費。
feecode
octet string
資費**（以分為單位）。
valid_time
octet string
存活有效期，格式遵循smpp3.3協議。
at_time
octet string
定時傳送時間，格式遵循smpp3.3協議。
src_id
octet string
源號碼。sp的服務**或字首為服務**的長號碼, 閘道器將該號碼完整的填到smpp協議submit_sm訊息相應的source_addr欄位，該號碼最終在使用者手機上顯示為短訊息的主叫號碼。
destusr_tl
unsigned integer
接收資訊的使用者數量(小於100個使用者)。
dest_terminal_id
32*destusr_tl
octet string
接收簡訊的msisdn號碼。
dest_terminal_type
unsigned integer
接收簡訊的使用者的號碼型別，0：真實號碼；1：偽碼。
msg_length 1
unsigned integer
首席資訊官度(msg_fmt值為0時：<160個位元組；其它<=140個位元組)，取值大於或等於0。
msg_content
msg_length
octet string
資訊內容。
linkid
octet string
點播業務使用的linkid，非點播類業務的mt流程不使用該欄位。
紅 色部分表示發長簡訊要更改的字段
洋紅色部分表示發長簡訊可以更改或者不更改的字段
（以下資料參考：
在cmpp協議裡，cmpp_submit訊息定義中有相應的引數配置：
tp_udhi ：0代表內容體裡不含有協議頭資訊 1代表內容含有協議頭資訊（長簡訊，push簡訊等都是在內容體上含有頭內容的）當設定內容體包含協議頭，需要根據協議寫入相應的資訊，長簡訊協議頭有兩種：
6位協議頭格式：05 00 03 xx mm nn
byte 1 : 05, 表示剩餘協議頭的長度
byte 2 : 00, 這個值在gsm 03.40規範9.2.3.24.1中規定，表示隨後的這批超長簡訊的標識位長度為1（格式中的xx值）。
byte 3 : 03, 這個值表示剩下簡訊標識的長度
byte 4 : xx，這批簡訊的唯一標誌，事實上，sme(手機或者sp)把訊息合併完之後，就重新記錄，所以這個標誌是否唯
一併不是很 重要。
byte 5 : mm, 這批簡訊的數量。如果乙個超長簡訊總共5條，這裡的值就是5。
byte 6 : nn, 這批簡訊的數量。如果當前簡訊是這批簡訊中的第一條的值是1，第二條的值是2。
例如：05 00 03 39 02 01
7 位的協議頭格式：06 08 04 xx xx mm nn
byte 1 : 06, 表示剩餘協議頭的長度
byte 2 : 08, 這個值在gsm 03.40規範9.2.3.24.1中規定，表示隨後的這批超長簡訊的標識位長度為2（格式中的xx值）。
byte 3 : 04, 這個值表示剩下簡訊標識的長度
byte 4-5 : xx xx，這批簡訊的唯一標誌，事實上，sme(手機或者sp)把訊息合併完之後，就重新記錄，所以這個標誌是否唯一並不是很重要。
byte 6 : mm, 這批簡訊的數量。如果乙個超長簡訊總共5條，這裡的值就是5。
byte 7 : nn, 這批簡訊的數量。如果當前簡訊是這批簡訊中的第一條的值是1，第二條的值是2。
例如：06 08 04 00 39 02 01
二. 實現**(c#)
byte messageucs2 = encoding.bigendianunicode.getbytes(mtmsg);
int messageucs2len = messageucs2.length;
int maxmessagelen = 140;
if (messageucs2len > maxmessagelen)
else
三、總結。
cmpp髮長簡訊
1、tp_udhi設定為 0x01
2、msg_content 按tp_udhi協議填寫6位元組或者7位元組的tp_udhi協議頭然後加上經過usc2編碼的訊息內容。由tp_udhi協議頭和訊息內容體組成的 msg_content總長度不能超過140個位元組
3、 msg_fmt 設定為 0x08 ucs2編碼；
4、pk_total和pk_number 可以不設定，如果要設定，就要分別跟tp_udhi的mm和nn欄位一致
cmpp2 0長簡訊的處理方案
長簡訊處理方案 上次寫過對簡訊傳送的處理,並沒有體現出對長簡訊的處理方案,在實際應用中發現了以下問題,對於簡訊長度超過指定的大小時會出現截短的現象.1 這種方案是處理長簡訊的方式 可以實現向客戶端傳送的連續的多條簡訊合併成一條在客戶端的手機上顯示 華為簡訊傳送類處理 公用類 param 簡訊類，包括...
傳送超長簡訊的協議格式
cmpp 協議中，cmpp submit message中有兩個欄位pk total和pk numer，恰看起來，這就是傳送超長簡訊的設定引數，其實不然，這兩個引數的設定，應該是沒有用處。傳送超長簡訊，需要做兩件事情 設定tp udhi的值設定為1，在訊息正文中增加協議頭。協議後可以兩種格式，分別是...
傳送超長簡訊的協議格式
cmpp協議中，cmpp submit message中有兩個欄位pk total和pk numer，恰看起來，這就是傳送超長簡訊的設定引數，其實不然，這兩個引數的設定，應該是沒有用處。傳送超長簡訊，需要做兩件事情 設定tp udhi的值設定為1，在訊息正文中增加協議頭。協議後可以兩種格式，分別是長...