手把手教你如何利用工具(IE9的F12)去分析模擬登陸網站(百度首頁)的內部邏輯過程

出處:http://www.crifan.com/use_ie9_f12_to_analysis_the_internal_logical_process_of_login_baidu_main_page_website/

【前提】

想要實現使用某種語言，比如Python，C#等，去實現模擬登陸網站的話，首先要做的事情就是使用某種工具，去分析本身使用瀏覽器去登陸網頁的時候，其內部的執行過程，內部邏輯。

此登陸的邏輯過程，主要指的是，需要訪問哪些地址，提交哪些http請求，其中包含了有哪些查詢關鍵字，涉及到哪些post的數據，涉及到哪些cookie等等。

只有知道了內部邏輯過程，才能談及，使用某種語言去實現，模擬，此套登陸網站的過程。

關於分析工具，其實有很多種，此處選用，之前在

【總結】瀏覽器中的開發人員工具（IE9的F12和Chrome的Ctrl+Shift+I）-網頁分析的利器

所介紹的IE9的F12。

在分析之前,雖然不需要你有太多的網絡相關的基礎，但是，如果真正想要熟悉分析網站抓取，模擬網站登陸的話，還是需要了解相關的知識的。

其中，和cookie相關的內容，可參考：

【總結】關於Http的Cookie的一些知識

【經驗總結】Http，網頁訪問，request，response相關的知識

【使用IE9的F12分析登陸百度首頁的內部邏輯過程】

1.準備好工具，配置好工具

打開IE9，打開百度首頁：

http://www.baidu.com/

按F12，調出F12工具，再切換到Network界面：

然後點擊“Start capturing”開始調試：

下面就來利用F12來調試，分析登陸的內部邏輯。

不過，在調試之前，先去做一些配置上的準備工作：

（1）設置網頁跳轉時，已抓取的數據不被清除掉

即設置：

Tools -> Clear entries on navigate中的Console和Network，都取消掉：

這樣，在網頁分析過程中，由於從一個頁面跳轉到另外一個頁面，所抓取的到內容，就不會被清空掉了。

（2）清除舊的cookie和緩存

爲了後續的調試，不被之前的已登陸的賬戶的（緩存和cookie等）信息所影響，所以去都清除掉：

其中，簡單解釋一下是：

A。2個和清除cookie有關的：

Cache->Clear session cookies:清除當前會話，即訪問當前這麼一堆網頁所涉及的cookie

Cache->Clear cookies for domain:清楚和當前網頁所屬的domain，此處爲.baidu.com相關的cookie；

B。2個和緩存cache有關的

另外，爲了清除的更徹底，往往也順帶把cache，即緩存的網頁，也順帶都清理了：

Cache->Clear browser cache

Cache->Clear browser cache for this domain

更多關於F12如何使用的事情，還是去參考之前所寫的：

【總結】瀏覽器中的開發人員工具（IE9的F12和Chrome的Ctrl+Shift+I）-網頁分析的利器

接下來的所有操作，實際上就是，在IE9中，手動操作一遍，登陸百度首頁的過程而已。

2.模擬操作過程，利用工具抓取所需的整個過程

點擊“登陸”：

可以看到，除了網頁中跳出你所熟悉的登陸對話框之外，F12調試窗口中，就已經抓取到很多內容了。

然後輸入用戶名和密碼，正常登陸：

然後，就可以看到網頁調轉到了：

http://www.baidu.com/index.php

以及，對應的抓取到了很多內容：

好了，到此爲止，我們的操作，基本就結束了。

剩下的，就是從我們所已經抓取到的信息中，找到是如何登陸的。

3.分析網站登陸的內部邏輯過程

3.1找到登陸網站所涉及的最核心的地址

對於熟悉的人，可以直接從那一堆的url中，找到哪個是登陸的頁面。

而現在假定你不熟悉，教你如何找到真正的有價值的信息。

對於此處，我們可以想到的一種辦法是，通過直接搜索密碼，而搜到哪裏發送了我們的密碼：

【小提示：顯示內容時，設置爲自動換行】

當抓取出來的Request Body，Response Body等部分的內容中，單行內容太長，一行顯示不下，不方便查看時，可以點擊右鍵，選擇Word wrap：

即可實現自動換行顯示的效果了，方便查看了：

此處，很容易看到，此處和我們密碼相關的url地址爲：

https://passport.baidu.com/v2/api/?login

即，以後如果想要寫代碼的話，所要訪問的url地址，就是這個地址了。

3.2分析所提交的數據（post data）中的參數和值

而且，此處的Request Body，就是對應的http的POST請求中所要提交的數據，簡稱爲post data。

此處Request Body中完整的數據爲（注：以下數據，是另外一次分析出來的結果，對解釋分析過程無影響）：

ppui_logintime=6852&charset=utf-8&codestring=&token=5ab690978812b0e7fbbe1bfc267b90b3&isPhone=false&index=0&u=&safeflg=0&staticpage=http%3A%2F%2Fwww.baidu.com%2Fcache%2Fuser%2Fhtml%2Fjump.html&loginType=1&tpl=mn&callback=parent.bdPass.api.login._postCallback&username=crifan&password=xxxxxx&verifycode=&mem_pass=on

然後處理一下就是：

ppui_logintime=6852&
charset=utf-8&
codestring=&
token=5ab690978812b0e7fbbe1bfc267b90b3&
isPhone=false&
index=0&
u=&
safeflg=0&
staticpage=http%3A%2F%2Fwww.baidu.com%2Fcache%2Fuser%2Fhtml%2Fjump.html&
loginType=1&
tpl=mn&
callback=parent.bdPass.api.login._postCallback&
username=crifan&
password=xxxxxx&
verifycode=&
mem_pass=on

再去掉後面的那個&字符，變爲：

ppui_logintime=6852
charset=utf-8
codestring=
token=5ab690978812b0e7fbbe1bfc267b90b3
isPhone=false
index=0
u=
safeflg=0
staticpage=http%3A%2F%2Fwww.baidu.com%2Fcache%2Fuser%2Fhtml%2Fjump.html
loginType=1
tpl=mn
callback=parent.bdPass.api.login._postCallback
username=crifan
password=xxxxxx
verifycode=
mem_pass=on

很明顯，此處就是模擬網站登錄的核心數據了，是在寫代碼時，對於

url=https://passport.baidu.com/v2/api/?login

提交POST請求時，所以要發送的一些參數和值了。

此處，再重新簡要的介紹一下，模擬登陸網站的基本邏輯：

想要模擬網站登陸，就要知道，要向什麼url地址，發送什麼樣的數據，GET請求還是POST請求。

GET請求只從服務器請求數據，不需要所謂的post data，但是往往需要在url後面添加上對應的?para1=val1&para2=value2之類的形式，此部分叫做query parameter，其本質上，有點類似於post data；
POST請求，在發送請求時，還需要提供對應的post data，此處即對應着IE9的F12中的Request Body。
- 而餘下的，發送請求時的其他相關參數設置，主要就是設置很多基本的參數，包括user-agent等，此處對應着那個Request Headers

而提交請求後，網站的服務器會給你反饋，返回數據和信息給你。

此處對應的就是Response Headers和Response Body。

經常地，其中還涉及到cookie等信息。在發送之前，準備好，發送給服務器，服務器返回的信息中，往往也包含，更新後，cookie的值。

對應的這部分內容，是Cookies部分。

此處，把所有的內容，分別截圖如下：

Request Headers

Request Body：

Response Headers：

Response body:

Cookies:

接下來，就是分析，如何獲得所需的信息。

先分析上述的post data中的值：

都是怎麼來的。

分析值是如何來的，以及順帶說說，寫代碼時，如何設置這些值。

在此之前，先解釋一下，在代碼中關於如何設置這些參數的值的規律和經驗：

（1）對於有參數，但是值爲空的哪些參數，一般來說，都是可以省略的。

即寫代碼時，是可以去掉，忽略掉，這些參數的；

當然，如果你抓取出來的參數是有值的，則需要考慮其值是怎麼得到的，是否有意義，否則隨便忽略掉某些參數，可能會導致模擬登陸失敗的。

（2）對於，看不太懂的參數的值的情況下，不妨先使用抓取出來的數據

尤其是一些參數，看不太懂，而且其值又明顯不是那種，很可能會變化的數字之類的值，則一般情況下，也都是固定的值，所以，即使對於參數和值本身不太瞭解，也無所謂，也都可以直接在代碼中，直接使用抓取出來的數據即可。

即使會導致出錯，一般來說，也可以通過後續的多次抓取和分析，看出來該值真正的規律。

在上面那一堆參數和值中：

（1）一些很明顯，是固定的值，不需要考慮太多的值有：

charset=utf-8 -> 表示當前網頁的編碼是utf-8，我們寫代碼照着寫即可，不需要改；

codestring= ->此處爲空，所以也可以不理會；

isPhone=false -> 很明顯，此處是通過PC登陸百度的，不是通過手機類的移動設備登陸的，所以是false。所以寫代碼時，也設置爲false即可；

細心的讀者，也很容易回想起，此處是對應着之前的登陸界面中的“手機登陸”：

如果是我們是通過“手機登陸”百度時，不出意外的話，肯定參數是isPhone=true

index=0 -> 未知，但是也沒看出來是什麼含義，所以也直接設置爲0即可；

u=-> 空值，同樣設置空值即可；

safeflg=0 -> 未知，所以也可以暫且不管，同樣設置爲0即可。

username=crifan -> 很明顯，是我們的賬號，不多解釋；
password=xxxxxx -> 同理，是對應的密碼；
verifycode= ->此處爲空，所以也可以不管；
mem_pass=on -> 很明顯，是memory password的所寫，即記住密碼，對應的頁面是，我們已經勾選的"記住我的登陸狀態"：

（2）另外一些就是不太容易一眼就看出來的值，需要簡單解釋一下的：

staticpage=http%3A%2F%2Fwww.baidu.com%2Fcache%2Fuser%2Fhtml%2Fjump.html ->

此處，等有了一定的調試經驗，和本身具有一定的url的encode，decode基礎的話，可以直接看出來，這個值

http%3A%2F%2Fwww.baidu.com%2Fcache%2Fuser%2Fhtml%2Fjump.html

是原先某個url地址，編碼之後的值。

而對應的原始的值，可以在代碼中去解碼而獲得；

此處先直接給出原始值：

http://www.baidu.com/cache/user/html/jump.html

關於如何通過此，被編碼的url地址中，獲得原始的url地址，詳細解釋在這裏：

【整理】關於http(GET或POST)請求中的url地址的編碼(encode)和解碼(decode)

loginType=1 -> 未知，但是一般不知道的值，都可以先按照原先的值去設置即可；

tpl=mn -> 未知，也還是同樣設置即可；

callback=parent.bdPass.api.login._postCallback -> 未知，也同樣設置即可；

（3）再剩下的，就是需要去分析調查，才知道爲何是這樣值的了：

ppui_logintime=6852

此值6852，看起來就像是會變化的。但是到底如何得到的，則需要去分析分析了。

所以就去搜索6852：

經過搜索，發現結果只能搜到此單獨一處的6852，貌似沒辦法找到此數據如何得到的。

但是，我們可以再去搜其參數ppui_logintime，然後另外在別的文件中也可以找到2處，其中一處是：

很明顯，此處是javascript腳本：

https://passport.baidu.com/js/pass_api_login.js?v=20121018

在其中根據實際情況計算出來的。

【小提示：對於參數的處理策略】

對於涉及的很多參數，總的說，有兩種策略：

一是，直接忽略此值，暫時不管。因爲很多時候，有些參數，至少是這樣看起來，不是那麼重要的參數（重要的參數，相信我不說你自己也能看出來，是那些username，password之類的參數）。

然後就去寫程序去模擬了。而真的等到程序運行出錯，服務器沒有返回你所期望的信息的時候，再回來分析此參數，看看是不是這個參數所導致的。

然後再試圖去分析其真正的值；

二是，繼續分析，甚至調試javascript代碼，以便找到此值到底是如何一點點計算出來的。此過程可能會極其繁瑣，也可能相對簡單。要取決於此值被計算出來所經歷的過程的複雜度。

此處，在表面看起來，這個參數ppui_logintime，大概意思是登陸的時間，所以推測是服務器爲了記錄你本地登陸百度的時間，和能否登陸百度這個過程本身，應該不會產生根本的影響，所以此處就可以採用策略一，暫時忽略不管。

萬一真的有影響，再回來繼續分析也不遲。

token=5ab690978812b0e7fbbe1bfc267b90b3 ->

此值5ab690978812b0e7fbbe1bfc267b90b3，很明顯，是需要從別的地方找到的。所以就去分析此值是如何來的。

同理，繼續去搜5ab690978812b0e7fbbe1bfc267b90b3，然後是可以搜到的，然後通過點擊搜索框中的向前和向後的按鈕，是可以找到這個

2/68 條記錄，對應url是：

https://passport.baidu.com/v2/api/?getapi&class=login&tpl=mn&tangram=true

的這處的：

【小提示：在兩種視圖模式：Detailed View和Summary View之間切換】

對應的，可以通過點擊“Back to summary view”，而更加清楚的看到，是哪條記錄，以及對應的視圖模式中，顯示出：

Go to detailed view

對於上述所搜到的內容，很明顯可以看出，就是我們在通過網頁登陸百度首頁過程中，通過IE9的F12抓取出來的記錄知道了，其內部還是會先去訪問：

https://passport.baidu.com/v2/api/?getapi&class=login&tpl=mn&tangram=true

然後會獲得Response Body，即（服務器所返回的）html源碼，其中包括了：

1	`bdPass.api.params.login_token='5ab690978812b0e7fbbe1bfc267b90b3';`

的，此時，你應該就明白了，到時候我們去寫代碼時，想要獲得上述token的值的話，就需要先去

對於

url=https://passport.baidu.com/v2/api/?getapi&class=login&tpl=mn&tangram=true

發送GET請求，獲得對應的html代碼，然後從中分析出token的值5ab690978812b0e7fbbe1bfc267b90b3；

而寫到此，基本邏輯過程，也相對清楚了。

但是有人很快會想到，即使上述代碼寫出來了，又如何能確保的確已經模擬登陸成功了，即如何驗證此處模擬登陸百度首頁成功了呢？

此處，根據經驗，主要通過兩方面來驗證：

【小提示：如何驗證模擬登陸網站已成功】

一是返回的html代碼

返回的html代碼，即對應着F12中的Response Body，此處爲截圖如下：

如果你登陸成功了，那麼代碼中所獲得的返回的html中，至少也應該是類似的html了。

二是cookie

如果你成功登陸了服務器，那麼其所返回的值中中，對於cookie，一般都是會有對應的，和成功登陸有關的新的cookie返回給你的，以及另外更新一些原先發送的一些cookie的值。

此處F12中的Cookies的截圖如下：

很容易看出，當登陸成功後，會返回那一堆的cookie，拷貝出來如下：


Direction  
Key Value   Expires Domain  Path    Secure  HTTP only

Received   
BDUSS   WpNYWFNSGFub0t6YU9PMW1tVzNIUGRya35TQk5pM0JnflI2fndrT3UtQmdESVpSQVFBQUFBJCQAAAAAAAAAAAoavCuy1YMAY3JpZmFuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAYIArMAAAALDmT5YqAAAA6p5DAAAAAAAxMC4yNi4xOWC-mFBgvphQM    Sat, 23-Jan-2021 07:38:08 GMT   baidu.com   /   No 
No

Received   
PTOKEN  b42a396ff9c7efb80c08beecd040f032    Sat, 23-Jan-2021 07:38:08 GMT   passport.baidu.com  /   No  No

Received   
STOKEN  f38612b7866cfb0357877b8ca3c4faa6    Sat, 23-Jan-2021 07:38:08 GMT   passport.baidu.com  /   No  No

Received   
PTOKEN  deleted Mon, 07-Nov-2011 07:38:07 GMT   baidu.com   /   No  No

Received   
SAVEUSERID  345baf769053e0ed4234    Sat, 23-Jan-2021 07:38:08 GMT   passport.baidu.com  /   No  No

而當代碼模擬登陸成功後，則也肯定會收到類似的cookie的。

【小提示：關於cookie，需要注意的事情】

此處，需要特別提示一句，如果你在最開始沒有去清除cookie，則很可能看到的cookie結果是這樣的：

即，登陸前後的cookie，都有BDUSS，PTOKEN，STOKEN，SAVEUSERID。

這是因爲，之前通過別的賬號，以及同樣的賬號crifan，登陸過，所以IE9已經在本地記錄了相關的cookie。

所以，在訪問該url時，能看到Sent中已經存在了類似的cookie。

所以，總的來說，可以通過返回的html和cookie，來驗證是否登錄成功了。

而一般來說，通過驗證cookie，是最有效的。因爲很多時候，某些網站登陸成功和登陸失敗，所顯示的頁面可能是同一個；

但是登陸成功的話，基本都會有對應的，新的，和登陸有關的cookie，返回的。

一般來說，實際上，對於很多不是很複雜的網站，到這一步，就完全就夠了，就能夠成功模擬登陸了。

但是，後來經過代碼的證實，如上的流程，實際上是行不通的，因爲對於去訪問：

https://passport.baidu.com/v2/api/?getapi&class=login&tpl=mn&tangram=true

實際上，返回的html是：


var
bdPass=bdPass||{};

bdPass.api=bdPass.api||{};

bdPass.api.params=bdPass.api.params||{};

bdPass.api.params.login_token='the
fisrt two args should be string type:0,1!';

        bdPass.api.params.login_tpl='mn';

                        document.write('<script
type="text/javascript" charset="UTF-8" src="https://passport.baidu.com/js/v2ApiUsedTangramFunctions.js?v=20121018"></script>');

                document.write('<script
type="text/javascript" charset="UTF-8" src="https://passport.baidu.com/js/pass_api_login.js?v=20121018"></script>');

其中的：

bdPass.api.params.login_token=’the fisrt two args should be string type:0,1!’;

是無法正確獲得我們所需要耳朵token的值的。

所以，接下來，就是繼續去想辦法，找到此處沒有正確獲得返回的html的原因。

不過，首先要知道的，無論何時，從抓取出來的數據來看，只要你程序是完整模擬了整個瀏覽器所發送的所有的數據，此處即IE9所發送的request headers：

和post data（Request body），此處爲空：

那麼，程序所獲得的返回值，就應該也和所抓取到的數據一樣，即應該就可以從返回的html（response body）中獲得所需的token的值了。

而此處之所有沒有獲得，對照上述所抓取的數據去看，則很可能是，request headers中某些值，比如cookie值，referer等值，沒有賦值正確，導致返回的html不對。

所以，接下來，就是想辦法，嘗試一點點，完全找到上那些cookie的值，referer等的值，都是從哪裏來的。

具體尋找的辦法，其實還是那些笨辦法，就是去搜索，然後一點點找線索，對於某個值，最初是哪裏獲得的。

好的，現在接着就以其中一個最複雜的cookie：SAVEUSERID，來說明，到底是如何分析出來的，找到最開始的SAVEUSERID是從哪裏來的：

不過，此部分內容，相對比較複雜，所以單獨寫到這裏了：

【教程】如何利用IE9的F12去分析網站登陸過程中的複雜的（參數，cookie等）值（的來源）

最終，才分析出來，SAVEUSERID是通過訪問：

https://passport.baidu.com/v2/api/?login

而獲得的。

而相應的，訪問https://passport.baidu.com/v2/api/?login之前，需要用到BAIDUID。

所以又用同樣的分析方法，去找到BAIDUID這個cookie的最開始的來源（又重新打開瀏覽器，重新分析了一次）：

因此，即爲：

先訪問：

http://www.baidu.com/

去獲得對應的BAIDUID，接着去訪問：

https://passport.baidu.com/v2/api/?login

其中發送的數據中，包括BAIDUID，返回數據中，得到SAVEUSERID。

而此時，其實訪問

https://passport.baidu.com/v2/api/?login

本身就是我們所追求的目標，模擬登陸百度。

所以後續的SAVEUSERID，其實此處是可以不用，只是去通過校驗cookie，而驗證登陸是否成功時，會涉及到而已。

然後再去回頭看之前所說的：

https://passport.baidu.com/v2/api/?getapi&class=login&tpl=mn&tangram=true

再次重現抓取所看到的結果爲：

就容易看懂了，即需要在訪問：

https://passport.baidu.com/v2/api/?getapi&class=login&tpl=mn&tangram=true

時，提供BAIDUID這個cookie。

另外，再確認一下，訪問：

https://passport.baidu.com/v2/api/?login

正確登陸時，所返回的cookie：

其中的cookie的詳細的值爲：


Direction  
Key Value   Expires Domain  Path    Secure  HTTP only

Sent   
BAIDUID D612E3728B8647FB61867F6A7FB9D9CD:FG=1                  

Received   
BDUSS   lxMkVCTHNMUlljSk9ERXgtNjZoZ3Q0S2tZbHBvUDFBSzZOUmk3ZHhza1JNSVpSQVFBQUFBJCQAAAAAAAAAAApRIA6y1YMAY3JpZmFuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAYIArMAAAALA2xXUAAAAA6p5DAAAAAAAxMC4yNi4xORHimFAR4phQbW    Sat, 23-Jan-2021 10:10:25 GMT   baidu.com   /   No 
No

Received   
PTOKEN  44cd9fe37e3f4a3a14811cc9ac0e0bf1    Sat, 23-Jan-2021 10:10:25 GMT   passport.baidu.com  /   No  No

Received   
STOKEN  9f262998a4613536bfdaa41f08f54f62    Sat, 23-Jan-2021 10:10:25 GMT   passport.baidu.com  /   No  No

Received   
PTOKEN  deleted Mon, 07-Nov-2011 10:10:24 GMT   baidu.com   /   No  No

Received   
SAVEUSERID  345baf769053e0ed4234    Sat, 23-Jan-2021 10:10:25 GMT   passport.baidu.com  /   No  No

可見，其中至少包括：

BDUSS，PTOKEN，STOKEN，SAVEUSERID

（其中，對於原先域名爲baidu.com的PTOKEN，是被刪除掉的，此處暫可忽略）

3.3 總結出模擬登陸網站的基本流程

至此，對於想要模擬登陸百度首頁：

http://www.baidu.com/

的內部邏輯過程，基本上就很清楚了：

順序	訪問地址	訪問類型	發送的數據	需要獲得/提取的返回的值
1	http://www.baidu.com/	GET	無	返回的cookie中的BAIDUID
2	https://passport.baidu.com/v2/api/?getapi&class=login&tpl=mn&tangram=true	GET	包含BAIDUID這個cookie	從返回的html中提取出token的值
3	https://passport.baidu.com/v2/api/?login	POST	一堆的post data，其中token的值是之前提取出來的	需要驗證返回的cookie中，是否包含BDUSS，PTOKEN，STOKEN，SAVEUSERID

【小提示：分析模擬登陸時，未必非得要完全搞懂和在代碼中用到所有的參數】

對於上述流程，按理來說，去使用代碼，Python或C#等，去實現出來，即可。

不過，關於模擬登陸時所需要的數據，多解釋一下。

按理來說，完整的模擬網站登陸的話，其實應該是從頭到尾的，分析出瀏覽器（IE9）本身是如何訪問網站的，然後把所有的邏輯搞懂，數據的來源都分析清楚，即如上述過程，對於訪問

https://passport.baidu.com/v2/api/?login

所需要的那麼一堆參數，都去搞懂具體的含義，以及參數的值，是怎麼獲得的。

而實際上，很多時候，模擬網站登陸，或者是抓取網頁信息的時候，只需要最關心的那些核心參數即可。

因爲，服務器，很可能，只是去判斷那些核心參數，比如上述的username，password，及其他幾個參數，

然後就可以正確返回你所需要的信息，即html，cookie等，就可以成功實現模擬登陸的目的了。

但是，話說回來，具體需要哪些，最基本的參數，還是需要通過寫程序，去一點點測試出來的。

而之所以給大家介紹上述的概念，目的是爲了，在你覺得自己能看懂參數的大概含義的時候，很多時候，能看出該參數不要也無所謂的時候，那就可以先去測試基本的參數，而暫時忽略其他相對次要的參數。

由此，在一定程度上，提高做事情的效率而已。

當然，在忽略參數的時候，也要注意，不要輕易忽略很多參數，否則也是很可能影響到程序模擬登陸的正確性的。

具體的尺度的把握，就一點：根據情況而定，自己看着辦。

【總結】

至此，關於模擬登陸網站，如何一步步的分析出內部邏輯過程，就完成了。

總結下來就是，先去用工具“錄製”你所有的操作，然後再去利用工具去分析和登陸有關那些url的相關的信息，主要是post data有哪些參數，以及其值是如何獲得的。

模擬登陸網站的內部邏輯過程分析完畢後，就可以去通過代碼去實現了：

【教程】模擬登陸網站之 Python版

手把手教你如何利用工具(IE9的F12)去分析模擬登陸網站(百度首頁)的內部邏輯過程

關於遊戲付費的一點想法

我通過CKA和CKS啦！

《最新出爐》系列入門篇-Python+Playwright自動化測試-42-強大的可視化追蹤利器Trace Viewer

大數據怎麼學？對大數據開發領域及崗位的詳細解讀，完整理解大數據開發領域技術體系

推薦測試耳機品質的專業網站

System.ArgumentException: 指定字符串與主題所要求的形式不符。在 System.Net.Mail.Message.set_Subject(String value)

Android Studio創建新項目出錯 Could not fetch model of type 'IdeaProject' using Gradle distribution

批處理實現利用Windows磁盤碎片定期整理

Visual Studio支持PowerShell腳本

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結