LOADRUNNER转码问题(UTF-8转为GBK)

这是一个HTTP接口测试中经常会碰到的问题,目前的服务器采用的都是UTF-8编码方式,而我们的客户机Windows系统一般默认采用的编码方式是GBK,这正是我们采用录制方式的时候会发现许多中文乱码的原因。

Loadrunner录制的时候可以通过在Virtual User GenTools->Recoding Options -> Advanced -> Support charset -> UTF-8的设置规避(其实也只是部分规避),下面我们讨论在手写测试脚本时如何解决UTF-8转码的问题。

实践一:在脚本中直接采用中文明文进行请求

web_custom_request("web_custom_request",
 "URL=http://172.16.4.191/list?id=环球影院",
 "Method=GET",
 "TargetFrame=",
 "Resource=0",
 "Referer=",
 "Body=",
 LAST);
结果:服务端返回404错误,找不到相应的资源id,明显服务端不能正确响应非UTF8编码方式的请求。

实践二:

为解决这个问题,最关键的是要把本地GBK编码的汉字转换成UTF-8编码格式的信息,为此我们引进loadrunner自带的编码函数lr_convert_string_encoding

lr_convert_string_encoding


href="javascript.:VarHTMLHelp.fShowPopup('Paramererization_Background.html#wp17152');" Return Values

href="javascript.:VarHTMLHelp.fShowPopup('Paramererization_Background.html#wp17132');" Parameterization

Converts a string to a different encoding.

C Language

intlr_convert_string_encoding( const char *sourceString, const char *fromEncoding, const char *toEncoding, const char *paramName);

Example See Also


sourceString

The string to convert

fromEncoding

The encoding of the sourceString

toEncoding

The encoding to convert of the string saved in parameterparamName

paramName

The name of the parameter in which the destination string will be saved

lr_convert_string_encodingconverts a string encoding between the following encodings: System locale, Unicode, and UTF-8.The function saves the result string, including its terminating NULL, in the parameterparamName.

lr_convert_string_encodingis added manually to a script. when needed. It is not recorded.

Possible values for 'fromEncoding' and 'toEncoding' :


Constant

Value

LR_ENC_SYSTEM_LOCALE

NULL

LR_ENC_UTF8

"utf-8"

LR_ENC_UNICODE

"ucs-2"

根据函数说明,我们编写测试脚本如下

 lr_convert_string_encoding( "环球影院",
 LR_ENC_SYSTEM_LOCALE,
 LR_ENC_UTF8,
 "str" );
 web_custom_request("web_custom_request",
 "URL=http://172.16.4.191/list?id={str}",
 "Method=GET",
 "TargetFrame=",
 "Resource=0",
 "Referer=",
 "EncType=text/xml;charset=UTF-8",
 "Body=",
 LAST);

使用lr_convert_string_encoding函数,将中文转换成UTF-8编码以后,作为参数传递给请求,并发送。

测试结果:仍然返回404错误,查看loadrunner日志信息环球影院已经正确转换成UTF8编码方式,那为什么还是请求失败呢?

再次查看日志如下

Action.c(7): t=825ms: 223-byte request headers for "http://172.16.4.191/list?id=悆褰遍櫌" (RelFrameId=1)
Action.c(7): GET /list?id=悆褰遍櫌\x00 HTTP/1.1\r\n
Action.c(7): Content-Type: text/xml;charset=UTF-8\r\n
Action.c(7): User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows)\r\n
Action.c(7): Accept-Encoding: gzip, deflate\r\n
Action.c(7): Accept: */*\r\n
Action.c(7): Connection: Keep-Alive\r\n
Action.c(7): Host: 172.16.4.191\r\n
Action.c(7): \r\n

发现在请求地址/list?id=悆褰遍櫌后面还带了一个\x00,这正是lr_convert_string_encoding函数说明中标红的说明:The function saves the result string, including its terminating NULL, in the parameterparamName.

也就是说,我转换成UTF-8之后,如果直接作为变量传到代码之中的话,在最后的字符串之中,会多出来一个NULL,在C语言中NULL是一个字符串的结束,而正是这个null字节的存在导致了服务端识别id出错。

实践三:

 char tmp[50];
 lr_convert_string_encoding( "环球影院",
 LR_ENC_SYSTEM_LOCALE,
 LR_ENC_UTF8,
 "str" ); 
 strcpy(tmp,lr_eval_string("{str}"));

lr_log_message("str is %s",tmp);
 lr_save_string(tmp,"sorvalue");
 web_custom_request("web_custom_request",
 "URL=http://172.16.4.191/list?id={sorvalue}",
 "Method=GET",
 "TargetFrame=",
 "Resource=0",
 "Referer=",
 "Body=",
 LAST);

通过lr_eval_string函数取参数值时会自动去掉\x00,测试结果正常,正确返回HTTP响应内容。



### 解析 Invalid UTF-8 Byte 错误 当遇到 `Invalid UTF-8 byte` 报错时,通常意味着程序尝试处理的数据流中包含了不合法的UTF-8编码字符。对于特定错误 `'FA.'` 的情况,在不同环境下可能有不同的原因和解决方案。 #### 数据源验证 确保输入数据确实是以UTF-8格式编写的非常重要。如果文件是在其他编码下创建的,则读取该文件的应用程序可能会因为期望的是UTF-8而抛出异常[^1]。 ```python import chardet def detect_encoding(file_path): raw_data = open(file_path, "rb").read() result = chardet.detect(raw_data) encoding = result['encoding'] return encoding file_path = 'path_to_your_file' print(f"The detected encoding of the file is {detect_encoding(file_path)}") ``` #### 修改IDEA配置 在开发环境中(如IntelliJ IDEA),可以通过调整项目设置来指定正确的编码方式: - 打开Settings/Preferences对话框 (Ctrl+Alt+S 或 Cmd+, on macOS). - 导航到Editor -> File Encodings. - 设置Global Encoding 和 Project Encoding 均为UTF-8. 此更改有助于防止因编辑器内部使用的默认编码与实际文件编码不符而导致的问题[^2]. #### Windows系统环境变量设定 针对Windows操作系统,默认情况下其控制台和其他组件采用ANSI作为主要编码标准而非UTF-8。为了使应用程序能够正确识别并解释来自外部资源(比如网络请求响应)中的Unicode字符,可以考虑修改系统的区域性和语言选项: - 控制面板->地区->管理标签页下的“更改系统区域设置”,勾选Beta版: 使用 Unicode UTF-8 提供全球语言支持。 这种做法能有效减少跨平台传输过程中产生的兼容性问题. #### Web服务器端点调试(LoadRunner场景) 如果是通过LoadRunner执行性能测试期间发生的此类错误,除了检查上述提到的内容外,还需要特别关注HTTP协议级别的参数配置。具体来说就是确认录制脚本时所选用的支持字符集是否恰当以及运行时间内的相应选项是否有做适当调整[^3]: - 录制选项 -> HTTP属性 -> 高级 -> 支持字符集; - 运行选项 -> 浏览器仿真模式 -> 字符串表单提交; 以上措施可以帮助缓解由客户端和服务端之间通信引起的潜在编码冲突。 #### XML声明修正(Apache Tomcat部署案例) 最后一种可能性涉及到XML文档本身的定义不当造成的解析失败。特别是那些用于描述Web应用结构的配置文件(.xml),它们应当明确定义根节点及其子元素遵循的标准命名空间规则。例如,对于Java EE web.xml 文件而言,应该包含如下声明以指明预期接收的内容类型[^4]: ```xml <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> </web-app> ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值