长短信是一种特殊的短信格式，它允许发送超过 70 个汉字的信息内容，但需要将其拆分成多条短信，然后在接收端组合成原始短信内容。 我们需要了解短信内容的大小限制。根据目前的通信技术条件，手机单条短信发送的文本信息的信息量限制为 160 个英文字符，或者 140 个字节的二进制信息，即 70 个汉字（包括标点符号）。英文字母采用 7 位 ASCII 编码，而汉字则采用 8 位 UCS-2 编码并占 2 个字节。因此，160 个字符按照 7 位 ASCII 编码来换算，即 160*7=1120 位，而汉字是按照 8 位的 UCS-2 编码，即 8 位一个字符，一个汉字占 2 个字符，这样 1120 位换算成汉字数就是 1120/8/2=70。 长短信的发送需要短信通道功能的配合，如果通道本身没有这个功能，那么就会被分成多条短信显示。而对于长短信来说，拆分成短短信之后，每条短短信的规定与单条短信的规定又有所不同。长短信实际也是由普通短信方式发送的，每条短信也是 70 字，只是每条短信头部有特殊标记，这也需要占一定的字符，一般情况有 6–16 个字节分别定义短信唯一标识以及该短信是第几条（特殊标记所占字符根据不同情况而定），所以长短信发送时每条实际为 62–67 个汉字。
在 CMPP 协议中，需要设置 TP_udhi 的值设置为 1，以便在消息正文中增加协议头。在 SGIP 协议中，对 TP_udhi 的解释如出一彻“GSM 协议类型。详细解释请参考 GSM03.40 中的 9.2.3.23,仅使用 1 位右对齐”。GSM 03.40 规范 TP-06 1999-12-15 7.4.0 中规定了 SME 对于超长短信的合并处理，当前绝大部分 GSM 手机都支持超长短信。
超长短信编码需要首先把 TP_udhi 的值设置设置为 1，在消息正文中增加协议头，然后在每条超长短信分割而成的短信中增加协议头，协议头分两种，分别是长度为 6 和长度为 7 的协议头。具体配置如下：CMPP 协议 SUBMIT 数据包相关字段配置：TP_pid：0（GSM 协议类型。详细解释请参考 GSM03.40 中的 9.2.3.9），PID 一般文本的时候设 0，铃声图片设 1；TP_udhi：1（GSM 协议类型。详细解释请参考 GSM03.40 中的 9.2.3.23，仅使用 1 位，右对齐），说明 UDHI 设为 0 的时候表示短消息内容中不包含头部信息：一般文本设置为 0；UDHI 设为 1 的时候表示短消息内容中包含头部信息：一般在图片、铃声、长短信，push 短信这类消息种设置为 1，长短信格式也填 1；Msg_Fmt：8（信息格式 0：ASCII 串，3：短信写卡操作，4：二进制信息，8：UCS2 编码 15：含 GB 汉字）。 在凌凯短信平台上，支持一次提交内容 1-500 字，单条短信是 70 字计费一条，而长短信是 67 字（或者 62 字、65 字，根据不同情况而定）计费一条，最后由平台智能处理短信，会根据不同网关自动处理短信，用户可以通过预览功能详细了解短信计费情况。
此外，凌凯短信平台还支持多网关自动切换，移动、电信、联通等通道自动切换，最大程度的解决端口拥堵现象，保证信息及时送出；以及多通道自动补发，保证每条信息的快速、准确到达。
第二章长短信发送和合并机制研究
在 GSM 标准中，规定了一条普通短信最多只能支持70个汉字，并且基于 SMPP / CMPP 等协议的短信网关、 IOD 等都对单条短信的字数进行了限制，使内容较长的信息难于通过短信来发送，短信的应用受到了很大的限制。目前为了解决此类问题，普遍采用的是信息拆分的方法，将信息内容拆分成多条短信发送，每条短信辅以辅助信息以便于接收端阅读，例如第一条、续前等，这种方式存在以下两个主要问题：1、短信到达顺序错乱：2、某条或某几条短信接收不成功；这些问题都会造成解读阅读不便、无法正确理解等诸多问题，客户满意度低，严重影响了市场的推广。
论文本章首先介绍点对点短信中关于短信合并的协议，进而通过在短信中心以及短信网关上抓包研究验证子短信头结构设置，借鉴点对点长短信的头结构，构造出梦网短信上如何进行短信头结构设置，从而在梦网短信应用中实现长短信发送和合并。
2.1点对点长短信合并机制
在 GSM 网络中发送短信时，每条短消息的内容长度最大可以达到160个字符(7bits的编码），或者是160x7bits/16bits=70个汉字（2bytes的 UNICODE 编码）。根据 GSM 03.40协议标准，通过发送可以合并的短信从而使得一条短信支持远远超过160字符的功能。例如 nokia 手机9000i和9110两个型号的手机可以支持合并长达2280字符长度的一条短信。为了合并多条短信为一条，需要在现有短信格式基础上在用户数据部分（ userdata ，即短信内容部分）定义一个报头用于标识各个分拆短信相互之间的关系，同时用这个报头控制接收端进行多条短信的合并。根据 GSM 03.40协议该报头封装在原短信内容中的用户数据，占用140个 byte 中前6个 byte ，这样剩余134个 byte 用于表示用户的短信内容。
报头（ header ）格式如下：
报头分成6个部分，每一部分都界定为一个 byte :
报头中第一个字段（ byte ）指定整个报头的长度，该字段取值固定为5，表示接下来的5个 byte 是头部分；
第二字段定义了该短信信息元素标识，值为0用于标识该短信是需要合并的短信（ concatenated SMS );
第三个字段是剩下报头消息长度，由于还有3个 byte 用于长短信的头，所以该字段为3。经过在短信中心以及短信网关上抓包验证，确认前3个 byte 为050003。
第四个字段是用来标识整个合并短信的参考数字标识，用于在短信发送端标识不同的长短信，每次在发送端发送长短信时，该值将会在前一个长短信该值的基础上加1，用于区分不同的长短信（由于该字段为1个 byte ，所以取值范围1-255，即同时在发送端同时可以发送255条长短信）接收终端会根据参考数字标识及源号码鉴别是否同一条长短信；
第五个字段表示该长短信被分成几个标准长度子短信（在该情况下比原来140个 byte 要少，可以达到134个 byte );
第六个字段用于标识当前子短信在长短信中位置（序列号），用于控制接收端进行长短信合并，接收终端在合并长短信时会根据此值来决定子短信在合并时的逻辑顺序；协议引申：根据报头中第五个字段（1个 byte ）用于表示一个长短信最多能被分拆为255(2的8次幂＝256，由于数值0不用，所以有255）个子短信，这样一个长短信理论上最多可以容纳67字x255=17085个汉字，如果是7bits编码下，大概可以达到34k左右的容量。
当然这只是理论上的推导，还需要发送端以及接收端的支持。象上文中提到 nokia 的两款手机最多就只能支持2280个字符的合并。另外在发送长短信时，需要设置 TPDU 报文中 UDHI ( userdata header information ）参数的值为1，这样表示用户数据部分（ UD ）包含报头，该部分是结构化的。在发送普通短信情况下， UDHI 值会设置为0（缺省值），表示用户数据部分是正常的字符串，非结构化内容。
2.2长短信发送技术研究
2.2.1梦网长短信实现关键技术分析
在梦网短信应用时， SP 需要采用短信网关厂家提供的基于 CMPP 协议 API 函数库，通过 IP 网络连接短信网关，通过 API 函数库中的短信提交和接收等函-
等向短信网关提交或接收短信，然后由短信网关通过 SMPP 协议向短信中心提交或接收对应的短信。
2.4基于 CMPP 协议实现长短信上行合并
SP 利用基于 CMPP 协议的 API 函数库连接短信网关，实现短信的发送和接收，上文中论文已经就如何通过短信网关实现长短信下发做了阐述，下面就手机终端侧发送上行长短信给 SP , SP 进行正确的合并。 SP 接收手机上行短信，首先根据 UDHI 判断该短信是否存在结构化信息头，若 UDHI 设置为1，则在用户数据部分存在结构化信息头，读取用户数据部分，以合并短信为例（其他类型的短信例如 wap push 等，本文不在这里赘述，请参考 GSM 03.40协议），第一个字节为05，表示从第二个字节开始共5个 byte 用于头部信息。第二个字节为0，表示为合并短信类型，第三个字节为3，表示紧接着的3个 byte 为合并短信的信息，第四个字节为长短信的标识， SP 依靠该标识以及发送方号码用于不同长短信的区分以及正确合并；第五个字节为该长短信被分拆为多少个子短信，第六个字节为当前这条子短信是该长短信的第几个子短信，后面的内容为短信内容部分，这样 SP 在接收完整的各条子短信后，按照次序进行组装，从而实现正确合并呈现上行的短信内容。
网店管家云端版：揭秘电商新势力，云端智慧助力店铺腾飞
键盘类型终极指南：从结构原理到场景化选择