[PATCH] Decoding UCS2 USSD

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Pavel Baturko pabftk at gmail.com
Sun Jan 20 20:16:14 UTC 2013


Hi list,

Some time ago I proposed patch for supporting UCS2 USSD decoding,
there was a discussion, but then unfortunately I have not received a
response.
Now I'm back to this subject and made small changes to decode UCS2 SMS
by reusing code from USSD. But before sending new patch for SMS (and
resend updated patch for USSD) I'd like to re-ask my last question in
this thread: what to do with UTF-8 text after converting from UCS2? I
sent patches with 3 variants:
1) Use setlocale to get available locales and set utf if possible and
then print message.
2) Call external *nix command "locale" to check if utf is available
and then print message.
3) Just print hex (with osmo_hexdump e.g.)
I prefer #2, #1 may be also ok, #3 is bad because local (non-English)
GSM providers often send service SMS/USSD messages in UCS2 and in that
case reading hex instead of text is awful, also reading usual SMS from
other MSs in hex uncomfortable too.
Another problem is that using all of these methods makes impossible to
read received SMS/USSD in VTY because AFAIU there is no way to check
if console with VTY will be ok with UTF. Maybe it's possible to add
flag to indicate that VTY can receive text in UTF? This flag may also
cancel auto-detection of terminal's locale and shift responsibility to
the user of this flag. But I'm not sure where this flag should be.. In
my tests I just send decoded UTF text to VTY and all works fine.
Another variant is inform user in VTY that message is printed in
mobile log.

So, what variant to choose when checking if terminal supports UTF?
And how to interact with VTY in case of UTF strings?

Thanks,
Pavel




More information about the baseband-devel mailing list