M03_HttpRunner中文乱码问题：悟空CRM 系统断言中文失败显示乱码分析

M03_HttpRunner中文乱码问题：悟空CRM 系统断言中文失败显示乱码分析

 

测试目的：

• 实现“悟空CRM”系统登录
• 通过页面标题文字进行断言，判断登录是否成功

 

通过浏览器登录成功后，进入系统首页，查看源代码，准备把标题文字作为断言用例执行是否成功的标志。

 

 

编写测试用例如下：

- config:
    name: 悟空CRM

- test:
    name: 登录
    request:
      url: http://192.168.1.102/72crm/index.html#/workbench/index
      method: POST
      data:
        username: 13888888888
        password: 123456
    validate:
      - eq: [status_code, 200]
      - eq: [, 悟空]

 

执行测试用例，直接失败 :(

 

看看错误提示，发现是第二个断言，即标题的断言失败了。

再仔细看输出，实际结果提取出来的是乱码，到这里就基本清楚了，字符编码问题！！

 

 

我们编写用例使用的是 UTF-8 字符编码方式，这种方式下对常见中文的编码规律是，每个汉字被编码为三个字节，“悟空”是两个汉字，编码后对应六个字节，数数乱码的字符数量，正好也是六个。

 

这六个乱码是什么鬼。别着急，我们详细分析一下。

 

这里我使用的常见的 EditPlus 文本编辑工具，新建一个空白文本文件，输入“悟空”二字，并保存为“UTF-8”编码方式（注意：这是重点！ 重点！）

 

保存成功后，直接查看文件内容的十六进制编码。

“悟空”二字的 UTF-8 编码是： E6 82 9F E7 A9 BA 共六个字节

 

 

正常情况下，用UTF-8方式进行编码，则解码也必须是UTF-8方式，即编码和解码一致，否则就会出现乱码。我们通过HttpRunner执行测试用例，返回的HTTP响应数据（即HTML文件）中，标题位置直接就输出了乱码（见截图中划绿线的红色错误提示部分）。那么HttpRunner到底用的什么方式进行解码呢？一般情况下，尤其是英文的软件，都默认习惯使用ISO8859-1的字符编码方式。

 

我们知道最早的字符编码是 ASCII 码，共表示128个字符，每个字符占用1B（1个字节）的大小，但实际只使用了其中的7位，高位补了0，如字符 'A'的编码是 '0100 0001'，最高位是一个0来占位的。

 

后续有些国家和地区对 ASCII 码进行了扩展，即把最高位的0给使用了，这样就可以表示256个字符。但是这些扩展互相间不兼容。

 

在 Windows 中运行命令：charmap ，打开字符映射工具，字符集分别选中“Windows 西欧”和“Windows中欧”，可以清楚的看到，从 0X80 编码以后（即扩展出来的字符内容），二者出现很大的不同，西欧字符集中的一些字符，在中欧字符集中就根本没有出现。也就是说，同样的编码如果使用不同的字符集解码，可能产生不同的字符显示，这就是乱码形成的很大根源，说白了就是一句话：编码和解码不一致。

 

 

于是大牛出现了- ISO（国际标准化组织），他制定了一套统一的标准，即 ISO8859 字符集系列，分别把西欧、东欧、南欧、北欧等字符集分别编号为 ISO8859-1、ISO8859-2、ISO8859-3、ISO8859-4等。其中，最常用的就是 ISO8859-1 西欧这个标准，也称Latin-1。

 

由于“悟空”二字的 UTF-8 编码是： E6 82 9F E7 A9 BA ，这六个字节如果用西欧的 ISO8859-1来一个字节一个字节的解码，每个字节就对应了一个西欧的字符。这些字符就是我们从错误提示信息中所看到的乱码了。