SNMP4J 处理中文信息时的有关问题
SNMP4J 处理中文信息时的问题首先说,多数时候你并不会遇到SNMP中文问题多数网络设备和网管软件都是西文的.
SNMP4J 处理中文信息时的问题
- 首先说,多数时候你并不会遇到SNMP中文问题
多数网络设备和网管软件都是西文的.这个"多数"的意思是95%以上.
目前有可能遇到的中文SNMP问题的场景:
1. 一些国产网络设备(别提华为,华为路由器的多数网管信息也是西文的)
2. Windows平台的SNMP服务
3. 一些国产网管软件
- SNMP4J处理中文时的问题:当遇到中文或者编码值大于 0x80 的字符时，就会直接以十六机制数输出
现象：???Vector<VariableBinding> responseVB = respEvent.getResponse().getVariableBindings();
?????????????????????
???if(1==responseVB.size()){
?????tempV = responseVB.elementAt(0);?????????????????????????????????????????????
?????System.out.println(tempV.getOid().toString()+":"+tempV.getVariable());
?????System.out.println(tempV.getVariable().getSyntaxString());
????????????????????????????}执行代码：
1.3.6.1.2.1.2.2.1.2.1:4d:53:20:54:43:50:20:4c:6f:6f:70:62:61:63:6b:20:69:6e:74:65:72:66:61:63:65:00
OCTET STRING
1.3.6.1.2.1.2.2.1.2.2:56:4d:77:61:72:65:20:56:69:72:74:75:61:6c:20:45:74:68:65:72:6e:65:74:20:41:64:61:70:74:65:72:20:66:6f:72:20:56:4d:6e:65:74:38:00
OCTET STRING
1.3.6.1.2.1.2.2.1.2.3:56:4d:77:61:72:65:20:56:69:72:74:75:61:6c:20:45:74:68:65:72:6e:65:74:20:41:64:61:70:74:65:72:20:66:6f:72:20:56:4d:6e:65:74:31:00
OCTET STRING
1.3.6.1.2.1.2.2.1.2.4:52:65:61:6c:74:65:6b:20:52:54:4c:38:31:33:39:20:46:61:6d:69:6c:79:20:50:43:49:20:46:61:73:74:20:45:74:68:65:72:6e:65:74:20:4e:49:43:20:2d:20:ca:fd:be:dd:b0:fc:bc:c6:bb:ae:b3:cc:d0:f2:ce:a2:d0:cd:b6:cb:bf:da:00
OCTET STRING
1.3.6.1.2.1.2.2.1.2.65542:41:53:55:53:20:38:30:32:2e:31:31:62:2f:67:20:57:69:72:65:6c:65:73:73:20:4c:41:4e:20:43:61:72:64:20:2d:20:ca:fd:be:dd:b0:fc:bc:c6:bb:ae:b3:cc:d0:f2:ce:a2:d0:cd:b6:cb:bf:da:00
OCTET STRING?????????????????????????
???????????????????????- 原因：问题出在SNMP4J的基础字符串类OctetString上。
(SNMP4J体系下的字符串是以OctetString的形式而不是String形式存在和处理的。各种和字符串有关的资源如community,version,user,password等都是基于OctetString)
问题出在OctetString类的toString方法：public class OctetString?extends AbstractVariable
????implements AssignableFromByteArray, AssignableFromString {
??
????public String toString() {
????????if (isPrintable()) {
??????????return new String(value);
????????}
????????return toHexString();
????????// 没通过isPrintable()判断的，如ASCII控制字符，汉字等，都以16进制显示
??????}??public boolean isPrintable() {
????for (int i=0; i<value.length; i++) {
??????char c = (char)value[i];
??????if ((Character.isISOControl(c)?||
??????????((value[i] & 0xFF) >= 0x80)) && (!Character.isWhitespace(c))) {
??????????//?判断其是否大于0x80 (即通常所说的大于128的ASCII码，汉字编码都在这个区间内）
????????return false;
??????}
????}
????return true;
??}
- 解决法1：网上有人给的建议是直接把OctetString类里toString方法里的if (isPrintable())部分取消掉，就是用基本的String转换??public String toString() {
??????return new String(value);
??}测试:1.3.6.1.2.1.2.2.1.2.1:MS TCP Loopback interface
OCTET STRING
1.3.6.1.2.1.2.2.1.2.2:VMware Virtual Ethernet Adapter for VMnet8
OCTET STRING
1.3.6.1.2.1.2.2.1.2.3:VMware Virtual Ethernet Adapter for VMnet1
OCTET STRING
1.3.6.1.2.1.2.2.1.2.4:Realtek RTL8139 Family PCI Fast Ethernet NIC - 数据包计划程序微型端口
OCTET STRING
1.3.6.1.2.1.2.2.1.2.65542:ASUS 802.11b/g Wireless?LAN Card - 数据包计划程序微型端口
OCTET STRING
这种方法更不可取，因为isPrintable()方法是用于判断可显示字符的，其中不止判断大于0x80，还有包括控制字符的判断（0-31,127-159）
（codePoint >= 0x0000 && codePoint <= 0x001F) || (codePoint >= 0x007F && codePoint <= 0x009F);
- 解决法2：克服法1的缺陷，toString()不变，只修改isPrintable()public String toString() {
????????if (isPrintable()) {
??????????return new String(value,"UTF-8");
????????}
????????return toHexString();
??????}??public boolean isPrintable() {
????for (int i=0; i<value.length; i++) {
??????char c = (char)value[i];
??????int codePoint =??(int)value[i];
??????if (((codePoint > 0x0000 && codePoint <= 0x001F)?||
???????????(codePoint >= 0x007F && codePoint <= 0x009F)) && (!Character.isWhitespace(c))) {
????????return false;
??????}
????}
????return true;
??}???
注意：上面codePoint变量的操作，基本就是Character.isISOControl(c)的操作
???但windows 平台的snmp信息会以‘\0'结尾，这样windows平台任何snmp信息都通不过Character.isISOControl(c)的判断
??所以必须把Character.isISOControl(c)中的codePoint >=?0x0000改成codePoint > 0x0000
- 解决法3：在国外的论坛上，有的比较死板的人要求按正规的“继承+覆写方法”的方式做修改，这样能保证源码的不被改变
其实仔细想想，完全不修改源码是很难的，所谓“牵一发而动全身”。
既然是开源的代码,该修改就修改.
?
?
