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

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/

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

Thanks for your offer, but I have everything I need in this area .
I used the GNU iconv library because there are many characters in the GSM-7 alphabet that are not in the ASCII character set. In fact GSM-7 contains characters (from languages like Greek, Danish, Spanish) that can’t be mapped to any single byte character set (like iso8859-1), so to get access to the full range of characters offered by GSM-7 you’ll have to use UCS-4, UCS-2 or UTF-8.

Cheers,
Jeroen