charles本地調試之map和rewrite功能

charles是一款mac下代理調試工具，對於前端開發同窗來講是至關方便的一個調試接口的工具；不過charles須要收費，不過在天朝幾乎收費的軟件都能找到破解方法；

使用charles前，須要將charles設置成mac OS的網絡系代理服務器，這樣charles就能夠捕獲到mac上全部的網絡請求，而後charles在作些手腳（如map和rewrite功能）就能夠很輕鬆的實現接口的調試。

至於charles的具體使用能夠在網上查閱其具體使用，本文就來講說在使用charles調試過程當中至關重要的map和rewrite功能，這也前端調試接口用到charles最多的功能。

map功能

---

map功能，顧名思義就是將某個請求進行重定向，用重定向後的內容來響應請求的內容；

map功能分爲map Local和map Remote,兩者區分是：

• map Local：是將某個網絡請求重定向到本地的某個文件

• map Remote：是將某個網絡請求重定向到另外一個網絡請求

  兩者除了重定向文件的位置不一樣以外，其餘功能都是同樣的。他們均可以對js、css、html以及api接口都可重定向，此外也可使用通配符來進行簡單的批量匹配，達到批量重定向的目的。

在使用map功能時，本人最多見的使用場景簡要說明以下：

• js、css重定向：主要是來調試js和css的實現效果

  • 本地開發獲取不到接口數據，那麼就使用測試環境，經過map Local來將制定的js、css重定向本地進行開發
  • 線上有個bug，想定位問題，可是線上代碼都壓縮過無法debug，這時可經過重定向到本地實現調試

• html重定向：在開發過程當中因爲本地沒有數據，那麼可使用測試環境的數據進行開發而不用mock數據，這時能夠訪問測試環境的某個頁面，而後將其頁面的html重定向到本地的某個頁面來獲取測試數據。
  頁面結構可能以下面這樣，有3個js引用，前面2個js爲每一個頁面公共的js，最後一個js爲當前頁的業務邏輯js：

<scritp type="text/javascript" src="http://host/path/com1.js"></scritp>
    <scritp type="text/javascript" src="http://host/path/com2.js"></scritp>
    <scritp type="text/javascript" src="http://host/path/page.js"></scritp>

這時，將上面頁面的html重定向到本地的開發頁面html，因爲本地頁面的3個js有2個是公共的，因此他會加載測試環境的對應js，這時須要將業務邏輯的js也需重定向到本地js，這樣就能夠開發了；

他只用了2個重定向操做實現：能夠實現本地開發，避免mock數據；不然須要多個重定向並且還須要本身mock數據。

• api重定向： 爲了mock數據；通常使用map Remote功能來將本地的請求重定向到測試或者線上環境的網絡請求。

除了單個map隱射外，還能夠使用*通配符進行批量匹配，不用一個個創建重定向了。下面舉一個實戰的例子。

在項目開發過程當中可能會遇到這種狀況，本地開發老是要爲各類數據而煩惱，那麼可否在本地開發中批量用到某個環境的數據呢？答案固然能夠！

在本人的某個項目開發中，本地開發由於沒有數據，須要相應環境的數據，因此就須要將本地請求數據的api接口map Remote到車上環境來獲取測試數據而不用進行大量的mock數據，由於涉及系統涉及到的數據api接口比較多，每一個都進行單獨重定向的話，效率過低；
而非數據api接口的請求不須要重定向，那麼涉及到的問題是：

• 修改數據請求接口api的host爲測試環境。

  本地系統中的/api/路徑下的請求都轉到對應的測試環境(cmstest.intra.xiaojukeji.com)的對應目錄/api/下,即數據接口請求的host改成測試環境hostcmstest.intra.xiaojukeji.com,請求路徑保持不變；

`http://127.0.0.1:8080/api/transit-nepenthes/line/list` ---> `http://cmstest.intra.xiaojukeji.com/api/transit-nepenthes/line/list`

• 非數據請求api接口不進行重定向

具體的charles配置以下圖所示：

注意上面map From中的Path配置項使用了*通配符，表示匹配127.0.0.1:8080/api/下的全部文件及子路徑，將其重定向到cmstest.intra.xiaojukeji.com下的/api/路徑下

上面的配置經過map Remote就是實現了區別對待本地系統的不一樣請求，將指定路徑下的請求重定向到指定的環境，配置完成後看到所捕獲的請求信息以下圖所示。

這說明配置已經生效，那麼本地開發，測試環境數據就能夠看到了，剩下的就能夠愉快的開發項目了，是否是超讚啊！

---

補充一下map隱射的相關功能

• map隱射可使用的模式匹配符有三種：

  1. *: 能夠匹配0個或者多個字符

  2. ?: 能夠匹配一個字符

  3. [...]: 範圍選擇符，能夠匹配範圍中的任意一個字符

• 假設Map From配置中的各個項爲空，表示匹配全部請求，而後Map To項的配置不一樣，表明不一樣含義，下表列出一個簡單例子

Host配置值	Path配置值	配置產生的結果
charlesproxy.com		匹配全部的請求重定向到charlesproxy.com主機
*.charlesproxy.com		匹配全部的請求重定向到以.charlesproxy.com結尾的主機
charlesproxy.com	/charles/	匹配全部請求只重定向到charlesproxy.com/charles/路徑下
charlesproxy.com	/charles/*	匹配全部請求只重定向到charlesproxy.com/charles/路徑下,包括路徑下的文件及其路徑的子路徑
charlesproxy.com	/charles	匹配全部請求只重定向到charlesproxy.com/charles下
charlesproxy.com	/index.html	匹配全部請求重定向到charlesproxy.com/index.html
	/charles/*.html	匹配全部請求重定向到任意主機下的以.html結尾的文件，該文件存放在主機的/charles/及其子目錄下

Rewrite功能

---

rewrite功能重寫對應的內容，主要能夠對某些匹配請求的header、host、url、path、query param、response status、body進行rewrite。

rewrite功能支持正則表達式的寫法，這是一個很是有用的功能；例如Math項的value正則式中的組捕獲項在Replace的value值中可使用$1~$n之類的捕獲組

Rewrite的具體設置規則步驟，能夠用下面一幅圖來講明：

上面map Rewrite中用127.0.0.1:8080/api/*下的全部接口替換成指定host下對應的/api/*路徑，而其餘接口不作處理，用rewrite一樣能夠實現

下面就rewrite設置規則內容頁面，就各項rewrite規則作一個簡單說明，指出其對應的做用及其使用場景：

• header：
  • 做用：能夠對請求或者響應的header內容進行操做，包括添加、修改及刪除。
  • 使用場景：在須要對header進行處理時用到，例如爲了用上某個環境數據，可能須要對應cookie，這時本地開發是能夠在請求的header中加上cookie信息；也能夠重寫響應header的信息

以下圖，在本地開發時，須要的某個環境中的數據api接口須要當前登陸用戶的登陸信息的cookie，本地環境沒有這些cookie，這時就須要添加須要cookie頭，以下圖所示，爲匹配的接口添加cookie相關的header：

• host: 主要是對請求進行host修改，以達到本地請求獲取指定host環境中的數據，常見於mock數據

• url:
  • 做用：修改url中某些部分，能夠用別的url進行替換或者url裁剪時間戳或者md5等
  • 使用場景：場景使用很是多，既能夠對host也能夠對path進行rewrite，能夠知足指定host下的請求重定向到其餘host下對應path下

• path: 主要rewrite path內容使用指定rewrite規則的path來響應指定的請求path，它能夠對paht進行裁剪

• query param:
  • 做用：能夠對param進行操做，包括修改、添加、刪除等
  • 使用場景：有時請求可能多傳遞了沒必要要的參數，這時能夠rewirte功能去掉多餘的參數；另外也能夠添加請求必須而暫時沒法提供的參數

• response status: 顧名思義就是對response的狀態碼進行rewrite；比方我想對一個指定頁面A的訪問重定向到另外一個頁面B，就能夠用到這個。以下圖：
  

• body：
  • 做用：對請求的響應內容作修改，通常是對某一個或幾個值進行rewrite，用新的值來替代返回的值
  • 使用場景：能夠用來mock數據，比方說在開發中爲了測試功能須要請求的某個數組字段有值，可是當前環境沒法給出，那麼就可使用該功能

---

參考文獻

• Charles輔助調試接口