使用fiddler抓取不到瀏覽器的包時常用的解決辦法：
1.必須先打開Fiddler，再打開瀏覽器
2.Fiddler只能截取網頁與服務器間的通信，無法截取游戲封包
3.Fiddler沒有打開捕捉模式
其他問題的解決方法：
1、這種是chrome瀏覽器抓不到的情況：實際上fiddler是可以抓chrome的請求的。
由於可能chrome安裝了代理管理的插件SwitchySharp，無論選擇直接連接還是選擇使用代理連接，插件都會屏蔽fiddler的設置。
fiddler會自動給瀏覽器設置一個代理127.0.0.1 端口8888，並且記憶瀏覽器的代理設置，所有的請求先走fiddler代理，再走瀏覽器代理。
如果使用插件，可能會直接屏蔽了fiddler的代理，因此無法監聽到請求了。
chrome下的解決方法，代理插件選擇“使用系統代理設置”選項，fiddler又重新能看到chrome的請求了。
或者不使用插件，不用卸載，chrome很方便禁用一個插件。然后使用瀏覽器默認的代理設置方式就ok了。
使用代理插件是為了方便切換代理，但是可能會導致fiddler等工具無法使用。正所謂魚和熊掌不可兼得。
2、還有就是可能是某個進程導致的，通常我們會到任務管理器中找，這里是個藏污納垢的地方，里面會發現好多的問題，你可以嘗試着把跟系統無關的進程都關掉，一個一個排查，看可能是哪里有問題。先這么多，后面如果有新的問題，再更新。
3、還有一種情況是用了一款叫做adsafe的軟件，可以屏蔽掉所有的廣告。把他關掉之后就可以抓包了。分析了以下原因可能是這款軟件權限比較高，就和殺毒軟件一樣，可以接管你所有的流量。所以，fiddler就不能正常的抓到你所有的包了。直接用任務管理器把這個程序進程殺掉就好了。
ASCII碼對照表|ASCII編碼_911查詢 http://ascii.911cha.com/
10，0A，換行鍵，LF
13，0D，回車鍵，CR
HTTP報文是簡單的格式化數據塊。看一下圖3-3給出的例子。每條報文都包含一條來自客戶端的請求，或者一條來自服務器的響應。它們由三個部分組成：對報文進行描述的起始行（start line）、包含屬性的首部（header）塊，以及可選的、包含數據的主體（body）部分。
起始行和首部就是由行分隔的ASCII文本。每行都以一個由兩個字符組成的行終止序列作為結束，其中包括一個回車符（ASCII碼13）和一個換行符（ASCII碼10）。這個行終止序列可以寫做CRLF。需要指出的是，盡管HTTP規范中說明應該用CRLF來表示行終止，但穩健的應用程序也應該接受單個換行符作為行的終止。有些老的，或不完整的HTTP應用程序並不總是既發送回車符，又發送換行符。
實體的主體或報文的主體（或者就稱為主體）是一個可選的數據塊。與起始行和首部不同的是，主體中可以包含文本或二進制數據，也可以為空。
在圖3-3的例子中，首部給出了一些與主體有關的信息。Content-Type行說明了主體是什么——在這個例子中，就是純文本文檔。Content-Length行說明了主體有多大，在這里就只有19個字節。
所有的HTTP報文都可以分為兩類：請求報文（request message）和響應報文（response message）。請求報文會向Web服務器請求一個動作。響應報文會將請求的結果返回給客戶端。請求和響應報文的基本報文結構相同。
HTTP請求報文中包含命令和URL
HTTP響應報文中包含了事務的結果
這是請求報文的格式：
<method> <request-URL> <version>
<headers>
<entity-body>
這是響應報文的格式（注意，只有起始行的語法有所不同）：
<version> <status> <reason-phrase>
<headers>
<entity-body>
下面是對各部分的簡要描述。
3.3.3 HEAD
HEAD方法與GET方法的行為很類似，但服務器在響應中只返回首部。不會返回實體的主體部分。這就允許客戶端在未獲取實際資源的情況下，對資源的首部進行檢查。使用HEAD，可以：
在不獲取資源的情況下了解資源的情況（比如，判斷其類型）； •
通過查看響應中的狀態碼，看看某個對象是否存在； •
通過查看首部，測試資源是否被修改了。 •
服務器開發者必須確保返回的首部與GET請求所返回的首部完全相同。遵循HTTP/1.1規范，就必須實現HEAD方法。圖3-8顯示了實際的HEAD方法。
3.3.4 PUT
與GET從服務器讀取文檔相反，PUT方法會向服務器寫入文檔。有些發布系統允許用戶創建Web頁面，並用PUT直接將其安裝到Web服務器上去（參見圖3-9）。
3.3.5 POST
POST方法起初是用來向服務器輸入數據的3。實際上，通常會用它來支持HTML的表單。表單中填好的數據通常會被送給服務器，然后由服務器將其發送到它要去的地方（比如，送到一個服務器網關程序中，然后由這個程序對其進行處理）。圖3-10顯示了一個用POST方法發起HTTP請求——向服務器發送表單數據——的客戶端。
3.3.6 TRACE
客戶端發起一個請求時，這個請求可能要穿過防火牆、代理、網關或其他一些應用程序。每個中間節點都可能會修改原始的HTTP請求。TRACE方法允許客戶端在最終將請求發送給服務器時，看看它變成了什么樣子。
TRACE請求會在目的服務器端發起一個“環回”診斷。行程最后一站的服務器會彈回一條TRACE響應，並在響應主體中攜帶它收到的原始請求報文。這樣客戶端就可以查看在所有中間HTTP應用程序組成的請求/ 響應鏈上，原始報文是否，以及如何被毀壞或修改過（參見圖3-11）。
3.5.2 請求首部
請求首部是只在請求報文中有意義的首部。用於說明是誰或什么在發送請求、請求源自何處，或者客戶端的喜好及能力。服務器可以根據請求首部給出的客戶端信息，試着為客戶端提供更好的響應。表3-13列出了請求的信息性首部。
表3-13 請求的信息性首部
首 部 描 述
Client-IP 提供了運行客戶端的機器的IP地址
From 提供了客戶端用戶的E-mail地址
Host 給出了接收請求的服務器的主機名和端口號
Referer 提供了包含當前請求URI的文檔的URL
UA-Color 提供了與客戶端顯示器的顯示顏色有關的信息
UA-CPU 給出了客戶端CPU的類型或制造商
UA-Disp 提供了與客戶端顯示器（屏幕）能力有關的信息
UA-OS 給出了運行在客戶端機器上的操作系統名稱及版本
UA-Pixels 提供了客戶端顯示器的像素信息
User-Agent 將發起請求的應用程序名稱告知服務器
參考資料：http://blog.csdn.net/sufubo/article/details/49331705
【Fiddler】使用fiddler抓取指定瀏覽器的包 - Lauren - 博客園 https://www.cnblogs.com/lauren1003/p/6519630.html
《HTTP權威指南》([美]David Gourley，[美]Brian Totty，[美]Marjorie Sayer，[美]Sailu Reddy，[美]Anshu Aggarwal)【摘要 書評 試讀】- 京東圖書 https://item.jd.com/11056556.html
百度搜索url編碼解密(url encode decode) - 程序員大本營 http://www.pianshen.com/article/236199113/
百度搜索結果中的URL是如何加密的？-CSDN論壇 https://bbs.csdn.net/topics/392175054?page=1