对于 Jmerter 中需要使用中文字符时, 我们一般用 UTF-8 编码, 而且对于 CSV Data Set Config 的中文参数化, 我们要求用编辑器 (Sublime,UltraEdit 等) 保存为无 BOM 的 UTF-8 编码格式的, 这是为什么呢? 从下面的字符编码介绍, 就知道原因了:
1, 美国人发明存储英文的是 ASCII 码, 扩展到全世界使用就成了 ANSI 码, 中国人发明了 GB2312 码(ASCII 码的中文扩充), 继续扩展后成了 GBK 码(加了新汉字和繁体字), 再扩展成了 GB18030(加了少数民族的字).
2, 最后为了统一全球文字, 发明了 unicode(万国码), 但是不方便传输和推广(因为在计算机上区别不了 unicode 和 ascii), 接着就发明了 UTF 码(unicode 码的互联网化实现方式), 其中 UTF-8 表示每次传输 8 位数据, UTF-16 表示每次 16 位转输(比如汉字人名中的生僻字, 用 UTF-8 不够转输, 就需要用 UTF-16).
所以 ASCII,GB2312,GBK 和 GB18030 是向下兼容的, 区分中文编码的方法是高字节的最高位不为 0.unicode 则只兼容 ASCII.
3, 对于 UTF-8 我们就需要关注 BOM 头了, 许多文本编辑器中能看到这样的格式区分
通常 BOM 是用来标示 Unicode 纯文本字节流的, 用来提供一种方便的方法让文本处理程序识别读入的. txt 文件是哪个 Unicode 编码(UTF-8,UTF-16BE,UTF-16LE),Windows 程序相对对 BOM 处理比较好, 打开文本文件时它会自动识别并剔除 BOM.(吐槽: 微软对兼容性的要求确实是到了非常偏执的地步, 任何一点破坏兼容性的做法都不允许, 以至于很多时候是自己绑住自己的双手), 所以干脆一步到位进入 UTF-8.
BOM 不受欢迎主要是在 UNIX 环境下(或是 Java 环境下的程序), 因为很多 UNIX 程序不鸟 BOM. 主要问题出在 UNIX 那个所有脚本语言通行的首行 #! 标示, 这东西依赖于 shell 解析, 而很多 shell 出于兼容的考虑不检测 BOM, 所以加进 BOM 时 shell 会把它解释为某个普通字符输入导致破坏 #! 标示, 这就麻烦了. 其实很多现代脚本语言, 比如 Python, 其解释器本身都是能处理 BOM 的, 但是 shell 卡在这里, 没办法, 只能躺着也中枪. 说起来这也不能怪 shell, 因为 BOM 本身违反了一个 UNIX 设计的常见原则, 就是文档中存在的数据必须可见. BOM 不能作为可见字符被文本编辑器编辑, 就这一条很多 UNIX 开发者就不满意.
最后引用网上的一些说明: 为什么 bom 头会产生乱码?
有 bom 头的存储或者字节流, 它一定是 unicode 字符集编码. 到底属于那一种(utf-8 还是 utf-16 或是 utf-32), 通过头可以判断出来.
由于已经说过 utf-16,utf-32 不指定 bom 头, 解析程序默认就认为是 ansi 编码, 出现乱码. 而 utf-8 指定或者不指定程序都可判断知道对于的字符集编码.
问题就出在这里, 可能有的应用程序(ie6 浏览器), 它就认为如果 utf-8 编码, 就不需要指定 bom 头, 它可以自己判断, 相反指定了 bom 头, 它还会出现问题
(因为它把头当 utf-8 解析出现乱码了). 众多技术博客里谈这个比较多, 目前 ie6 会出现问题. 其它 ie7+,Firefox,Chrome 不会出现, 会忽略掉 bom 头.
统一解决办法是: 存为 utf-8 编码是, 不需要加入 bom 头, 其它 utf-16,utf-32 加入.
来源: https://yq.aliyun.com/articles/675001