究极秒杀Loadrunner乱码
Loadrunner乱码一击必杀之前有介绍一些简单的针对Loadrunner脚本或者调试输出内容中乱码的一些设置，但是并没能完全解决一些小伙伴的问题，因为那些设置实在能力有限，还是有很多做不到的事情。但是没关系，知道君还有更厉害的招数分享给大家，简单实在，堪称必杀技，请各路高手前来挑战。欢迎大家有问题加我微信wanderx99一起探讨更多的性能测试技术.首先我们来看看有哪些内容是配置无法解决的，这里通过对3个Loadrunner使用率最高的HTTP请求函数来解释（web_url，web_submit_data，web_custom_request），其他一些关联、检查等函数大部分都是直接可以通过配置来解决的。[*]web_url
关键参数： URL（配置无效）当然谁在URL里写中文本身就是一个问题，不同浏览器处理中文的处理和编码都不同，但总有人喜欢那么干……任何关于编码的配置都对URL中的中文无效，一切都会以系统默认编码处理，也就是ANSI（GBK）
[*]web_submit_data
关键参数1：Action（配置无效）该参数实际就是URL，只是参数名称不同于常规关键参数2：ITEMDATA中的各项value（配置有效）
[*]web_custom_request
关键参数1：URL（配置无效）与上面URL参数情况相同，配置对中文无效，都只会作为GBK处理关键参数2：Body（含其他模式的Body，配置同样无效）
[*]参数化文件的编码（配置无效）
http://img.mp.itc.cn/upload/20161206/82151afdadd245f09828e94ddb5ad4ad_th.jpg看了以上的情况后，发现配置实际对很多情况并没有作用，那么我们就开始出招了，招招导致“乱码兄”小命不保。常规通用招数利用Loadrunner提供的转换函数（lr_convert_string_encoding）进行处理，GBK转换UTF-8参考代码：lr_convert_string_encoding("我是代码","GBK","UTF-8","outparam");由于转换过程中会多出一个 \0 的结束字符，也就是outparam转换后变成了”我是代码\0”，所以还需要特别进行处理：lr_save_string(lr_eval_string("{outparam}"),"newparam");将outparam重新save转存到另一个newparam的参数中，当然也可以保存在原来的outparam参数中进行覆盖，这样才能保证整个转换过程没有纰漏，一些系统对\0比较敏感的时候还可能出现未知的问题。针对参数文件的转换LoadRunner对于参数化文件，都是统一使用系统默认编码（GBK）到操作，如果内容中含有中文，就需要每次获取时进行代码转换，这对于一些参数化策略多少会受到一些影响，但如果说使用这招，就可以避免这类的问题，那到底是什么招数呢？假设你的数据文件名称为data.dat，你可以在LoadRunner没有打开参数文件窗口的情况下，使用文本编辑器，打开data.dat，直接将数据文件另存为UTF-8的编码对原来的文件进行覆盖，再回去看下参数文件窗口，虽然显示上都成乱码，但实际使用时的效果惊人，可直接发送UTF-8编码的中文数据，简单方便，唯一的缺点是只能在脚本外部进行编辑。直接发送16进制编码数据，无视任何编码假设需要在web_custom_request的body中发送一串json，内容为{"test":123,"name":"名称"} ，json的格式中，中文只能是UTF-8，而如果不是UTF-8编码，情况好点只是乱码，情况差点，可能连带json解析器都会一起报错。那么上面的内容我们可以发送什么来代替呢？揭晓答案：{"test":123,"name":"\xE5\x90\x8D\xE7\xA7\xB0"}至于中间如何转换的过程，可以参考编码码表，或者通过UTF-8编码获取中文的Hex值，再或者，你会发现实际上这和Urlencode的结果很像。通过那么多的招数，如果你还是搞不定乱码，那么只有2种情况了：1. 人家不是编码错误导致的乱码，本身就是一种加密数据，只是你误会了2. 请找知道君来探讨一下你的处理方式是否正确
谢谢总结和分享！
其他人可以作为参考资料了
页:
[1]
