在我的部落格A debugging issue caused by source code mapping裡我介紹了在我做SAP C4C開發時遇到的一個曾經困擾我很久的問題，最後結論是這個問題由于JavaScript的source code map機制在Chrome開發者工具裡起作用，其實是working as designed的一種行為。但是當時因為時間限制，沒有去深入學習JavaScript source code map的更多細節。
在這篇文章裡我用一個簡單的UI5應用來研究該機制。這個應用的UI僅僅包含一個Button，點選之後彈出一個Message Toast。
下面是我XML view和Controller的實作。
如何在本地找到sap-ui-core.js.map檔案
單擊sap-ui-core.js,在其最後一行1875行，看到該行内容：
這個檔案的字尾.map給了我們提示：其作用就是維護位置映射關系，将sap-ui-core.js(壓縮之後的檔案)裡的代碼位置映射到壓縮之前的代碼位置(來自壓縮之前的檔案名，代碼行數，代碼列數，涉及到的壓縮之前的JavaScript變量名)。
但是，同樣的，我在開發者工具的Network标簽裡也觀察不到這個.map檔案被加載。
在Chrome裡輸入url: “chrome://net-internals/#events”, 結果顯示确實有一個url請求去通路sap-ui-core.js.map, 隻是因為本地磁盤緩存能響應該請求, 是以沒有産生真正的網絡請求:
在Chrome裡輸入"chrome://cache"能看到Chrome本地的所有緩存，從這裡我成功找到了檔案sap-ui-core.js.map的本地緩存。
單擊該超連結能看到這條緩存的擡頭資訊。但是緩存的具體檔案内容顯示格式為HEX，沒法直接分析。
sap-ui-core.js.map檔案内容一覽
這篇部落格
Introduction to JavaScript Source Maps介紹了JavaScript source code map的基本知識。
檔案sap-ui-core.js.map的内容：
version: 3
.map檔案的各組成部分的作用和含義定義在一個叫做Source Map Revision Proposal的協定文檔裡，在我的例子sap-ui-core.js.map裡使用了該協定的第三版。
sources:
這是一個數組，包含了所有用于生成壓縮之後的js檔案的原始檔案的名稱。
names:
這是一個數組，包含了原始js檔案裡出現的JavaScript變量和屬性名稱。
下面是一個例子，展現了原始檔案之一Device-dbg.js裡的變量名稱和其在sap-ui-core.js.map檔案裡的names數組裡的對應記錄，友善您了解。
- mappings:
.map檔案最重要的部分，定義了原始檔案内的位置和生成壓縮版本檔案内位置的對應關系。對應關系記錄的粒度是基于壓縮之後檔案的每一行，用分号隔開。這樣做的好處是無需再配置設定而外的位來維護壓縮檔案位置的行号資訊。
回到我的例子，壓縮檔案sap-ui-core.js一共包含1874行，是以sap-ui-core.js.map一共出現了1874次分号，每個分号内又是一個很長的字元串，由一系列逗号隔開，這些由逗号隔開的字元串片段稱為Segment。每個Segment維護了一個位置的映射關系。
如何生成.map檔案
有很多開源的元件用于生成.map檔案，其中之一是Google Closure compiler。假設我想基于我的測試應用裡的controller實作檔案App.controller.js生成一個壓縮版本的檔案：
從Google網站下載下傳compile.jar， 然後生成一個名為script-min.js的壓縮檔案和script-min.js.map：
生成的壓縮檔案script-min.js隻有1行内容:
生成的script-min.js.map内容:
可以使用
vlq.js将這些segment解碼：
浏覽器打開該html，産生如下輸出：每個segment由4或5個字元組成。
每一位的對應含義:
第一位，表示這個位置在轉換後的壓縮檔案的第幾列。
第二位，sources數組中的索引，表示這個位置來自哪一個原始檔案。
第三位，表示這個位置屬于原始檔案的第幾行。
第四位，表示這個位置屬于原始檔案的第幾列。
第五位，names數組中的索引，表示這個位置屬于源檔案中的哪一個變量。
關于VLQ編碼的更多細節，可以閱讀這篇部落格Source Maps under the hood – VLQ, Base64 and Yoda