On Wed, Jun 30, 2004 at 01:29:07PM +0200, Biot Olivier wrote:
> You're most certainly correct. The code page in use in Brazil probably is an
> ISO-LATIN variant (ISO-8859-1 maybe), for which the 128 8-bit characters
> (values 128 to 255) have a different encoding in UTF-8. The GTK2 interface
> expects UTF8-encoded text and sees some bytes which seemingly are not
> encoded as UTF-8 hence the Pango rendering engine is complaining :)
>
> Sounds like we'll have to add locale and charset translation support to
> Ethereal :)
What we should add eventually is:
a way for a dissector to indicate that a string extracted from
the protocol is in some character set encoding (note that the
encoding of a particular string in a particular packet will not
necessarily be supported by "iconv()" on the platform on which
Ethereal is running, and some platforms might not even have
"iconv()", so we can't just use "iconv()" - we might be able to
take the GNU libiconv code, give it another name to avoid
namespace collisions, and supply our own conversion tables, *if*
all the encodings we'd support can be handled by "iconv()");
a way to translate from that to UTF-8 for GTK+ 2.x (and somehow
translate to the appropriate encoding for the font being used
for GTK+ 1.2[.x]; other toolkits will probably support 16-bit
Unicode, e.g. Windows, although we might need whatever that
Microsoft add-on is to add Unicode support to Windows 95/98/Me,
or UTF-8, so I suspect GTK+ 1.2[.x] is the only platform for
which we'd need that, although that would also require either
that the platform do something reasonable with characters for
which it has no glyph or let us find out whether there is a
glyph for the character);
a way to translate from that to the appropriate character
encoding for:
text output in Tethereal;
printing to a printer (which will probably eventually
become platform-dependent);
saving the summary or detail dissection to a text file.
For now, we should just make heavy use of "format_text()" and
"tvb_format_text()", which will escape non-printable characters (which,
for GTK+ 2.x, is translated as "non-ASCII characters" - yes, that's a
deficiency, but fixing that deficiency requires that we know what
encoding the characters are in...).
