WSH/VBSでデスクトップブラウザを起動してスクレイピング

WSH/VBSでデスクトップブラウザを起動してスクレイピング

昨日からVBS系の記事を書き出していますが、閲覧数が少ない！笑
まぁね、それだけ需要の少ないニッチなプログラム言語になっているって事でしょう。

PHP/Python/Ruby とか使った方が端末の影響受けずに済むからねぇ。
ローカル環境で構築しちゃうと結局同じかもだけど…。

でもですね、WSH/VBS の非常に優れた点ってやっぱりあるんです。
その一つがWEBスクレイピング。

最近のサイトはスクレイピング対策がしっかり構築されてきています。
楽天市場やYahoo!ショッピングの店舗ログインページでも目にします。

スクレイピングを妨害する技術

サーバーからのスクレイピングではヘッドレスブラウザという種のブラウザを利用して実行します。
scriptの裏側で1つの指示に対して1つのブラウザがしっかりと処理してくれるので、並列ブラウジングも可能になるのですが、いくつかの壁があります。※Chromeヘッドレスブラウザ

例えばAmazonでは2と3を基にクローラーか否かを判断し、1を画面に出力します。
それも10アクセス位で判断されます。（判断されました…。）

ヘッドレスブラウザでの情報収集作業は快適ですが、自分の手元には結果だけが返ってきます。
CAPTCHAの画面なんて出てきません。
世の中にはすごい方もいて、画像解析を行いCAPTCHAを突破する方法もある様ですが私にはまだまだ難易度高すぎ。

で、これらを突破できる方法の1つがWSHやVBSでデスクトッププラウザを人が操作するように操縦する事なんです。

WSHやVBSでデスクトッププラウザを操作する

WSHやVBSを利用すればどんなブラウザでも操作できます。IEだけではなく、chromeもFireFoxでもOKです。
ただ、COMオブジェクトを積んでいないので例えば起動時にこんな書き方はできません。

起動時にはパスをしっかりと書かないといけません。

また、【 objIE.Document.getElementsByClassName(“chartDetailBtn”)(0).Click 】の様にHTMLの要素を取得して要素に対して操作すると言う書き方については使えるか否かがブラウザによって異なります。
動かない時はまずブラウザがコードに対応しているか調べてみましょう。

デスクトップブラウザ操作のメリットとデメリット

上記の通りVBSから簡単に起動させることができるデスクトップブラウザですが知っておくべき利点と欠点があります。

上に記載したようにクリックしたりキーボードのEnterを押したりなど人が行う操作をそのまま表現できるのでクローラーと言われにくいのが最大のメリットです。
しかし、その分デスクトップの動作を占拠してしまい他の作業が出来なくなると言うデメリットが出てきます。

例えば、400ページのスクレイピングをしようと計画したとします。
1ページ当たり1分で400分 = 6.6時間。
作業量が多いからスクレイピングしたい訳ですが、その作業量がPCの占有という副産物を産んでしまうと言う悪循環。

サーバー立ててヘッドレスブラウザ使いたくなりますよね。でもヘッドレスブラウザにするとクローラー対策が…。

楽天市場RMSに設置されているクローラ対策

私がさっと触った部分だけでもこの4種がありました。
ページ全体だともっとあるのだろうなと。

3、4の合わせ技などはSleep時間を多めに取るしか解決策がないし、多めにとれば実行時間が長くなるしと困ったチャンです。スクレイピングの所要時間が長くなってしまいますから…。

まとめ

デスクトプブラウザを使ったスクレイピングはクローラー対策に掛かりにくいため有効手段の1つです。
でもブラウジング中は他の作業が出来ない等、困った環境も作り出してしまいます。

まぁ要は『どんなルールを作るか』運用面も含めて設計しないといけないって事ですね。
その中には、ヘッドレスブラウザとの切り分けとかいろんな解決策があると思います。