Wireshark-bugs: [Wireshark-bugs] [Bug 7227] Need full support for character encodings for string
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7227
Guy Harris <guy@xxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Platform|x86 |All
Summary|hebrew letters in wireshark |Need full support for
| |character encodings for
| |strings
OS/Version|Windows XP |All
--- Comment #4 from Guy Harris <guy@xxxxxxxxxxxx> 2012-05-06 11:24:02 PDT ---
(I've pulled the archive apart and attached the individual files, for the
benefit of developers who *don't* happen to have an RAR unarchiver handy.
There's rarely, if ever, a reason to attach a tarball/zipball/RARball/whatever
archiveball to a bug rather than attaching the individual files in the
archive.)
The underlying problem is that Wireshark doesn't handle very many character
encodings. It has a small number of ENC_ values for various character
encodings, but, in practice, the encoding is ASCII or (one flavor of) EBCDIC.
It needs to distinguish between ASCII (and, in an ASCII string, display all
octets with the 8th bit using the "substitute" glyph) and UTF-8 (and, in a
UTF-8 string, display all invalid UTF-8 sequences using the "substitute"
glyph), also support UTF-16 (and UCS-2?), and add support for a bunch of other
"extended ASCII" encodings. We also would need to add an encoding argument to
the routines to fetch strings from the tvbuff.
Supporting that from Lua would require changing the Lua API to add an encoding
argument to the "add" method of TreeItem (which would obsolete the "add_le"
method).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
