Bill said:
I am working with a Java-based program that performs SNMP. One of the MIB variables is a 6 byte octet message stream. The program retrieves the information and saves it on a table as a String. My part of the code must get the info as a String. I need to convert the String to a byte buffer.
The MIB / SNMP terminology appears to be "octet _string_" (emphasis
mine) not "octet message stream".
The problem I have is that not all of the data is encoded properly.
That's rather unlikely. It is entirely possible that you don't know how
it is encoded, however.
For example: The MIB variable message is (in decimal): 00 04 -127 12 -115 -114
When I use the getBytes() function, the byte buffer contains (in decimal): 00 04 63 12 63 63.
To do this you have already coerced the byte sequence into a String
according to some encoding. The byte 63 (decimal) is a '?' in Unicode;
it signals that the charset you used does not map the current byte(s) to
a character.
I have used the Character Encoding Sets US-ASCII, ISO-8859-1, UTF-8, UTF-16, UTF-16BE, UTF-16LE, and windows-1252. None have given me the result I need.
How would you recognize the result when you got it? If you know what
the correct answer is, then that would be very pertinent.
What Character Encoding Set should I use to get the right values?
That may be device-dependent. MIB specifies data types in ASN.1, and
ASN.1 apparently does not define encodings to use (that's part of the
"Abstract" in "Abstract Syntax Notation"). The information is probably
carried by some other item in the MIB.
Have you considered the possibility that the string is empty? The
initial zero byte is very suspicious in that regard. If you are getting
fixed-length strings with variable-length content then there will be
some kind of fence byte to indicate the end of the meaningful data -- at
least when the string is shorter than the maximum length. Compare to C
strings.
If that's not it then you'll probably need to pass on more information.
For what it's worth, the charsets you have already tried cover all the
likely ones.
John Bollinger
(e-mail address removed)