针对Jmeter编码问题简单普及一下字符编码知识

  1. 云栖社区>
  2. 博客>
  3. 正文

针对Jmeter编码问题简单普及一下字符编码知识

smooth00 2017-04-19 09:12:59 浏览627
展开阅读全文
版权声明:本文为博主原创文章,未经博主允许不得转载。欢迎访问我的博客 https://blog.csdn.net/smooth00/article/details/70236638

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

网友评论

登录后评论
0/500
评论
smooth00
+ 关注