這一次我掉進了Unirest的坑

 

路徑中的斜槓

　　咱們常見的網址如 http://www.cnblogs.com/aaa/bbb/1.html 是由多級的結構（目錄/文件夾）組成的，這裏關注的是其中的aaa和bbb，它們之間用斜槓(/)分隔。從最大自由度來說，每一級結構的名字是能夠隨意取的。既然名字能夠隨意取，並且上下級之間是用/來作分隔，那麼若是名字裏面有斜槓要怎麼辦呢？可能有人說Windows不容許啊，在Windows文件夾或者文件的名字裏面不能出現斜槓，在web是容許的。因爲斜槓在網址中表明上下級結構的分隔符，因此若是某一層的文件夾出現斜槓的話，必須進行轉碼。具體的這個斜槓就得轉成%2F，便是百分號後加2位十六進制表示的ASCII碼。因此%2F表明文件夾名字中的斜槓，不表明上下級文件夾的分隔。

Unirest是什麼？

　　如今軟件web化很是流行，並且多數是先後端分離，因此web API一般是給前端調的。但也存在一種可能，就是咱們本身寫一個軟件須要去訪問（調用）別人的web API。此時就須要一些組件封裝了HTTP協議，而後咱們就能夠方便地使用。這樣的組件不少，可是因爲HTTP協議比較複雜，因此實現這樣的組件要作到強大+易用，還真的不太容易。在衆多HTTP組件之中，Unirest就是可貴的封裝得很是好用的一套組件。

歷險過程

　　前段時間我寫一個程序須要去訪問其餘系統的web接口，網址大概長這樣：http://www.abc.com/one%2Ftwo/abc。一開始用了其餘的組件，調用接口的結果是下載一個文件，但下載的文件中文是亂碼，且文件不完整。因爲我對那套組件不熟，因此我就想到換爲我比較熟的unirest。因而去 https://mvnrepository.com/ 找了unirest的引用代碼，結果發現還不止一個。我也忘了之前是怎麼選擇的，因此就習慣性地採用那個排名第一的，也就是下載量最大的那個。估計之前也是用那個，之前也沒遇到什麼問題。三下五除二，說幹就幹，輕車熟路，一番噼裏啪啦，很快弄好了。

　　啓動機器調試。什麼？404（找不到文件資源）？我沒看錯吧？各類檢查，沒有發現緣由。把代碼中的網址複製到瀏覽器，結果401（未登陸）。由於我沒有傳送認證參數，401就是對的。我多麼想代碼也能獲得401，可他卻就是404！可是404是個很很差解決的問題。我知道，資源就在那裏，誰知道哪一個地方寫錯了呢。服務器就告訴你「找不到。至於哪裏寫錯了，不知道，你猜」。我進行了各類嘗試，也包括把%2F變直接變成斜槓去訪問服務器，給的回答是。項目不存在，狀態碼是200。事情陷入了僵局。

　　經同事提醒，使用了抓包工具。原來unirest真的「幫我」把%2F轉成斜槓了！好吧，既然你會幫我一次解碼，那我就編碼兩次，讓你解一次結果就恰好是對的。編解碼我仍是懂的。查了一下%的編碼是%25，因而我把網址變成這樣http://www.abc.com/one%252Ftwo/abc。程序運行，又是404！從抓包工具來看，……，此次他就乾脆不解碼了，你說氣不氣人？整我的又陷入了絕望。我那麼信賴的unirest，怎麼會出現這樣的bug？

　　接下來怎麼辦？我還能有其餘的選擇嗎？第一，其餘的組件我也不熟，出了問題更是難排查。第2，Unirest基本是業界最好的了，他都搞不定，其餘組件會更好嗎。

　　後來又通過各類排查，排查到了unirest的源頭，我又再次去了 https://mvnrepository.com/。看到了這一幕

這個時候我才發現，原來我使用的已經有好幾年不更新了，而那個一直有更新的下載量並非第一。總算又看到了一線但願，立刻下載來試這一次，問題解決了！！！他不會自動把網址中的2%F進行轉碼！

教訓啊

1. 使用unirest要留意你使用的是哪一個unirest。
2. 當遇到一些技術問題，走投無路的時候，能夠在各個分叉點進行嘗試。因此呢，在研發或選型的過程當中就要記錄這些分叉點。典型的就是有多種選擇的時候。

　　如今覆盤寫出來思路很清晰，可是人在事中時，是帶着混亂的。每每到了山窮水盡疑無路，而不知道哪裏有柳暗花明又一村。