LoadRunner脚本传中文参数出现乱码报错怎么解决？

在使用LoadRunner进行性能测试时,处理包含中文字符的请求是一个常见的挑战，许多测试工程师会遇到脚本回放时因中文乱码或编码错误导致业务失败的情况，这不仅影响测试的准确性，也给问题定位带来了困扰，本文将深入剖析LoadRunner传递中文参数报错的根本原因，并提供一套系统性的解决方案。

问题根源：字符编码的“误会”

要解决问题,必先理解其本质，LoadRunner传中文报错的核心原因在于字符编码不一致，计算机在存储和传输字符时，需要遵循特定的编码规则，如ASCII、GBK、UTF-8等。

LoadRunner默认编码：LoadRunner脚本默认使用类似ISO-8859-1的编码，这是一种西欧字符集，无法直接表示中文字符。
应用服务器编码：现代Web应用普遍采用UTF-8或GBK编码来支持国际化，尤其是UTF-8，已成为业界标准。
冲突点：当LoadRunner脚本将一个包含中文的参数（如用户名、地址）发送给服务器时，如果脚本内部仍使用默认编码，而服务器期望接收UTF-8编码的数据，服务器就会将收到的字节流按照UTF-8的规则进行解码，由于源头编码不匹配，解码出的自然是乱码，从而导致后续的业务逻辑处理失败，例如用户验证不通过、数据插入错误等。

核心解决方案

解决编码问题的关键在于确保数据从客户端（LoadRunner脚本）发出到服务器接收的整个链路中，编码格式保持统一，通常统一为UTF-8，以下是三种主流且有效的解决方法。

脚本内字符编码转换

这是最常用、最根本的解决方法，通过在脚本中对中文参数进行显式编码转换，确保发送出去的数据是服务器期望的格式，LoadRunner提供了强大的函数lr_convert_string_encoding来实现这一目标。

函数语法：
lr_convert_string_encoding(const char *sourceString, const char *fromEncoding, const char *toEncoding, const char *paramName);

使用示例：
假设我们需要提交一个名为“userName”的中文参数“张三”。

Action()
{
    // 1. 将原始中文“张三”存入一个临时参数
    lr_save_string("张三", "tempName"); 
    // 2. 核心步骤：将临时参数从本地系统编码（通常是本地ANSI，如GBK）转换为UTF-8编码
    lr_convert_string_encoding(lr_eval_string("{tempName}"), 
                               LR_ENC_SYSTEM_LOCALE, 
                               LR_ENC_UTF8, 
                               "utf8Name");
    // 3. 在请求中使用转换后的UTF-8编码参数
    // 注意：lr_eval_string会返回一个带双引号的字符串，如""...""
    // 在某些API中需要去除，但在web_submit_data中通常可以直接使用
    web_submit_data("login",
        "Action=https://example.com/login",
        "Method=POST",
        "RecContentType=text/html",
        "Referer=https://example.com/index",
        "Mode=HTML",
        ITEMDATA,
        "Name=username", "Value={utf8Name}", ENDITEM, // 使用转换后的参数
        "Name=password", "Value=123456", ENDITEM,
        LAST);
    return 0;
}

修改运行时设置

对于整个脚本都涉及中文的场景,可以通过修改运行时设置来全局指定字符编码。

在VuGen中,进入 Vuser -> 运行时设置。
选择 浏览器 -> 浏览器仿真。
点击 使用浏览器 右侧的“选项”按钮，或者直接在 Internet Protocol -> 首选项 -> 高级 中找到 编码 选项。
将其设置为 UTF-8。

这种方法相对简单,但它会影响所有请求，有时可能不够灵活，特别是当脚本需要同时处理不同编码的接口时。

自定义HTTP请求头

另一种有效的方式是显式地告诉服务器,我们发送的请求体是UTF-8编码的，通过添加或修改Content-Type请求头来实现。

Action()
{
    // 在提交数据前，添加或修改Content-Type请求头
    web_add_header("Content-Type", "application/x-www-form-urlencoded; charset=UTF-8");
    // 后续的web_submit_data或web_custom_request中，可以直接使用中文参数
    // 但仍建议与方法一结合，确保万无一失
    lr_save_string("李四", "userName");
    web_submit_data("submit_data",
        "Action=https://example.com/api/submit",
        "Method=POST",
        ITEMDATA,
        "Name=data", "Value={userName}", ENDITEM,
        LAST);
    return 0;
}

这种方法尤其适用于API测试,通过明确指定charset=UTF-8，引导服务器正确解析请求体。

解决方案对比小编总结

为了方便选择,下表对三种方法进行了对比：

解决方案	适用场景	优点	缺点
脚本内转换	单个或多个参数需要精确控制编码	精确、灵活，不影响其他请求	需要对每个中文参数进行处理，代码量稍多
运行时设置	整个脚本统一使用一种编码	一次性设置，全局生效	缺乏灵活性，可能不适用于混合编码场景
自定义请求头	API测试，或需要明确告知服务器编码	标准化，符合HTTP协议规范	仅对当前请求有效，需确保请求体内容本身编码正确

最佳实践：推荐将方法一（脚本内转换）与方法三（自定义请求头）结合使用，前者确保数据本身是正确的UTF-8字节流，后者则通过标准HTTP头向服务器“声明”编码格式，双重保险，确保万无一失。

常见问题解答 (FAQs)

Q1: 我已经按照方法一转换了字符串，为什么服务器端收到的还是乱码？
A1: 这种情况通常由以下几个原因造成：

源编码判断错误：lr_convert_string_encoding函数的fromEncoding参数设置错误，如果脚本文件本身是UTF-8格式，但fromEncoding设置为了LR_ENC_SYSTEM_LOCALE（通常是GBK），就会导致二次编码错误，请确保脚本文件的保存格式与fromEncoding参数一致。
服务器端配置问题：问题可能不在客户端，而是服务器本身没有正确配置以解析UTF-8请求，Tomcat的URIEncoding="UTF-8"配置缺失。
参数被再次编码：在某些API中，如果将lr_eval_string("{utf8Name}")的结果直接放入另一个需要URL编码的函数中，可能会导致被再次编码，请检查函数调用链。

Q2: GBK和UTF-8有什么区别？在测试中我应该优先选择哪个？
A2: GBK是中国国家标准编码，专门用于解决汉字的编码，它采用双字节表示一个汉字，兼容GB2312，UTF-8（Unicode Transformation Format-8）则是一种全球通用的变长编码，它能表示世界上几乎所有的字符，对于英文字符使用1字节，汉字通常使用3字节。
在性能测试中，强烈推荐优先使用UTF-8，因为现代应用系统为了支持国际化和多语言，绝大多数都采用UTF-8作为统一标准，使用UTF-8能确保测试脚本具有更好的通用性和可移植性，避免因应用系统升级或支持更多语言而带来的编码问题，只有当被测系统非常老旧且明确只支持GBK时，才考虑使用GBK。

LoadRunner脚本传中文参数出现乱码报错怎么解决？

问题根源：字符编码的“误会”