winsock的buffer简单解析

        "Host: 172.28.17.134:8888\r\n"
        "Connection: Keep-Alive\r\n"
        "\r\n"
在buffer0里已经没有了0－56一些看不懂的数据，直接是get请求。这说明lr的winsock捕获了tcp传输中的数据部分，而略去了tcp的头。我们明白一点了。
但是我们看到server端抓到的数据其实都是十六进制的数据，lr直接显示的是文本，那lr是怎样将其转换为文本的呢（我用的是snoop命令在server端抓包，它也有自动将其转换文本的功能，就是数据的右侧文本）？
我们知道在编码过程中，一个英文字母用一个字节来表示，一个中文汉字则用两个字节来表示。（有时lr不能正确地显示中文，就是因为它不支持中文，无法知道怎样去合并两个字节成为中文汉字）
那么我们试着去解析下面的一行
64: 6c38 3030 302f 6164 6d69 6e2e 6a73 7020    l8000/admin.jsp
snoop命令给我们已经解析好了，“l8000/admin.jsp”， 按一个英文字母对应一个字节的规则的话，英文字母l应该对应6c，6c是十六进制，转化十进制是108，而l的ascii码正是108。这个字母对上了。
往下就简单了，38对应8，30对应0，依次a d m i n . j s p都能对应下去。解析完毕！

如果都能这样解析，那么lr中的send buffer和receive buffer都应该能够解析出来，不会出现乱码。我们也能很轻松地去参数化buffer了。

但是很不幸，看起来，lr犯了一个错误，在receive buffer和send buffer中。lr不管三七二十一，都按照此规则解析。解析不出来就显示大段的乱码。让使用者无所适从。

例如我在下面请求中，试图get一个图片，server端返回一个图片，图片是二进制的，用十六进制在网络传输。但是lr还是试图去解析这个图片，结果得到了一大批的乱码，让我们都判断不出来这段buffer的含义了。

还有一种乱码的情况，前不久和QA_BAY聊了用lr录制QQ的例子，结果录下来，发现满篇都是乱码，晕啊。如果都能象http协议这样透传的话，最起码能够录到登陆口令的英文字母啊。所以我只好怀疑在上层加密了数据，导致socket层全是乱码，解析不出来。

晕，先说到这里。希望大家能看懂。
在windows下面可以用ethreal，在unix下面可以用snoop。我的例子是在solaris下面用snoop命令抓包的。
第一，我对楼主的这点提法有点异议：这是TCP的三次握手，只是具有TCP的头和尾，其中并没有数据，可能lr将其忽略了。我个人认为loadrunner只会对应用层的一些协议进行处理，而对于传输层或网络层的东西都会将其过滤掉，或者说应用层以下的东西并不是所loadrunner关注的
第二，在网络上所有的内容都是按照bit流的方式来传输，而所谓的二进制或者说16进制这只是print出来的方式不同而已；在socket协议中data.ws中loadrunner会将sendbuf和recvbuf中的所有数据都按照ascii码的方式来解析，而有些中文或者其他编码没有办法解析所以就以乱码的方式表现出来了（好像loadrunner并不支持unicode编码）。我觉得如果希望参数化buf中的内容首先你要熟悉buf中每个字节的意义，这也就要求你必须熟悉应用层的协议了。
第三，对于qq登录我想应该是经过加密的了，我想腾讯也不会让用户的userid和password应该不会以明文的方式在网络上传输，所以录制qq登录过程中产生的乱码是可以解释的

第一，我对楼主的这点提法有点异议：这是TCP的三次握手，只是具有TCP的头和尾，其中并没有数据，可能lr将其忽略了。我个人认为loadrunner只会对应用层的一些协议进行处理，而对于传输层或网络层的东西都会将其过滤掉，或者说应用层以下的东西并不是所loadrunner关注的
第二，在网络上所有的内容都是按照bit流的方式来传输，而所谓的二进制或者说16进制这只是print出来的方式不同而已；在socket协议中data.ws中loadrunner会将sendbuf和recvbuf中的所有数据都按照ascii码的方式来解析，而有些中文或者其他编码没有办法解析所以就以乱码的方式表现出来了（好像loadrunner并不支持unicode编码）。我觉得如果希望参数化buf中的内容首先你要熟悉buf中每个字节的意义，这也就要求你必须熟悉应用层的协议了。
第三，对于qq登录我想应该是经过加密的了，我想腾讯也不会让用户的userid和password应该不会以明文的方式在网络上传输，所以录制qq登录过程中产生的乱码是可以解释的
lr7.8的buffer的转换上是不支持的，不知8.0是否能够做到。
lr的大多函数都与win32的api有关联，就算lr在api上没有这个函数，我们也可以include进来，自己调用。

可以使用lrs_save_param_ex  (....ascii ) 保存，再用 lr_log_message之类函数打印