1. 为什么要有Buffer对象？
在Node中，应用需要处理网络协议、操作数据库、处理图片、接收上传文件等，在网络流和文件的操作中，还要处理大量二进制数据，JavaScript自有的字符串远远不能满足这些需求，于是Buffer对象应运而生。
Buffer在文件I/O和网络I/O中运用广泛，尤其在网络传输中，它的性能举足轻重。在应用中，我们通常会操作字符串，但一旦在网络中传输，都需要转换为Buffer，以进行二进制数据传输。在Web应用中，字符串转换到Buffer是时时刻刻发生的，提高字符串到Buffer的转换效率，可以很大程度地提高网络吞吐率。
2. 可以谈谈你所认识的Buffer对象吗？
嗯嗯，好的。
Buffer是一个像Array的对象，但它主要用于操作字节。所以我将会从模块结构和对象结构的层面上来认识它。
模块结构
Buffer是一个典型的JavaScript与C++结合的模块，它将性能相关部分用C++实现，将非性能相关的部分用JavaScript实现，如图所示。
在【深入探究Node】（4）“内存控制” 有十五问我们提到Buffer所占用的内存不是通过V8分配的，属于堆外内存。由于V8垃圾回收性能的影响，将常用的操作对象用更高效和专有的内存分配回收策略来管理是个不错的思路。由于Buffer太过常见，Node在进程启动时就已经加载了它，并将其放在全局对象（global）上。所以在使用Buffer时，无须通过require()即可直接使用。
Buffer对象结构
Buffer对象类似于数组，它的元素为16进制的两位数，即0到255的数值。示例代码如下所示：
由上面的示例可见，不同编码的字符串占用的元素个数各不相同，上面代码中的中文字在UTF-8编码下占用3个元素，字母和半角标点符号占用1个元素。
Buffer受Array类型的影响很大，可以访问length属性得到长度，也可以通过下标访问元素，在构造对象时也十分相似，代码如下：
上述代码分配了一个长100字节的Buffer对象。可以通过下标访问刚初始化的Buffer的元素，代码如下：
这里会得到一个比较奇怪的结果，它的元素值是一个0到255的随机值。同样，我们也可以通过下标对它进行赋值：
3. 哇塞，原来Buffer对象这么有意思，还可以当成Array来使用，我突发奇想，要是给元素赋值的值是小数而不是整数会怎么样呢？
给元素的赋值如果小于0，就将该值逐次加256，直到得到一个0到255之间的整数。如果得到的数值大于255，就逐次减256，
直到得到0~255区间内的数值。如果是小数，舍弃小数部分，只保留整数部分。
4. 我看Buffer对象很像字符串，它两可以互转吗？
可以的。
字符串转Buffer
字符串转Buffer对象主要是通过构造函数完成的：
通过构造函数转换的Buffer对象，存储的只能是一种编码类型。encoding参数不传递时，默认按UTF-8编码进行转码和存储。
Buffer转字符串
实现Buffer向字符串的转换也十分简单，Buffer对象的toString()可以将Buffer对象转换为字符串，代码如下：
比较精巧的是，可以设置encoding（默认为UTF-8）、start、end这3个参数实现整体或局部的转换。如果Buffer对象由多种编码写入，就需要在局部指定不同的编码，才能转换回正常的编码。
5. Buffer应该是常见于输入输入流中，你可以说说怎么使用吗？
Buffer在使用场景中，通常是以一段一段的方式传输。以下是常见的从输入流中读取内容的示例代码：
上面这段代码常见于国外，用于流读取的示范，data事件中获取的chunk对象即是Buffer对象。对于初学者而言，容易将Buffer当做字符串来理解，所以在接受上面的示例时不会觉得有任何异常。
6. 我有时候这样读取数据，然后打印出来，有时候会出现乱码，是什么原因呢？
一旦输入流中有宽字节编码时，问题就会暴露出来。如果你在通过Node开发的网站上看到[插图]乱码符号，那么该问题的起源多半来自于这里。
用多个字节来代表的字符称之为宽字符，而Unicode只是宽字符编码的一种实现，宽字符并不一定是Unicode。
这里潜藏的问题在于如下这句代码：
这句代码里隐藏了toString()操作，它等价于如下的代码：
值得注意的是，外国人的语境通常是指英文环境，在他们的场景下，这个toString()不会造成任何问题。但对于宽字节的中文，却会形成问题。为了重现这个问题，下面我们模拟近似的场景，将文件可读流的每次读取的Buffer长度限制为11，代码如下：
搭配该代码的测试数据为李白的《静夜思》。执行该程序，将会得到以下输出：
7.为什么 “月”、“是”、“望”、“低”4个字没有被正常输出，取而代之的是3个乱码？
产生这个输出结果的原因在于文件可读流在读取时会逐个读取Buffer。
这首诗的原始Buffer应存储为：
由于我们限定了Buffer对象的长度为11，因此只读流需要读取7次才能完成完整的读取，结果是以下几个Buffer对象依次输出：
上文提到的buf.toString()方法默认以UTF-8为编码，中文字在UTF-8下占3个字节。所以第一个Buffer对象在输出时，只能显示3个字符，Buffer中剩下的2个字节（e6 9c）将会以乱码的形式显示。第二个Buffer对象的第一个字节也不能形成文字，只能显示乱码。于是形成一些文字无法正常显示的问题。
在这个示例中我们构造了11这个限制，但是对于任意长度的Buffer而言，宽字节字符串都有可能存在被截断的情况，只不过Buffer的长度越大出现的概率越低而已，但该问题依然不可忽视。
8. so噶！那样的话，那我限制Buffer对象的长度为12，就不会有问题了吧！但是这样每次都要数，很麻烦，有没有简单的方法呢？
有的，我们别忘了可读流还有一个设置编码的方法setEncoding()，示例如下：
该方法的作用是让data事件中传递的不再是一个Buffer对象，而是编码后的字符串。为此，我们继续改进前面诗歌的程序，添加setEncoding()的步骤如下：
重新执行程序，得到输出：
9. 哇塞，真是令人兴奋，Node是如何实现这个输出结果的呢？
事实上，在调用setEncoding()时，可读流对象在内部设置了一个decoder对象。每次data事件都通过该decoder对象进行Buffer到字符串的解码，然后传递给调用者。是故设置编码后，data不再收到原始的Buffer对象。
10. 可是设置decoder后，即使被转码，那也无法改变宽字节字符串被截断的问题啊？
decoder对象来自于string_decoder模块StringDecoder的实例对象。
可以看看 下面的代码：
我将前文提到的前两个Buffer对象写入decoder中。奇怪的地方在于“月”的转码并没有如平常一样在两个部分分开输出。StringDecoder在得到编码后，知道宽字节字符串在UTF-8编码下是以3个字节的方式存储的，所以第一次write()时，只输出前9个字节转码形成的字符，“月”字的前两个字节被保留在StringDecoder实例内部。第二次write()时，会将这2个剩余字节和后续11个字节组合在一起，再次用3的整数倍字节进行转码。于是乱码问题通过这种中间形式被解决了。
