Comment # 3
on bug 13073
from Guy Harris
(In reply to Philippe Rosenfeld from comment #2)
> By bad. You are right.
> However why not representing this as \u0100? currently we are using \u0001
Because the string is treated as being an ASCII string, so that 0x01 0x00 is an
01 - \u0001 followed by an 00 (which is currently not shown as string values
are null-terminated). \u0100 is LATIN CAPITAL LETTER A WITH MACRON:
http://www.fileformat.info/info/unicode/char/0100/index.htm
which isn't part of SSCII. If the string were treated as UTF-8, that character
would be 0xC4 0x80. It would only be \u0100 if the string were treated as
big-endian UTF-16, but if it's big-endian UTF-16, the value for
S7COMM_BLOCKTYPE_OB, which is '0' followed by '8' according to the dissector
source, would be 0x30 0x38, which wouldn't be "08", it'd be \u3038, which is
HANGZHOU NUMERAL 10:
http://www.fileformat.info/info/unicode/char/3038/index.htm
So is that field a 2-character ASCII string - in which case 01 00 isn't a
*printable* value 0 - or is it a binary field?
You are receiving this mail because:
- You are watching all bug changes.