[[403568]]

 前言

而今，只要是工程化的項目，大多離不開 sourcemap 的身影，一言蔽之：構(gòu)建處理前的代碼和處理后的代碼之間的橋梁。但卻很少有同學(xué)真的去深入了解它的運作原理，真問起來也就停留在“啊，有個.map 文件，可以通過它定位到源碼信息”，來，我們?nèi)コ虺颍创a是一句簡單的`console.log('好好學(xué)習(xí),天天向上'`)的`.map`文件

如果我告訴你，位置信息就在mapping對應(yīng)的這堆字母里

sourcemap成為了房間里的大象，一旦出現(xiàn)諸如“無法映射到源文件”“只能映射到 loader 處理后的文件”等問題，多數(shù)人是毫無頭緒的;而就像 TJ 大神說的: "不要直接 copy 解決方案，要理解后自己去實現(xiàn)";

閑言少敘，書歸正傳(不好意思，最近愛看評書)，通過本文你將收獲什么呢?

本文目標(biāo)

sourcemap配置項給你安排的明明白白，順帶送上生產(chǎn)環(huán)境、開發(fā)環(huán)境最佳實踐

sourcemap定位原理給你安排的明明白白，Base64-VQL是怎么做到生成mapping記錄源碼和處理后代碼間的映射

感恩大奉送，編碼給你安排的明明白白，base64 編碼、VLQ 編碼、base64-vlq 編碼的三世孽緣

讀至此處，您還要跑?

冰冰動圖大合集云盤，en，是不可能給的，就給一張你們瞅瞅好了

sourcemap：devTools 配置項二三事

對于sourcemap而言，我們最常見的，莫過于在 webpack 的配置項devTools中進行使用，而有多少種供我們選擇的配置呢?

也不多，二十種的樣子，好了，官網(wǎng)鏈接在此，大家去背吧，背完記得喊一聲，本文完。

抱歉我皮了，所謂變中取定，這么多種配置項其實只是五個關(guān)鍵字 eval、source-map、cheap、module 和 inline 的組合罷了，請牢記這張表，破陣心法，忽悠時方可娓娓道來。

怎么理解呢?實戰(zhàn)見真知。

舉例詳解

文件源碼如下

let a = 1,b; 
b = a; 

source-map 處理后輸出結(jié)果

//# sourceMappingURL=bundle.js.map 

 

eval 處理后輸出結(jié)果

eval("var a = 1,\n    b;\nb = a;\n\n//////////////////\n// WEBPACK FOOTER\n// ./src/index.js\n// module id = 0\n// module chunks = 0\n\n//# sourceURL=webpack:///./src/index.js?"); 

 

解決問題：原作者解釋whyeval，關(guān)鍵在于下面兩句話

• devtool: "source-map" cannot cache SourceMaps for modules and need to regenerate complete SourceMap for the chunk. It's something for production.
• devtool: "eval-source-map" is really as good as devtool: "source-map", but can cache SourceMaps for modules. It's much faster for rebuilds.

翻譯來說劃重點：加 eval 和不加是一樣的🐂，但加了eval后可以緩存，于是更🐂。

Inline-source-map處理后輸出結(jié)果

//# sourceMappingURL=data: ...（base64 字符串） 

 

cheap-source-map處理后輸出結(jié)果

//# sourceMappingURL=bundle.js.map 

 

對于cheap-source-map而言，只會定義到出錯的這一行

而對于source-map而言，則會精準(zhǔn)到列

存在的問題

1. 錯誤信息只會定義到行，而不會定義到列
2. 對于經(jīng)由 babel 之類工具轉(zhuǎn)義的代碼，只能定位到轉(zhuǎn)換后的代碼

這就引出了我們最后的一個關(guān)鍵字

cheap-module-source-map處理后輸出結(jié)果

//# sourceMappingURL=bundle.js.map 

 

測試代碼

# sum 
let sum =  (a, b) => { 
    return a + b 
} 
debugger 
export default sum; 
# index.js 
import sum from './sum'; 
console.log(sum); 

對于cheap-source-map而言，此時頁面 debugger 展示源碼是 es5 的代碼，因為已經(jīng)被 babal 轉(zhuǎn)義了

而對于source-map而言，則會精準(zhǔn)到原始代碼

配置項關(guān)鍵字小結(jié)

至此，我們`source-map`的五個關(guān)鍵詞的學(xué)習(xí)也就告一段落了，而最開始提到官網(wǎng)給出的二十幾種配置無非是選詞組合而已，再附送下一些常見配置項的關(guān)鍵參數(shù)對比吧。

配置項最佳實踐

開發(fā)環(huán)境

• 我們在開發(fā)環(huán)境對 sourceMap 的要求是：快(eval)，信息全(module)，
• 且由于此時代碼未壓縮，我們并不那么在意代碼列信息(cheap),

所以開發(fā)環(huán)境比較推薦配置：devtool: cheap-module-eval-source-map

生產(chǎn)環(huán)境

• 一般情況下，我們并不希望任何人都可以在瀏覽器直接看到我們未編譯的源碼，
• 所以我們不應(yīng)該直接提供 sourceMap 給瀏覽器。但我們又需要 sourceMap 來定位我們的錯誤信息，
• 一方面 webpack 會生成 sourcemap 文件以提供給錯誤收集工具比如 sentry，另一方面又不會為 bundle 添加引用注釋，以避免瀏覽器使用。

這時我們可以設(shè)置devtool: hidden-source-map

至此，關(guān)于sourcemap在 webpack 中的應(yīng)用層面我們就算是了解個七七八八了。但其實，這只是一個開頭小菜

本文最大目標(biāo)來啦：sourcemap 到底怎么做到源文件和處理后文件映射的?

輸出內(nèi)容分析：map 文件詳解

要分析實現(xiàn)，還是得先從現(xiàn)象下手，假定源文件script.js內(nèi)容為

let a=1; 
let b=2; 
let c=3; 

其輸出內(nèi)容為

script-min.js

var a=1,b=2,c=3; 

script-min.js.map

{"version":3,"file":"script-min.js","lineCount":1,"mappings":"AAAA,IAAIA,EAAE,CAAN,CACIC,EAAE,CADN,CAEIC,EAAE;","sources":["script.js"],"names":["a","b","c"]} 

文件字段具體含義分析

 

可以看到，既然我們要定位，自然最關(guān)心的是具有【記錄位置信息】功能的 mapping 屬性，接下來詳細(xì)講解如何分析mapping。

mapping 屬性值含義

• 【行對應(yīng)】很好理解，即一個分號為一行，因為壓縮后基本上都是一行了，所以這個沒啥有用信息;
• 【位置對應(yīng)】可以理解為分詞，每個逗號對應(yīng)轉(zhuǎn)換后源碼的一個位置;
• 【分詞信息】是關(guān)鍵，如AAAA代表該位置轉(zhuǎn)換前的源碼位置，以VLQ編碼表示;

其中【分詞信息】每組最多五位(如果不是變量，只會有四位)，分別是：

• 第一位，表示這個位置在【轉(zhuǎn)換后代碼】的第幾列。
• 第二位，表示這個位置屬于【sources 屬性】中的哪一個文件。
• 第三位，表示這個位置屬于【轉(zhuǎn)換前代碼】的第幾行。
• 第四位，表示這個位置屬于【轉(zhuǎn)換前代碼】的第幾列。
• 第五位，表示這個位置屬于【names 屬性】的哪一個變量。

到此，我們也算是知道 map 文件到底是怎么組成的了。

小思考

Q：但為什么這么設(shè)定呢?理解絕對比死記更有效，其他都好理解，但談到分詞信息中的位置對應(yīng)，我們下意識應(yīng)該都會想到坐標(biāo)，記錄組成元素在編譯后文件和源文件的坐標(biāo)，就形成了映射;但我們看到的`mapping`卻是字符串，為什么?A：因為體積，如果直接坐標(biāo)記錄信息，至少存在兩點空間損耗：編譯后文件的縱坐標(biāo)大的驚人;因為坐標(biāo)信息是數(shù)字，如果采用數(shù)組存儲，將有大量存儲空間浪費。注意上面的`version`字段，象征著版本，而對于現(xiàn)在的默認(rèn)也是最新版`Source Map Revision 3.0`(V3)而言，通過使用 Base64 VLQ 編碼，大大縮小了.map 文件的體積，而這也是本文最有價值的思考點：`Base64 VLQ`是啥?為什么能做到縮減體積。

此處附送base64vlq 在線轉(zhuǎn)換地址，將上面的mappings對應(yīng)的字符串輸入，將會得到對應(yīng)的數(shù)字信息，如AAAA對應(yīng)的是0000，這兩者之間的映射規(guī)則就是base64vlq編碼。

整理目標(biāo)

到此，我們整理下接下來要做的事情，抬頭看天，低頭走路。

我們希望解決坐標(biāo)信息占用空間過大的問題，主要在于兩點

• 編譯后文件列號過大問題：因為會編譯成一行，可以想象靠后的元素縱坐標(biāo)是很大的
• 數(shù)據(jù)結(jié)構(gòu)占據(jù)空間問題：數(shù)組自然比字符串更耗費空間

隨著對這兩個問題的思考，我們將會徹底理解，為啥我們用于記錄位置信息的mapping會是這個鬼樣子

AAAA,IAAIA,EAAE,CAAN,CACIC,EAAE,CADN,CAEIC,EAAE 

打起精神，繼續(xù)學(xué)!冰冰續(xù)命

相對位置解決列號過大問題

對于第一點輸出后的位置元素的列號特別大的問題，可以采用相對位置的方案進行解決，具體規(guī)則如下

• 第一次記錄的輸入位置和輸出位置是絕對的，往后的輸入位置和輸出位置都是相對上一次的位置移動了多少

舉例而言，假設(shè) a.js 內(nèi)容為feel the force，處理后輸出the force feel ，其 names 為:['feel','the','force'], source: ['a.js']

則其按照相對位置輸出的關(guān)系如下

| 字符組合 | 位置類別 | 輸出位置 | 輸入位置 | 映射(輸出 x | 屬于文件在 source 的索引 | 輸入 x | 輸入 y | 變量在 names 的索引) | | --- | --- | --- | --- | --- | | feel | 絕對 | 10, 0 | 0, 0 | 10 | 0 | 0 | 0 | 0 | | the | 相對 | -10, 0 | 5, 0 | -10 | 0 | 5 | 0 | 1 | | force | 相對 | 4, 0 | 4, 0 | 4 | 0 | 4 | 0 | 2 |

其中【位置類別】的相對代表相對上一個元素坐標(biāo)的偏移，比如`the`的輸出位置相對于`feel`就是 x 軸左移 10，y 軸不變，所以其輸出位置為(-10, 0);其輸入位置是 x 軸右移 5，y 軸不變，所以其輸入位置為(5 ,0)，`force`對比`the`類推即可。有心的小伙伴會發(fā)現(xiàn)【輸出 y 坐標(biāo)】在映射中沒有記錄，其原因也很簡單，因為處理后的輸出代碼都是一行的，固定為 0，所以也就沒必要記錄了現(xiàn)在，我們就來到了第二點了，如何壓縮`mapping`?涉及到壓縮體積，便逃不掉編碼

就像上面說的，sourcemap 通過`Base64 VLQ`編碼進行了縮小.map 文件的體積的處理。那就開始琢磨下關(guān)鍵而神奇的`Base64 VLQ`吧

base64VLQ 解決數(shù)據(jù)結(jié)構(gòu)占據(jù)空間問題

以坐標(biāo)信息`[0,0,0,0], [4,0,0,4,0]`為例首先，我們得明確，對于源、目標(biāo)文件的元素坐標(biāo)映射關(guān)系，數(shù)組是不可能用數(shù)組的，這輩子是不可能用數(shù)組的，用字符串不香嗎?(原因就不解釋了)

[[403573]]

既然是字符串，原例就變成了`0,0,0,0 | 4,0,0,4,0` ，有沒有感覺這個`,`有點不順眼?本來它們就都是描述同一個映射關(guān)系，干嘛還浪費這空間，想想我們編譯后的那一大串，如果保留這個分隔符，別扭的很，那如何去掉呢?主角`Base64-VLQ`登場。Base64-VLQ 編碼見名知意，其實就是 VLQ 編碼方式和 base64 編碼的“一套組合拳”，它能去除分隔符主要在于 VLQ 編碼方式【變長】的特性，關(guān)鍵點就一句：用二進制表示，進行分組后每組最高位表示連續(xù)性，如果是 1，代表這組字節(jié)后面的一組字節(jié)也屬于同一個數(shù);如果是 0，表示該數(shù)值到這就結(jié)束了。不明白?十臉懵逼?沒關(guān)系，咱一步步來。柿子挑軟的捏，要了解`Base64 VLQ`，咱就先查漏補缺下最熟悉的陌生人：`base64`編碼。

BASE64 編碼

我們開發(fā)同學(xué)最初了解到base64大概是在小icon圖標(biāo)的處理上，當(dāng)時了解到的是可以將圖片的二進制轉(zhuǎn)為文本，從而減少 http 請求，但只適用于小圖標(biāo)等體積小的內(nèi)容，因為使用base64編碼處理過會導(dǎo)致被處理對象體積增加 33%;那么base64到底是什么?它出現(xiàn)就是為了處理小圖標(biāo)嗎?了解事物的經(jīng)典三問

是什么?

在 MDN 中的定義：

• 是一組相似的二進制到文本(binary-to-text)的編碼規(guī)則，使得二進制數(shù)據(jù)在解釋成 radix-64 的表現(xiàn)形式后能夠用 ASCII 字符串的格式表示出來。

為什么出現(xiàn)?

回想一下，有沒有遭遇過用記事本打開exe、jpg、pdf這些文件時，看到一大堆亂碼?很簡單，在 ASCII 碼中規(guī)定，031、127 這 33 個字符屬于控制字符，32126 這 95 個字符屬于可打印字符(來源于Unicode 官網(wǎng))，也就是說網(wǎng)絡(luò)傳輸、文本處理只能使用這 95 個字符，不在這個范圍內(nèi)的字符無法使用。那么該怎么才能傳輸其他字符呢?這就就需要一個二進制到字符串的轉(zhuǎn)換方法。

怎么做到的?

編碼本身并不復(fù)雜，對使用者而言按圖索驥而已，關(guān)鍵是它規(guī)則為什么這么設(shè)定，以及修補規(guī)則出現(xiàn)的原因。

既然 ASCII 碼表中存在不可打印字符，那我們就定義一個新碼表，其范圍固定在可打印字符內(nèi)。(這就意味著要多個新碼表字符表示一個 ASCII 碼表字符，原因很簡單，你要用蘋果、梨表示所有水果，那只好定義兩個蘋果是西瓜、兩個梨是番茄、一個蘋果一個梨是。。。排列組合)

新碼表字符的組成單元占幾個字節(jié)?

我們知道基礎(chǔ) ASCII 碼，使用 7 位二進制數(shù)表示組成單元，新碼表的表示范圍小于 ASCII 碼表(因為要確保新碼表中都是可打印字符)，這也就意味著，新碼表使用的二進制數(shù)必須少于七位，而二進制數(shù)越少代表其能表示的字符越少，那就需要更多個二進制數(shù)來表示一個字符，而這個位數(shù)應(yīng)該是越多越好的，因為這樣我們所有的組成元素(新碼表)就多了，于是定 6 位吧。2^6 是 64，于是新碼表叫做 base64(這塊純屬于個人理解，僅供推理記憶，如有錯誤請不吝賜教)

如何 ASCII 碼進行 Base64 編解碼

ASCII 碼字符占 8 位二進制，而 Base64 占 6 位，取最小公倍數(shù)即為 24，即可以用 4 個 base64 字符去表示 3 個 ASCII 碼字符。遂有如下轉(zhuǎn)換規(guī)定

1.ASCII 碼字符串根據(jù) ASCII 碼對照表轉(zhuǎn)換為二進制數(shù)值;

2.把二進制數(shù)值按每 6 位進行劃分;

• 假設(shè)字符數(shù)是 3 的倍數(shù)，比如三個 ASCII 碼字符，就可以三個為一組，用四個 base64 字符來表示(3 * 8 == 4 * 6，enen，應(yīng)該好理解的)
• 如果待編碼字符串的長度不是 3 的倍數(shù)，則用 0 補位. 如果有連續(xù) 6 位都是 0 的話, 就用=來表示。

3.然后 6 位二進制轉(zhuǎn)化為十進制根據(jù) Base64 對照表找到編碼字符.

對照表

擴展

在JavaScript中，原生提供了 base64 和 ASCII 碼之間的轉(zhuǎn)換 API

舉例而言

以 ASCII 的 A 字符為例，A 轉(zhuǎn)為二進制如上010000001，不足三位，所以補 0，從而補齊 24 位

再 6 位為一組，對照Base64 編碼表，全為 0 的話用=號代替

所以，得出結(jié)果，A 字符對應(yīng)的 Base64 編碼是QQ==

至此，我們就算是對 base64 這位“最熟悉的陌生人”至少能答出個來龍去脈了

擴展-修補規(guī)則：URL 安全的 Base64 編碼

修補規(guī)則出現(xiàn)背景

Base64 編碼可用于在[HTTP](http://zh.wikipedia.org/wiki/HTTP)環(huán)境下傳遞較長的標(biāo)識信息，然而，標(biāo)準(zhǔn)的 Base64 并不適合直接放在 URL 里傳輸，因為 URL 編碼器會把標(biāo)準(zhǔn) Base64 中的「/」和「+」字符變?yōu)樾稳纭?XX」的形式，而這些「%」號在存入數(shù)據(jù)庫時還需要再進行轉(zhuǎn)換，因為[ANSI](http://zh.wikipedia.org/wiki/ANSI) [SQL](http://zh.wikipedia.org/wiki/SQL)中已將「%」號用作通配符。咱證明下權(quán)威性，來看看`rfc`中的定義

• For base 64, the non-alphanumeric characters (inparticular, "/") may be problematic in file names and URLs.

翻譯過來即：

• 對于 base 64 編碼, 非字母表中的字符 (特別是 "/") 可能會在文件名和 URL 中出現(xiàn)問題

修補規(guī)則

為解決此問題，可采用一種**用于 URL 的改進 Base64**編碼，具體也很簡單，加密時先執(zhí)行三條規(guī)則再轉(zhuǎn)`base64`即可(解密反之)

• 不在末尾填充=號
• + 用 *替換
• / 用 -替換

擴展-實現(xiàn)：在JavaScript中如何實現(xiàn)base64url的編碼解碼?

編碼

function urlsafe_b64encode(str) { 
      base64Str = base64_encode(str); 
      base64UrlStr = base64Str.replaceaLL('+','*').replaceaLL('/','-').replaceaLL('=',''); 
      return base64UrlStr; 
   } 

解碼

function urlsafe_b64decode(base64UrlStr) { 
      data = base64Str.replaceaLL('*','+').replaceaLL('-','/'); 
       let mod4 = strlen(data) % 4; 
       if (mod4) { 
           data = data.substr('====', mod4); 
       } 
       return base64_decode(data); 
    } 

有興趣的小伙伴可以使用處理 base64url 的 npm 包地址自行去驗證下哦

# npm i base64url  
const base64url = require('base64url'); 
console.log('字符串     base64     base64URL'); 
console.log(' A     ', encode('A'),'     ',base64url("A")); //  A      QQ==       QQ 

 

VLQ 編碼

這是一個很陌生的詞匯，但卻是sourcemap實現(xiàn)的核心工具，還是老樣子，了解事物的經(jīng)典三問

是什么?

• VLQ 是 Variable-length quantity 的縮寫，變長編碼，用以通過任意位二進制精簡地表示很大的數(shù)值。

為什么出現(xiàn)?

縮減多數(shù)字組成的元素所占據(jù)的空間(比如按上文所生成的mapping，就是通過|進行區(qū)分不同數(shù)字的，這個|其實最好可以省掉，因為只是為了閱讀者好理解而已)

怎么做到的?

將數(shù)字轉(zhuǎn)化為二進制，然后規(guī)定通過二進制始末位具有標(biāo)識數(shù)字的起始的特殊含義，從而節(jié)省分隔符所占的空間，設(shè)定如下：

一個二進制字節(jié)有 8 個位，在 VLQ 編碼中設(shè)定最高位為是否連續(xù)的標(biāo)識，除了最高位，如果不足 7 個位的倍數(shù)則高位補 0;

對于大數(shù)字而言，需要多個單元進行表示，那么如果得知這幾個單元屬于同一個數(shù)字，編碼規(guī)則設(shè)定最高位表示連續(xù)性，如果是 1，代表這組字節(jié)后面的一組字節(jié)也屬于同一個數(shù);如果是 0，表示該數(shù)值到這就結(jié)束了;這就避免了分隔符，如|，的出現(xiàn)

舉例而言

對于數(shù)字 7 和 1200 以及-7，如果用 VLQ 分別該怎么進行表示呢?

對 7 而言

• 先判斷是不是七的倍數(shù)：不是，只有三位，所以前置位補 4 個 0;
• 只有一個單元，自然最高位是 0(標(biāo)識該數(shù)的結(jié)束);

得出的 VLQ 編碼就是0000111;

對于 1200 而言

• 先判斷是不是七的倍數(shù)：不是，有 11 位，所以前置位補 3 個 0，處理對象變?yōu)?0010010110000
• 只有兩個單元，所以第一個單元最高位是 1(標(biāo)識下一個單元還是表示該數(shù))，第二個單元是 0;

最后得到的結(jié)果即1000100100110000

到此，VLQ的編碼也算是告一段落了，其實就是一個規(guī)定，規(guī)定二進制某些位具有特定含義，從而節(jié)省空間，反正處理時按規(guī)定解碼就好了，也不需要人去看，再怎么難理解也是計算機的事兒，懶人改變世界嘛。

擴展一：VLQ 偏移自然數(shù)：Git 底層格式

在了解 VLQ 編碼的過程中，意外的了解到了很多冰山之下的知識，比如【VLQ 與自然數(shù)的相互轉(zhuǎn)換】在 Git 中居然有專門的實現(xiàn)的一個算法：雙射計數(shù)法(bijective numeration)，主要是如何做到一一映射從而避免多字節(jié) VLQ 的冗余現(xiàn)象，這個與本文主題相差有點大，不做過分拓展，推薦一篇文章《深扒 Git 底層格式：VLQ 偏移自然數(shù)》

擴展二：在JavaScript中如何實現(xiàn) VLQ 的編碼?

/**如何對數(shù)值進行 VLQ 編碼 * 1. 將數(shù)值改寫成二進制形式 10001001 * 2. 七位一組做分組，不足的補 0 * 3. 最后一組開頭補 0，其余補 1 * 4. 拼接 得出編碼 * @param {*} num  */function encodeForVLQ(num) {    let binary = num.toString(2);    let padded = binary.padStart(Math.ceil(binary.length / 7) * 7, '0');    let groups = padded.match(/\d{7}/g);     groups = groups.map((group,index)=>{          let pre = (index==0 && groups.length > 1?'1':'0')          return pre + group;      });    let vlqCode = groups.join('');    return vlqCode}console.log(encodeForVLQ2(7));console.log(encodeForVLQ2(1200)); 

至此，我們就完成了對 VLQ 編碼處理的了解，但我們可以發(fā)現(xiàn)輸出的是二進制數(shù)，而如果我們希望獲得的是字符串，就需要使用到BASE64 vlq編碼處理了

Base-VLQ 編碼

見名知意，其實就是 VLQ 編碼方式和 base64 編碼的結(jié)合。不過有幾點與 VLQ 的區(qū)別也需要注意一下

• Base64 VLQ 需要能夠表示負(fù)數(shù),于是用第一個單元的最后一位來作為符號標(biāo)志位
• 在 Base64 VLQ 中，因為要和 base64 相對應(yīng)，所以修改vlq7 位一組的設(shè)定，改為 5 位一組，加上設(shè)定為最高位的連續(xù)位正好六位。

是什么?

對數(shù)字進行 VLQ 編碼處理后，使用 base64 字符表示 VLQ 編碼的結(jié)果。

為什么出現(xiàn)?

考慮到 mapping 文件的可閱讀和文本軟件處理的問題，VLQ 轉(zhuǎn)化后的二進制應(yīng)該通過可打印字符去表示。

怎么做到的?

大致與 VLQ 編碼的處理邏輯相似，都是分組，然后用最高位表示連續(xù)，最關(guān)鍵的不同在于base64-vlq需要表示負(fù)數(shù)，于是用第一個單元的最后一位來作為符號標(biāo)志位。

1.在 base64 中，將 VLQ 存儲單元是 8 個 btye 的設(shè)定改為 6 個，這樣就對應(yīng)上了 base64 的存儲格式。

2.對于正負(fù)而言，編碼規(guī)則設(shè)定第一個單元的最后一位用于表示正負(fù)數(shù)，零正一負(fù);

• 這里需要注意，為什么說是【第一個單元】，因為一共六個位，去掉一個表示連續(xù)，一個表示正負(fù)，那能表示的范圍是[-15,15]，如果數(shù)字過大，就會需要多個單元去描述(這也是說其變長的原因)非第一個單元是不需要表示正負(fù)的，所以只需要最高位表示是否終止即可。

3.將 VLQ 每個單元對應(yīng)的 base64 字符存儲下來即可

舉例而言

對于數(shù)字 7 和 1200 以及-7，如果用base64-VLQ分別該怎么進行表示呢?

首先，對 7 而言

• 只有一個單元，自然最高位是 0;
• 正數(shù)，所以最后一位是 0;
• 最后只有三位，所以前置位補 0;

得出的 VLQ 編碼就是001110;

其次，對于 1200 而言

先完成第一個單元

• 多個單元，所以連續(xù)，最高位是 1;
• 正數(shù)，所以最后一位是 0;
• 超過一個單元，所以對于第一個單元在二進制中從后取出四個數(shù)出來填充四位即可

那得到的第一個單元的組成就是100000

再完成第二個單元

• 還是填不滿，所以聯(lián)系，最高位是 1
• 非第一個單元，所以不管正負(fù)了，取出五個數(shù)填充五位即可

得到的第二個單元的組成就是101011

例推下去，最后得到的結(jié)果即100000101011000010

 

根據(jù)mapping獲取信息

知道了 mapping 文件時如何來的，關(guān)鍵在于我們常見的場景是有類似AAAA,IAAIA,EAAE,CAAN,CACIC,EAAE,CADN,CAEIC,EAAE的 mapping 文件，那我們怎么從中獲取信息呢?很簡單，按照編碼方式反著來就好了，具體可見【擴展-解碼】的實現(xiàn)。

擴展：在JavaScript中如何實現(xiàn)base64-VLQ的編碼解碼?

在此實現(xiàn)一個簡易版本，其實目前有base64-vql的處理包，處理 vql 的 npm 包地址，其內(nèi)部實現(xiàn)大多用到的是諸如>>> |之類的位運算，在此就不過分展開了，有機會單獨出一篇文章，思路是相似的。

編碼

let base64 = [    'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P',    'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'a', 'b', 'c', 'd', 'e', 'f',    'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v',    'w', 'x', 'y', 'z', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '+', '/']; /**如何對數(shù)值進行 bae64-VLQ 編碼 * 1. 將數(shù)值改寫成二進制形式  * 2. 五位一組做分組，不足的補 0，并將組倒序排序 * 3. 最后一組開頭補 0，其余補 1 * 4. 轉(zhuǎn) bae64 進制，即通過對應(yīng)索引在 base64 碼表中取值  * @param {*} num  */function encode(num) {    //1. 改寫成二進制形式,如果是負(fù)數(shù)的話是絕對值轉(zhuǎn)二進制    let binary = (Math.abs(num)).toString(2);    //2.正數(shù)最后邊補 0,負(fù)數(shù)最右邊補 1,127 是正數(shù),末位補 0     binary = num >= 0 ? binary + '0' : binary + '1';    //3.五位一組做分組，不足的補 0     let zero = 5 - (binary.length % 5);    if (zero > 0) {        binary = binary.padStart(Math.ceil(binary.length / 5) * 5, '0');    }    let parts = [];    for (let i = 0; i < binary.length; i += 5) {        parts.push(binary.slice(i, i + 5));    }    //4. 將組倒序排序     parts.reverse();    //5. 最后一組開頭補 0,其余補 1    for (let i = 0; i < parts.length; i++) {        if (i === parts.length - 1) {            parts[i] = '0' + parts[i];        } else {            parts[i] = '1' + parts[i];        }    }    //6. 轉(zhuǎn) bae64 進制，即通過對應(yīng)索引在 base64 碼表中取值     let chars = [];    for (let i = 0; i < parts.length; i++) {        chars.push(base64[parseInt(parts[i], 2)]);    }    return chars.join('')}let result = encode(137);console.log(result); 

解碼

let base64 = [    'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P',    'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'a', 'b', 'c', 'd', 'e', 'f',    'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v',    'w', 'x', 'y', 'z', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '+', '/'];function getValue(char) {    let index = base64.findIndex(item => item == char);//先找這個字符的索引    let str = (index).toString(2);//索引轉(zhuǎn)成 2 進制    str = str.padStart(6, '0');//在前面補 0 補到 6 位    //最后一位是符號位,正數(shù)最后一位是 0,負(fù)數(shù)最后一位為 1    let sign = str.slice(-1)=='0'?1:-1;    //最后一組第一位為 0,其它的第一位為 1    str = str.slice(1, -1);    return parseInt(str, 2)*sign;}function decode(values) {    let parts = values.split(',');//分開每一個位置    let positions = [];    for(let i=0;i<parts.length;i++){        let part = parts[i];        let chars = part.split('');//得到每一個字符        let position = [];        for (let i = 0; i < chars.length; i++) {            position.push(getValue(chars[i]));//獲取此編寫對應(yīng)的值        }        positions.push(position);    }    return positions;}let positions = decode('AAAA,IAAIA,EAAE,CAAN,CACIC,EAAE,CADN,CAEIC,EAAE');//后列,哪個源文件,前行,前列,變量 console.log('positions',positions);let offsets = positions.map(item=>[item[2],item[3],0,item[0],]);console.log('offsets',offsets);let origin = {x:0,y:0};let target = {x:0,y:0};let mapping=[];for(let i=0;i<offsets.length;i++){    let [originX,originY,targetX,targetY] = offsets[i];    origin.x += originX;    origin.y += originY;    target.x += targetX;    target.y += targetY;    mapping.push(`[${origin.x},${origin.y}]=>[${target.x},${target.y}]`);}console.log('mapping',mapping); 

有興趣的小伙伴可以使用處理 vql 的 npm 包地址自行去驗證下哦

# npm i vlq const vlq = require('vlq');console.log(vlq.encode( 137 )); // yIconsole.log(vlq.decode( 'yI' )); // 137 

 

關(guān)于base64-vlq的尾聲

到此，base64-VLQ的編碼也算是告一段落了，其實就是一個規(guī)定，規(guī)定二進制某些位具有特定含義，從而節(jié)省空間，反正處理時按規(guī)定解碼就好了，也不需要人去看，再怎么難理解也是計算機的事兒，懶人改變世界嘛。

尾聲

很喜歡《看見》，看來很多遍，其中一篇是《真實自有萬鈞之力》，大意講的是拍攝時要“去雕飾，去匠氣”，真正有價值的東西會自然而然的流露出來;研究 sourceMap 原理的過程中很“突兀”的想到了這句話，很多時候，我們對高大上的名詞趨之若鶩，卻很少思考一些像`sourcemap`這類實際解決痛點的“硬核”知識點置若罔聞，看到編碼就“累覺不愛”，老實講，要不是因為設(shè)定了交稿日期，我起碼還得拖個一兩周，因為看編碼實在是太太太煩了，又不常用，但堅持下來后才發(fā)現(xiàn)很多諸如`base64`、`ASCII`之類的知識點串聯(lián)成線，“通了”，大概很多小伙伴都或多或少有過這種類似頓悟的感覺，其實就算前端出了名的新知識點層出不窮，我們還是可以看到很多通用的、沉在冰山之下的“道”，而這，則需要靜下來去思考。

涉及到的工具

• 處理 vql 的 npm 包地址
• base64vlq 在線轉(zhuǎn)換