Это все про SMS?
Предыдущую статью следует считать некоей точкой в повествовании об SMS. Была еще мысль сделать -- небольшой на пару статей -- обзор остальных протоколов, но потом я от нее отказался по двум причинам. Во-первых, такой обзор получиться бы мог весьма скомканным. А во-вторых, работа с различными протоколами, _по_сути_, одинакова (бес, как известно, в деталях :). Думается, что ознакомившись с предыдущими статьями, читатель сможет построить клиента, способного отсылать и принимать _текстовые_ короткие сообщения по спецификациям любого протокола. Что же дальше? Хороший вопрос, и не менее хороший ответ: а, собственно, дальше и начнется рассмотрение технологий используемых в _современных_ сервисах. Я имею ввиду технологии EMS/MMS, принимающие статус отраслевых стандартов, и корпоративные технологии доставки rich media контента на мобильные устройства, то есть то что относится к так называемым сетям 2.5G. Но сначала, для того, чтобы "закруглить тему" поговорим еще немного о тексте.
Кодировка.
Часто (точнее -- всегда) недостаточно передавать только латинский текст, да и передача собственно "иностранных" сообщений, содержащих специальные символы требует некоторых дополнительных усилий. Таким образом вполне закономерно теперь поговорить о кодировке текста в сообщениях.
Видимо не секрет для читателей, уже разбиравшихся с протоколами SMS, что в мобильной сети сообщения большей частью передаются в так называемой кодировке GSM. Это семибитная кодировка -- каждый передаваемый символ предатавляется 7-ю старшими битами октета, младший бит относится уже к следующему символу. В следующем октете "отсекаются" уже два бита, и так далее, до тех пор, пока на 8-м октете символы опять не выровняются на границе. Не Бог весть какое сжатие, но позволяет сэкономить каждый восьмой октет, или, другими словами, впихнуть в 140 октетов пресловутые 160 символов. Приведем таблицу кодировки GSM (в сравнении с IA5):
Кодировка GSM.
Выбор кодировки осуществляется полем data_coding в submit_sm, о котором писано уже парой статей выше. Таким образом, при выборе кодировки 0x0, (SMSC default alphabet) можно надеятся, что центр воспримет текст сообщения именно в стандартной кодировке GSM.
Вообще говоря кодировке сообщений посвящен документ GSM 03.38, в котором возможные значания параметра data_coding (DCS -- data coding scheme) рассмотрены весьма подробно. Посмотрим и мы на них, так как этим параметром регулируется еще одна вещь: так называемый класс сообщения.
Класс сообщения.
Класс сообщения является своего рода "указанием" для принимающей стороны (SME, или мобильного терминала), как с этим сообщением поступить (в основном это, разумеется, относится к Mobile Terminated -- MT -- "предназначенным для мобильного устройства" сообщениям). Приняв сообщение, устройство может поступить с ним следующим образом:
- Немедленно отобразить. (Class 0)
- Записать в память устройства. (Class 1)
- Записать в память SIM-карты. (Class 2)
- Передать на терминальное устройство. (Class 3)
Сообщения класса 3 описаны в GSM TS 07.05 и здесь мы не будем на них останавливаться. С остальными классами, надеюсь, все ясно без комментариев. Можно только добавить, что сообщения 0-го класса называются также "Flash messages" и могут быть потеряны сразу же после прочтения.
Спецификация DCS.
А теперь приведем, наконец, описание DCS из GSM 03.38.
| Биты 7..4 (Coding Group Bits) | Значение битов 3..0 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 00xx | Если бит 5 не установлен, то текст считается не сжатым, в противном случае используется стандартное сжатие GSM (в GSM 03.38 не описано). Если бит 4 не установлен, считается, что биты 1 и 0 не несут смысловой нагрузки и зарезервированы, в противном случае биты 1 и 0 указывают на класс сообщения:
Биты 3 и 2 указывают на алфавит:
Частный случай DCS = 0x0 -- 0000 0000(bin) -- означает Default alphabet с неуказанным классом. | ||||||||||||||||||||||||||||||
| 0100..1011 | Зарезервировано | ||||||||||||||||||||||||||||||
| 1100,1101,1110 | Эти группы используются, когда, наряду с передачей текста, пользователя необходимо уведомить о том, что на его адрес получены сообщения других типов (Message Waiting Indication group), напрмер сообщения Voice Mail, FAX, E-Mail или сообщение другого типа. Аппарат может уведомить пользователя с помощью иконки на экране (индикатора) или другим способом. При этом:
Бит 3 при этом может принимать значения:
Биты 1 и 0 указывают на тип ожидающего сообщения:
| ||||||||||||||||||||||||||||||
| 1111 | Бит 3 не используется и устанавливается в 0. Бит 2 указывает кодировку и может принимать значения:
Биты 1 и 0 указывают на класс сообщения.
|
Принимая во внимание вышесказанное приведем примеры: для передачи Flash сообщения, содержащего русское "Привет от Иванова!" нужно использовать DCS = 0x18, а для передачи двоичных данных (напрмер -- тех же картинок и мелодий) используется DCS=0xF5.
Заключение.
Вот мы и подошли вплотную к передаче rich media. Следующая статья будет посвящена передаче мелодий, логотипов, графики (точнее, с нее начнется обсуждение этих вопросов). Это еще не совсем 2.5G, но уже и не просто текст. Оставайтесь с нами!
No comments:
Post a Comment