最近在使用scrapy來製作爬蟲以爬取一些**上的資訊，但是卻出現了乙個很奇怪的問題，即在網頁中開啟待爬取的url，並在網頁源**中定位了某些待爬取的元素，但是當使用scrapy爬取資料時，卻發現報錯了，而錯誤竟然是所爬取到的網頁中並沒有我在瀏覽器中看到的元素，即對於同乙個url，爬取到的頁面和我在瀏覽器中開啟所看到的頁面不一樣！
在反覆確認css類選擇器沒寫錯，爬蟲所爬取的url沒有被重定向到另外的頁面後，我發現事情並不簡單。
而後我機緣巧合之下在不修改任何**的情況下重新執行了一遍，卻發現又爬取成功了，然後再試一次，又報錯了，這時候我就知道，肯定是爬取到的頁面是沒有載入完全的頁面了。
頁面沒載入完全的情況，我首先想到的有兩種可能：
其一，部分資料是在網頁載入中由js動態寫入的，即在第一次請求中部分資料傳給了js並由js在前端進行處理後再顯示到頁面上；
其二，便是網頁資料採用了非同步載入，在爬取網頁的時候部分資料還沒載入進來。
而基於scrapy是乙個成熟的爬蟲框架的考量，我想第一種情況應該不會出現，畢竟爬蟲完全可以等頁面初始化完成後再進行爬取，但是對於第二種情況卻無法預先控制，因為資料載入是非同步的。
基於如上考慮，那便直接考慮第二種情況，因此可以通過在瀏覽器控制台的network中檢視所有傳送的請求，檢視是否自己所需的資料是被非同步載入了。如下圖，可以對每一條請求的response進行檢視，手動檢視是否返回了自己所需的資訊。
對於我的情況，果不其然，如上圖所示，便被我找到了整個非同步請求的返回的json格式的資料，其中包含了所有我需要的資訊，我甚至不需要再去對網頁進行爬取，只需如下圖所示，檢視該請求的header，可以看到該非同步請求的請求格式，即圖中的request url
將獲得的request url複製到瀏覽新視窗中開啟，可以看到如下圖，能夠訪問到json格式的返回資料，這表明**並沒有對這種請求進行攔截，這也使得我不需要再去從頁面上爬取資料了，我只需直接構造相應的url然後分析返回的json資料即可，大功告成！
不完全的計算
在與一些年歲較大的c程式設計師接觸的過程中，可以比較明顯的感受到c的思維方式與物件導向思想的不同。c的世界很清澈，先做a,再做b,我們所期待發生的計算過程與源 的結構是直接一一對照的。這意味著程式將要執行的計算過程在編寫 的時刻就已經確定下來。物件導向首先需要確定的是類，物件等中間元素，而並不是最終...
jBPM Designer的不完全漢化
url 前些天，在群jbpm inside 25496693 裡和am大哥請教了關於jbpm designer的漢化問題，在am大哥的耐心指導和幫助下，我完成了對其不完全的漢化。在此，非常感謝am大哥的熱心和耐心，謝謝！好了，下面就開始漢化了 二 開啟目錄jbpm starters kit 3.1....
C 中的「不完全型別」
用delete刪除乙個只有宣告但無定義的型別的指標，是危險的。這通常導致無法呼叫析構函式 包括物件本身的析構函式 成員 基類的析構函式 從而洩露資源。示例 引用 class c 在另乙個cpp檔案中定義 c createc 在另乙個cpp檔案中定義 int main 初步分析 型別c沒有被定義，所以...