["John Vincent" <jpv@xxxxxxxxxxx>]

Hi,

I downloaded ethereal-setup-0.10-12-SVN-15203.exe and the poblem with UCS2 encoding is now fixed at least to
the extent that the decoder does not say [Malformed Packet: GSM SMS]. Thanks to Anders Broman for fixing that
:-)

The larger issue of actually displaying unicode fonts is not much of an issue for me personally, since I'm a
bit linguistically challenged (I only understand English :-) ) although I can imagine that it would be very
useful to a large number of people.

Anyway, thanks to Anders, and Guy, and everyone else who gives their time for free to produce this great piece
of software!

/John.

-----Original Message-----
From: Guy Harris [mailto:gharris@xxxxxxxxx]
Sent: Monday, August 01, 2005 7:58 PM
To: jpv@xxxxxxxxxxx; Ethereal user support
Subject: Re: [Ethereal-users] GSM MAP SMS decode


John Vincent wrote:

> I notice that the decode from GSM MAP SMS text does not work
> correctly when the encoding scheme is UCS2 (it works OK for the GSM
> 7-bit alphabet. Would anybody be intersted in fixing that? To fix it
> I guess ethereal needs support for displaying unicode fonts (unless
> it already has that...?)

A limited capability to handle it could be provided simply by ignoring
(or displaying as "\XNNNN") non-ASCII characters.

Displaying Unicode characters is not hard with GTK+ 2.x - GTK+ 2.x
expects to be handed a UTF-8 string.  It's harder with GTK+ 1.2[.x] -
I'm not even sure how to find out the encoding GTK+ 1.2[.x] expects for
strings.

(The native Windows GUI code Gerald's been working on off and on would,
I think, require something such as the Microsoft Layer for Unicode:

	http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx

in order to support W95/W98/WMe.  Were we to do a native KDE version, I
think the version of Qt that KDE 3.x uses handles Unicode natively -
either as UCS-2 or UTF-8; OS X also uses UTF-8 encoded Unicode in the
GUI code.

This also raises issues of file access - recent versions of GLib have
stdio wrapper routines that presumably either do nothing or translate
from UTF-8 to the locale's character set on UN*X, and map to Unicode on
Windows.)

The main thing Ethereal needs is a more sophisticated scheme for
handling strings, as there are a number of different character encodings
that can be used for strings (UCS-2, both little-endian as in SMB and
probably big-endian in some places; UTF-8; ISO 8859/n for various values
of n; assorted other EUC character encodings, e.g. DBCS encodings for
various Asian languages; various non-EUC character encodings, including
DOS/Windows code pages, old Mac character sets, Shift-JIS, KOI-8, etc.,
etc., etc. - oh, and don't forget EBCDIC, if, as I think is the case,
some SNA protocols we dissect use it).

This might also call for us incorporating our own version of iconv, or
something equivalent, as the Single UNIX Specification item on iconv
says that the actual encoding names are implementation-dependent, but we
need a *platform-independent* way for a dissector to specify that a
string is, say, MacRoman or ISO 8859/1 and for the Ethereal core to
translate from that to UTF-8.

See the first item under "Dissector infrastructure" in

	http://wiki.ethereal.com/Development_2fWishlist

> Even if ethereal can't display the message correctly, it would be
> nice if it didn't say [Malformed Packet: GSM SMS] which it does at
> the moment.

I suspect that's a separate problem.