小李刀刀博客

　　今天测试新接口的发送和响应，为了便于和Oblog和动网的开发人员进行测试，我特地把动易接口的相关操作单独写了一个测试工具包。 　　结果别说跟动网和Oblog联合测试了，自己测试的时候就出现了意想不到的问题。 　　首先在构造请求的时候，我用了下面的方式来生成安全码： 'strKey为配置文件中的安全密钥；'strName为提交测试的用户名'objXmlDoc为XMLDOM对象syskey = Md5(strName & strKey, 32)objXmlDoc.documentElement.selectSingleNode("//syskey").text = syskeyobjXmlDoc.documentElement.selectSingleNode("//username").text = strName 　　然后在服务器端用下面的代码处理： 'strKey为配置文件中的安全密钥；'strName为提交测试的用户名'objXmlDoc为XMLDOM对象objXmlDoc.Load(Request)syskey = objXmlDoc.documentElement.selectSingleNode("//syskey").textstrName = objXmlDoc.documentElement.selectSingleNode("//username").textIf Ucase(syskey) = Ucase(Md5(strName & strKey, 32) Then '安全码检验成功 Else '安全码检验失败 End If 　　这里服务器端和发送请求的文件都调用的是同一个配置文件，因此strKey的值是完全一样的。可是不管怎么测试，加密出来的安全码始终都不相等。 　　我开始怀疑是编码的问题导致，于是在发送请求端显示声名我发送的信息是utf-8编码的，在服务器端也作了相应处理。可是结果依旧。 　　按照原来处理Trackback的方式，我用Unicode编码函数在发送前对中文用户名先进行编码，结果还是不行。 　　后来跟NT讨论这个问题，我把文件打包发给他看，还在发送的时候，他问了一句：你用MD5处理用户名？ 　　听到这句话我突然想到，对啊，发送前的syskey是用还没处理的UserName直接生成的，接受到的UserName经过DOM处理，已经是Unicode状态了。于是我改了一下，用下面的方式来生成syskey： 'strKey为配置文件中的安全密钥；'strName为提交测试的用户名'objXmlDoc为XMLDOM对象objXmlDoc.documentElement.selectSingleNode("//username").text = strNamestrName = objXmlDoc.documentElement.selectSingleNode("//username").textsyskey = Md5(strName & strKey, 32)objXmlDoc.documentElement.selectSingleNode("//syskey").text = syskey 　　先把用户名用DOM设置为XML元素的文本数据，然后再解析出来，这时的strName就和服务器端解析出来的状态一样了。然后再加密。 　　改完再试，果然成功了。 　　XMLDOM在创建和解析XML数据的时候，自动对数据进行Unicode编码，并且根据Codepage的设置自动进行编码转换，因此并不需要对字符的编码做特殊处理。但是如果直接用字符串构造XML，就失去了这个优势，反而导致乱码。