С.Кадаков
sgerr@clubpro.spb.ru
Выше, дальше, сильнее. Это все про SMS?

Предыдущую статью следует считать некоей точкой в повествовании об SMS. Была еще мысль сделать -- небольшой на пару статей -- обзор остальных протоколов, но потом я от нее отказался по двум причинам. Во-первых, такой обзор получиться бы мог весьма скомканным. А во-вторых, работа с различными протоколами, _по_сути_, одинакова (бес, как известно, в деталях :). Думается, что ознакомившись с предыдущими статьями, читатель сможет построить клиента, способного отсылать и принимать _текстовые_ короткие сообщения по спецификациям любого протокола. Что же дальше? Хороший вопрос, и не менее хороший ответ: а, собственно, дальше и начнется рассмотрение технологий используемых в _современных_ сервисах. Я имею ввиду технологии EMS/MMS, принимающие статус отраслевых стандартов, и корпоративные технологии доставки rich media контента на мобильные устройства, то есть то, что относится к так называемым сетям 3G. Но сначала, для того, чтобы "закруглить тему" поговорим еще немного о тексте.

Часто (точнее -- всегда) недостаточно передавать только латинский текст, да и передача собственно "иностранных" сообщений, содержащих специальные символы требует некоторых дополнительных усилий. Таким образом вполне закономерно теперь поговорить о кодировке текста в сообщениях.

Видимо не секрет для читателей, уже разбиравшихся с протоколами SMS, что в мобильной сети сообщения большей частью передаются в так называемой кодировке GSM. Это семибитная кодировка -- каждый передаваемый символ предатавляется 7-ю старшими битами октета, младший бит относится уже к следующему символу. В следующем октете "отсекаются" уже два бита, и так далее, до тех пор, пока на 8-м октете символы опять не выровняются на границе. Не Бог весть какое сжатие, но позволяет сэкономить каждый восьмой октет, или, другими словами, впихнуть в 140 октетов пресловутые 160 символов. Приведем таблицу кодировки GSM (в сравнении с IA5):

Выбор кодировки осуществляется полем 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 из GSM 03.38. Биты 7..4 (Coding Group Bits) Значение битов 3..0

00xx	Если бит 5 не установлен, то текст считается не сжатым, в противном случае используется стандартное сжатие GSM (в GSM 03.38 не описано). Если бит 4 не установлен, считается, что биты 1 и 0 не несут смысловой нагрузки и зарезервированы, в противном случае биты 1 и 0 указывают на класс сообщения: Бит 1 Бит 0 Значение 0 0 Class 0 0 1 Class 1 1 0 Class 2 1 1 Class 3 Биты 3 и 2 указывают на алфавит: Бит 3 Бит 2 Значение 0 0 Default alphabet (7 bit) 0 1 8 bit 1 0 UCS 2 (16 bit) -- Unicode 1 1 Зарезервировано Частный случай DCS = 0x0 -- 0000 0000(bin) -- означает Default alphabet с неуказанным классом.
0100..1011	Зарезервировано
1100,1101,1110	Эти группы используются, когда, наряду с передачей текста, пользователя необходимо уведомить о том, что на его адрес получены сообщения других типов (Message Waiting Indication group), напрмер сообщения Voice Mail, FAX, E-Mail или сообщение другого типа. Аппарат может уведомить пользователя с помощью иконки на экране (индикатора) или другим способом. При этом: Группа 1100 предписывает аппарату просто изменить состояние индикатора, не сохраняя при этом собственно текст SM Группа 1101 предписывает изменить состояние индикатора и сохранить текст SM. Текст имеет кодировку Default alphabet. Группа 1101 предписывает изменить состояние индикатора и сохранить текст SM. Текст имеет кодировку UCS2 -- Unicode. Бит 3 при этом может принимать значения: 0 - отключить индикатор 1 - включить индикатор Биты 1 и 0 указывают на тип ожидающего сообщения: Бит 1 Бит 0 Значение 0 0 Voice Mail 0 1 FAX 1 0 E-Mail 1 1 Другое
1111	Бит 3 не используется и устанавливается в 0. Бит 2 указывает кодировку и может принимать значения: 0 - Default alphabet. 0 - 8 bit. Биты 1 и 0 указывают на класс сообщения. Бит 1 Бит 0 Значение 0 0 Class 0 0 1 Class 1 1 0 Class 2 1 1 Class 3

Принимая во внимание вышесказанное приведем примеры: для передачи Flash сообщения, содержащего русское "Привет от Иванова!" нужно использовать DCS = 0x18, а для передачи двоичных данных (напрмер -- тех же картинок и мелодий) используется DCS=0xF5.

Вот мы и подошли вплотную к передаче rich media. Следующая статья будет посвящена передаче мелодий, логотипов, графики (точнее, с нее начнется обсуждение этих вопросов). Это еще не совсем 3G, но уже и не просто текст. Оставайтесь с нами!