wget和curl在下載時以某種方式修改bencode文件

Question

好的，所以我有一個很奇怪的問題，我不確定如何解釋...基本上我正在嘗試解碼一個Bencode文件（.torrent文件），現在我已經嘗試了4種或5種不同的腳本通過Google和SO找到運氣不佳（在非字典中得到這樣的返回，或者從同一個輸出錯誤）

現在我像這樣下載.torrent文件

wget http://link_to.torrent file  
 //and have also tried with curl like so 
curl -C - -O http://link_to.torrent

並得出結論，當我以這種方式下載時，文件中發生了某些事情。 原因是我發現此站點將解碼您在線上載的.torrent文件，以顯示文件中包含的信息。 但是，當我不僅通過瀏覽器單擊鏈接而是使用上述方法之一下載.torrent文件時，它也不起作用。 那么，有沒有人使用這些方法之一遇到過類似的問題，找到了解決問題的方法，甚至解釋了為什么會這樣？ 據我所知，我在網上找不到太多信息，也不知道可以用於我的服務器的解決方法

更新：好的，正如@ coder543建議的那樣，比較通過瀏覽器和wget下載的文件大小。 使用wget樣式時它們的大小不相同，因此文件大小較小，因此很明顯問題是wget & curl沒有其他問題。

Updat 2：好的，所以我現在已經嘗試了幾次，並且將問題縮小了一點，問題似乎只出現在torcache和torrage鏈接上。 來自其他站點的鏈接似乎正常運行或按預期運行...因此，以下是一些鏈接，我通過以下三種方法得出的結果：

   *** differnet sizes***
 http://torrage.com/torrent/6760F0232086AFE6880C974645DE8105FF032706.torrent
   wget -> 7345 , curl -> 7345 , browser download -> 7376

 *** same size***
 http://isohunt.com/torrent_details/224634397/south+park?tab=summary
 wget -> 7491 , curl -> 7491 , browser download -> 7491

 *** differnet sizes***
 http://torcache.net/torrent/B00BA420568DA54A90456AEE90CAE7A28535FACE.torrent?title=[kickass.to]the.simpsons.s24e12.hdtv.x264.lol.eztv
 wget -> 4890 , curl-> 4890 , browser download -> 4985

  *** same size***
 http://h33t.com/download.php?id=cc1ad62bbe7b68401fe6ca0fbaa76c4ed022b221&f=Game%20of%20Thrones%20S03E10%20576p%20HDTV%20x264-DGN%20%7B1337x%7D.torrent 
  wget-> 30632 , curl -> 30632 , browser download -> 30632

  *** same size***
 http://dl7.torrentreactor.net/download.php?id=9499345&name=ubuntu-13.04-desktop-i386.iso
 wget-> 32324, curl -> 32324, browser download -> 32324

 *** differnet sizes***
http://torrage.com/torrent/D7497C2215C9448D9EB421A969453537621E0962.torrent
wget -> 7856 , curl -> 7556 ,browser download -> 7888

因此，我似乎在某些網站上運行良好，但實際上是在torcache.net和torrage.com上提供文件的網站。 現在，如果我可以直接使用其他站點而不直接依賴緩存的話，那就好了，但是我正在使用bitsnoop api（它將所有數據從torrage.com中拉出，因此這並不是一個選擇），如果有人有任何想法的話關於如何解決此問題或為找到解決方案而采取的步驟，將不勝感激！

即使任何人都可以復制結果，也將不勝感激！ ...我的服務器是64位體系結構上的12.04 LTS，我嘗試進行實際下載比較的筆記本電腦是相同的

Answer 1

對於使用命令行工具檢索的文件，我得到：

$ file 6760F0232086AFE6880C974645DE8105FF032706.torrent
6760F0232086AFE6880C974645DE8105FF032706.torrent: gzip compressed data, from Unix

可以肯定的是，使用gunzip解壓縮將產生正確的輸出。 查看服務器發送的內容，會得出有趣的線索：

$ wget -S http://torrage.com/torrent/6760F0232086AFE6880C974645DE8105FF032706.torrent
--2013-06-14 00:53:37--  http://torrage.com/torrent/6760F0232086AFE6880C974645DE8105FF032706.torrent
Resolving torrage.com... 192.121.86.94
Connecting to torrage.com|192.121.86.94|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 200 OK
  Connection: keep-alive
  Content-Encoding: gzip

因此服務器確實報告它正在發送gzip壓縮數據，但是wget和curl忽略了這一點。 curl具有--compressed開關，它將為您正確解壓縮數據。 即使對於未壓縮的文件，這也應該是安全的，它只是告訴http服務器客戶端支持壓縮，但是在這種情況下，curl會查看接收的標頭以查看它是否真正需要解壓縮。