在Node中,应用需要处理网络协议、操作数据库、处理图片、接收上传文件等,在网络流和文件的操作中,还要处理大量二进制数据,JavaScript自有的字符串远远不能满足这些需求,于是Buffer对象应运而生。
创新互联2013年至今,先为临泽等服务建站,临泽等地企业,进行企业商务咨询服务。为临泽企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
Buffer在文件I/O和网络I/O中运用广泛,尤其在网络传输中,它的性能举足轻重。在应用中,我们通常会操作字符串,但一旦在网络中传输,都需要转换为Buffer,以进行二进制数据传输。在Web应用中,字符串转换到Buffer是时时刻刻发生的,提高字符串到Buffer的转换效率,可以很大程度地提高网络吞吐率。
嗯嗯,好的。
Buffer是一个像Array的对象,但它主要用于操作字节。所以我将会从模块结构和对象结构的层面上来认识它。
Buffer是一个典型的JavaScript与C++结合的模块,它将性能相关部分用C++实现,将非性能相关的部分用JavaScript实现,如图所示。
在【深入探究Node】(4)“内存控制” 有十五问我们提到Buffer所占用的内存不是通过V8分配的,属于堆外内存。由于V8垃圾回收性能的影响,将常用的操作对象用更高效和专有的内存分配回收策略来管理是个不错的思路。由于Buffer太过常见,Node在进程启动时就已经加载了它,并将其放在全局对象(global)上。所以在使用Buffer时,无须通过require()即可直接使用。
Buffer对象类似于数组,它的元素为16进制的两位数,即0到255的数值。示例代码如下所示:
由上面的示例可见,不同编码的字符串占用的元素个数各不相同,上面代码中的中文字在UTF-8编码下占用3个元素,字母和半角标点符号占用1个元素。
Buffer受Array类型的影响很大,可以访问length属性得到长度,也可以通过下标访问元素,在构造对象时也十分相似,代码如下:
上述代码分配了一个长100字节的Buffer对象。可以通过下标访问刚初始化的Buffer的元素,代码如下:
这里会得到一个比较奇怪的结果,它的元素值是一个0到255的随机值。同样,我们也可以通过下标对它进行赋值:
给元素的赋值如果小于0,就将该值逐次加256,直到得到一个0到255之间的整数。如果得到的数值大于255,就逐次减256,直到得到0~255区间内的数值。如果是小数,舍弃小数部分,只保留整数部分。
可以的。
字符串转Buffer对象主要是通过构造函数完成的:
通过构造函数转换的Buffer对象,存储的只能是一种编码类型。encoding参数不传递时,默认按UTF-8编码进行转码和存储。
实现Buffer向字符串的转换也十分简单,Buffer对象的toString()可以将Buffer对象转换为字符串,代码如下:
比较精巧的是,可以设置encoding(默认为UTF-8)、start、end这3个参数实现整体或局部的转换。如果Buffer对象由多种编码写入,就需要在局部指定不同的编码,才能转换回正常的编码。
Buffer在使用场景中,通常是以一段一段的方式传输。以下是常见的从输入流中读取内容的示例代码:图片上面这段代码常见于国外,用于流读取的示范,data事件中获取的chunk对象即是Buffer对象。对于初学者而言,容易将Buffer当做字符串来理解,所以在接受上面的示例时不会觉得有任何异常。
一旦输入流中有宽字节编码时,问题就会暴露出来。如果你在通过Node开发的网站上看到[插图]乱码符号,那么该问题的起源多半来自于这里。
用多个字节来代表的字符称之为宽字符,而Unicode只是宽字符编码的一种实现,宽字符并不一定是Unicode。
这里潜藏的问题在于如下这句代码:图片这句代码里隐藏了toString()操作,它等价于如下的代码:
值得注意的是,外国人的语境通常是指英文环境,在他们的场景下,这个toString()不会造成任何问题。但对于宽字节的中文,却会形成问题。为了重现这个问题,下面我们模拟近似的场景,将文件可读流的每次读取的Buffer长度限制为11,代码如下:
图片搭配该代码的测试数据为李白的《静夜思》。执行该程序,将会得到以下输出:
产生这个输出结果的原因在于文件可读流在读取时会逐个读取Buffer。
这首诗的原始Buffer应存储为:
由于我们限定了Buffer对象的长度为11,因此只读流需要读取7次才能完成完整的读取,结果是以下几个Buffer对象依次输出:
上文提到的buf.toString()方法默认以UTF-8为编码,中文字在UTF-8下占3个字节。所以第一个Buffer对象在输出时,只能显示3个字符,Buffer中剩下的2个字节(e6 9c)将会以乱码的形式显示。第二个Buffer对象的第一个字节也不能形成文字,只能显示乱码。于是形成一些文字无法正常显示的问题。
在这个示例中我们构造了11这个限制,但是对于任意长度的Buffer而言,宽字节字符串都有可能存在被截断的情况,只不过Buffer的长度越大出现的概率越低而已,但该问题依然不可忽视。
有的,我们别忘了可读流还有一个设置编码的方法setEncoding(),示例如下:
该方法的作用是让data事件中传递的不再是一个Buffer对象,而是编码后的字符串。为此,我们继续改进前面诗歌的程序,添加setEncoding()的步骤如下:
重新执行程序,得到输出:
事实上,在调用setEncoding()时,可读流对象在内部设置了一个decoder对象。每次data事件都通过该decoder对象进行Buffer到字符串的解码,然后传递给调用者。是故设置编码后,data不再收到原始的Buffer对象。
decoder对象来自于string_decoder模块StringDecoder的实例对象。
可以看看 下面的代码:
我将前文提到的前两个Buffer对象写入decoder中。奇怪的地方在于“月”的转码并没有如平常一样在两个部分分开输出。StringDecoder在得到编码后,知道宽字节字符串在UTF-8编码下是以3个字节的方式存储的,所以第一次write()时,只输出前9个字节转码形成的字符,“月”字的前两个字节被保留在StringDecoder实例内部。第二次write()时,会将这2个剩余字节和后续11个字节组合在一起,再次用3的整数倍字节进行转码。于是乱码问题通过这种中间形式被解决了。
文章名称:深入探究Node|(5)“Buffer与乱码的故事”有十问
文章位置:http://www.shufengxianlan.com/qtweb/news48/99548.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联