Wireshark · Ethereal-dev: Re: [Ethereal-dev] While we're on the subject of new frametypes...

[Guy Harris <guy@xxxxxxxxxx>]

On Thu, Dec 12, 2002 at 11:14:42PM -0800, Guy Harris wrote:
> 	2) As long as we're going down that path, should we store *all*
> 	   strings as Unicode in the protocol tree, and just keep the
> 	   existing FT_STRING types, and:
> 
> 		perhaps have the byte-order argument to
> 		"proto_tree_add_item()" specify, for FT_STRING types,
> 		the character set and, in cases where a multi-byte
> 		character type can come in either byte order, the byte
> 		order;
> 
> 		add a character set+byte order argument to
> 		"proto_tree_add_string()"?
> 
> 	   That complicates life for GTK+ 1.2[.x], as you have to figure
> 	   out what character encoding is being used for the font, and
> 	   translate into that.  However, GTK+ 2.x, and the Win32 GTK+
> 	   1.3[.x], use UTF-8, so we should be able to make that work
> 	   reasonably well.  Doing so *might* fix *some* of the problems
> 	   people are reporting on Windows.

Hmm.

It may be that, in GTK+ 1.2[.x], we can load fontsets rather than fonts
for the main text fonts, in which case it appears that the GDK functions
that take "gchar *" pointers as arguments treat the pointers as pointing
to strings that are multibyte-encoded strings according to the current
locale.  GDK includes "gdk_wcstombs()" and "gdk_mbstowcs()" functions to
convert between "wide character" strings (in which each character is the
same number of bytes long, and is a GdkWChar) and multibyte-encoded
strings.

I don't know offhand whether the character set for "wide character"
strings is always UCS-2 or UCS-4, or depends on the locale.