Comments on: GSM-7 Encoding with the GNU iconv library

By: Marcin

Marcin — Tue, 05 Apr 2011 11:38:16 +0000

You made my day. Thanks!

By: Nico

Nico — Wed, 03 Nov 2010 02:58:44 +0000

Hello Jeroen,

Thanks for theses precious infos !
I have troubles to modify the iconv library from your post.
(I’m running a X86_64 Ubuntu 10.04 if it matters).
After ‘make’ I’m told : In file included from ./iconv.c:108:
./encodings.def:43: error: ‘ei_gsm7_oflags’ undeclared here (not in a function)
Might you assist a bit ?
Thanks in advance for your time and efforts !

By: Minhaj

Minhaj — Wed, 16 Jun 2010 10:04:44 +0000

Hello JEROEN
Your article about concatenated sms sending is just awesome , but I would like to know that how do I get my padding bits added in my GSM-7 Character set in java , I have get my PDU but dont know how to add the padding bits finally after getting the PDU

By: Felix

Felix — Wed, 12 May 2010 19:29:50 +0000

Hi.

Does anyone got the php PDU file?. I’m trying with SMS. Thanks.

By: Lakshmi chinta

Lakshmi chinta — Tue, 11 May 2010 22:05:31 +0000

Hey,

Can you please explain what is “n” which is a parameter to gsm7_wctomb(conv_t conv, unsigned char *r, ucs4_t wc, int n)

By: siva prasad

siva prasad — Sat, 13 Mar 2010 19:13:29 +0000

Hai Franco,
plz send me the php fuctions for encoding and decoding GSM-7 format.
My e-mail:siva2prasad2007@yahoo.co.in

By: Jeroen

Jeroen — Thu, 10 Sep 2009 03:02:13 +0000

Geir,

I had sent an email to that mailing list right after I published this article. I got a response saying that libiconv is more for streaming applications and SMS messages are short and a simpler API is more appropriate. It was also noted that some later standards on GSM-7 encodings include language specific escape codes for diffent western alphabets (like Turkish), in this case my algorithm would not work…. I’ll continue to use my version of libiconv in SMS software I write and will probably address the language specifica escape codes and update the article for this. If anything; though this article I complied with the LGPL requirements to publish any enhancements.

Regards,
Jeroen

By: Geir

Geir — Tue, 08 Sep 2009 14:56:18 +0000

if you haven’t already done so; would you please consider submiting your changes to the libiconv project? Their mailing list:

bug-gnu-libiconv @ gnu.org — for discussing bugs and features of GNU libiconv. An archive for this list can be found at http://lists.gnu.org/archive/html/bug-gnu-libiconv/

By: Franco

Franco — Mon, 20 Jul 2009 23:58:36 +0000

Jeroen:
Thanks again.
You wrote 22 lines full of characters and of a huge amount of helpful knowledge (unmeasurable).
Regards
Franco

By: Jeroen

Jeroen — Mon, 20 Jul 2009 16:50:46 +0000

There are standards for compressing and decompressing SMS messages, but a.f.a.i.k. nobody has implemented them. There are plenty of SMS applications for various smart-phones that will compress SMS messages, but they all require the same app to be running on the sender and the receiver’s phone.

I don’t get your question of ‘which is best’… Do you mean for use by SMS applications?
- UCS-4 uses 4 octets per Unicode character. This is the most wasteful. All well-known character sets around the world can be coded with 2 octets (UCS-2).
- UCS-2 uses 2 octets per Unicode character. This is wasteful for messages that consist largely of ASCII characters (as used in US and Western European languages). For these messages UTF-8 is more efficient.
- UTF-8 is an encoding of UCS-2 and UCS-4. If used with UCS-4 it will use 1-5 octets per character, if used with UCS-2 it will use 1-3 octets per character. If the you’re dealing with text in Chinese or Japanese, most characters would require 3 octets if you encode them using UTF-8. For these languages UCS-2 is the most efficient.

Since phones only support GSM-7 and/or UCS-2 you should use GSM-7 for English and other Western European languages and use UCS-2 for Chines, Japanese and the likes. Which is just how it was intended.

Though all phones will display UCS-2 messages, doesn’t mean it will correctly display all the characters in the world. What it manages to display depends on which fonts it has installed, which is highly localized (Chinese phones will support Chinese but US phones won’t).

Cheers,
Jeroen