在 Stream 篇結(jié)中，我們留下了一個問題，下述代碼輸出的 chunk 是一個什么東西？

通過打印，我們發(fā)現(xiàn) chunk 是 Buffer 對象，其中的元素是16進制的兩位數(shù)，即0～255的數(shù)值?！鞠嚓P(guān)教程推薦：nodejs視頻教程、編程教學】

說明在 Stream 中流動的數(shù)據(jù)就是 Buffer，那下面就讓我們來探究一下 Buffer 的真實面目！

? Node 中為什么要引入 Buffer?

最開始的時候 JS 只在瀏覽器端運行，對于 Unicode 編碼的字符串容易處理，但是對于二進制和非 Unicode 編碼的字符串處理困難。并且二進制是計算機最底層的數(shù)據(jù)格式，視頻/音頻/程序/網(wǎng)絡(luò)包都是以二進制來存儲的。所以 Node 需要引入一個對象來操作二進制，因此 Buffer 誕生了，用于 TCP流/文件系統(tǒng)等操作處理二進制字節(jié)。

由于 Buffer 在 Node 中過于常用，所以在 Node 啟動的時候已經(jīng)引入了 Buffer，無需使用 require()

ArrayBuffer

是什么

ArrayBuffer 是內(nèi)存之中的一段二進制數(shù)據(jù)，本身不能夠操作內(nèi)存，需要通過TypedArray 對象或者 DataView 來操作。將緩沖區(qū)中的數(shù)據(jù)表示為特定的格式，并通過這些格式來讀寫緩沖區(qū)的內(nèi)容，其部署了數(shù)組接口，可以使用數(shù)組的方式來操作數(shù)據(jù)

TypedArray 視圖

最常用的是 TypeArray 視圖，用于讀寫簡單類型的 ArrayBuffer，比如 Uint8Array(無符號8位整數(shù))數(shù)組視圖,?Int16Array(16位整數(shù))數(shù)組視圖

和 Buffer 的關(guān)系

NodeJS 中的 Buffer 類其實是 Uint8Array 的實現(xiàn)。

Buffer 結(jié)構(gòu)

Buffer 是一個類似 Array 的對象，但是它主要用于操作字節(jié)

模塊結(jié)構(gòu)

Buffer 是 JS 和 C 結(jié)合的模塊，性能部分都由 C 實現(xiàn)，非性能部分都是 JS 實現(xiàn)的

Buffer 所占用的內(nèi)存不是由 V8 分配的，屬于堆外內(nèi)存。

對象結(jié)構(gòu)

Buffer 對象類似數(shù)組，其元素是16進制的兩位數(shù)，即0～255的數(shù)值

從這個例子能夠看出，不同字符在 Buffer 中占據(jù)的字節(jié)是不一樣的，在 UTF-8 編碼下，中文占據(jù)3個字節(jié)，英文和半角標號占用1個字節(jié)

? 輸入的元素是小數(shù)/負數(shù)/超出255會發(fā)生什么事情？

對于上述這種情況，Buffer 的處理為：

• 給元素的賦值小于0， 就將該值逐次加256，直到得到一個0到255之間的整數(shù)
• 如果得到的數(shù)值大于255，就逐次減256，直到得到0～255區(qū)間內(nèi)的數(shù)值
• 如果是小數(shù)，只保留整數(shù)部分

Buffer 里面為什么展示的是16進制

其實在內(nèi)存存儲的依舊是二進制數(shù)，只是 Buffer 在顯示這內(nèi)存數(shù)據(jù)的時候采用了16進制

大小為2字節(jié)的 buffer，一共有16 bit ，比如是00000001 00100011，如果直接這樣顯示不太方便就轉(zhuǎn)成為了16進制<buffer></buffer>

Buffer 的創(chuàng)建

Buffer.alloc 和 Buffer.allocUnsafe

創(chuàng)建固定大小的 buffer

Buffer.alloc(size [, fill [, encoding]])

• size 新 Buffer 的所需長度
• fill 用于預(yù)填充新 Buffer 的值。默認值: 0
• encoding 如果 fill 是一個字符串，則這是它的字符編碼。默認值: utf8

Buffer.allocUnsafe(size)

分配一個大小為 size 字節(jié)的 Buffer，allocUnsafe 執(zhí)行速度比 alloc 快，我們發(fā)現(xiàn)其結(jié)果并不像 Buffer.alloc 那樣都初始化為 00

當調(diào)用 allocUnsafe 時分配的內(nèi)存段尚未初始化，這樣分配內(nèi)存速度很塊，但分配到的內(nèi)存片段可能包含舊數(shù)據(jù)。如果在使用的時候不覆蓋這些舊數(shù)據(jù)就可能造成內(nèi)存泄露，雖然速度快，盡量避免使用

Buffer 模塊會預(yù)分配一個內(nèi)部的大小為?Buffer.poolSize 的 Buffer 實例，作為快速分配的內(nèi)存池，用于使用 allocUnsafe 創(chuàng)建新的 Buffer 實例

Buffer.from

根據(jù)內(nèi)容直接創(chuàng)建Buffer

• Buffer.from(string [, encoding])
• Buffer.from(array)
• Buffer.from(buffer)

Buffer.allocUnsafe 的內(nèi)存機制

為了高效使用申請來的內(nèi)存，Node.js 采用了 slab 機制進行預(yù)先申請、事后分配，是一種動態(tài)的管理機制

使用?Buffer.alloc(size)?傳入一個指定的?size 就會申請一塊固定大小的內(nèi)存區(qū)域，slab 具有如下三種狀態(tài)

• full: 完全分配狀態(tài)
• partial：部分分配狀態(tài)
• empty：沒有被分配狀態(tài)

Node.js 使用8 KB 為界限來區(qū)分是小對象還是大對象

Buffer 在創(chuàng)建的時候大小就已經(jīng)被確定了且無法調(diào)整！

分配小對象

如果分配的對象小于 8KB，Node 會按著小對象的方式來進行分配

Buffer 的分配過程中主要使用一個局部變量?pool 作為中間處理對象，處于分配狀態(tài)的?slab 單元都指向它。以下是分配一個全新的 slab 單元的操作，它將會新申請的 SlowBuffer 對象指向它

一個 slab 單元

分配一個 2KB 大小的 Buffer

創(chuàng)建一個 2KB 的 buffer后，一個 slab 單元內(nèi)存如下：

這個分配過程是由 allocate 方法完成

當我們創(chuàng)建了一個 2KB 的 buffer 之后，當前 slab 狀態(tài)為 partial

再次創(chuàng)建 buffer 的時候，會去判斷當前 slab 剩余空間是否足夠。如果足夠，使用剩余空間，并更新 slab 的分配狀態(tài)

如果 slab 空間不夠，就會構(gòu)建新的 slab，原 slab 中剩余的空間造成浪費

分配大對象

如果有超過 8KB 的 buffer，直接會走到 creatUnsafeBuffer 函數(shù)，分配一個 slab 單元，這個 slab 單元將會被這個大 Buffer 對象獨占

allocate 分配機制如圖

Buffer 的內(nèi)存分配機制

Buffer 和字符編碼

通過使用字符編碼，可實現(xiàn) Buffer 實例與 JavaScript 字符串之間的相互轉(zhuǎn)換

Node 中目前支持 utf8、ucs2、utf16le、latin1、ascii、base64、hex、base64Url 八種編碼方式，具體實現(xiàn)

針對于每一種不同的編碼方案都會用實現(xiàn)一系列 api，返回會有不同的結(jié)果，Node.js 會根據(jù)傳入的 encoding 來返回不同的對象

Buffer 和字符串的轉(zhuǎn)換

字符串轉(zhuǎn) Buffer

主要通過上述講的 Buffer.from 方法，默認的 encoding 方式為 utf-8

Buffer 轉(zhuǎn)字符串

? 為什么會出現(xiàn)亂碼呢？如何解決這個問題呢？

按著讀取來說，我們每次讀取的長度為4，chunk輸出如下

對于data = chunk等價于data = data.toString chunk.toString

由于一個中文占據(jù)三個字節(jié)，第一個 chunk 中的第四個字節(jié)會顯示亂碼，第二個 chunk 的第一第二個字節(jié)也無法形成文字等等，所以會展示亂碼問題

更多node相關(guān)知識，請訪問：nodejs 教程！

以上是深入了解Node中的Buffer的詳細內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！