之前有介绍一些简单的针对Loadrunner脚本或者调试输出内容中乱码的一些设置，但是并没能完全解决一些小伙伴的问题，因为那些设置实在能力有限，还是有很多做不到的事情。但是没关系，知道君还有更厉害的招数分享给大家，简单实在，堪称必杀技，请各路高手前来挑战。
　　首先我们来看看有哪些内容是配置无法解决的，这里通过对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，配置同样无效）
　　· 参数化文件的编码（配置无效）
　　看了以上的情况后，发现配置实际对很多情况并没有作用，那么我们开始出招了，招招导致“乱码兄”小命不保。
　　常规通用招数
　　利用Loadrunner提供的转换函数
　　（lr_convert_string_encoding）进行处理，GBK转换UTF-8参考代码：
　　lr_convert_string_encoding("我是代码"，
　　"GBK"，
　　"UTF-8"，
　　"outparam");
　　由于转换过程中会多出一个 的结束字符，也是outparam转换后变成了”我是代码”，所以还需要特别进行处理：
　　lr_save_string(lr_eval_string("{outparam}")，"newparam");
　　将outparam重新save转存到另一个newparam的参数中，当然也可以保存在原来的outparam参数中进行覆盖，这样才能保证整个转换过程没有纰漏，一些系统对比较敏感的时候还可能出现未知的问题。
　　针对参数文件的转换
　　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":"xE5x90x8DxE7xA7xB0"}
　　至于中间如何转换的过程，可以参考编码码表，或者通过UTF-8编码获取中文的Hex值，再或者，你会发现实际上这和Urlencode的结果很像。
　　Ending
　　通过那么多的招数，如果你还是搞不定乱码，那么只有2种情况了：
　　1. 人家不是编码错误导致的乱码，本身是一种加密数据，只是你误会了
　　2. 请找知道君来探讨一下你的处理方式是否正确