对于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加入。
