[SpookyJS] https環境でformデータをpostするやり方でEdinetサイトをクローリング

インターネットで巨大なデータベースである事は、この蜘蛛の巣が世の中に出回り始めてから誰もが感じていると思いますが、そうしたデータベースを十分に活用できているわけではなく、それぞれのWEBサイト毎に好き放題データベースを作って運用しているのが現状です。 もちろん、全てのデータベースを規則化する事は難しいのですが、システムレギュレーションは統一規格が無く、W3Cのような規格団体が存在するけど、守られていないケースの方が多いように感じるのは、エンジニアだけかもしれませんね。 そして、WEBサイトスクレイピングを数多くやっていると、色々な構成のページに出会います。もちろん規格など無いことが前提の話です。 今回は、金融庁の株式情報の公開サイトである「Edinet」のスクレイピングに挑戦しているんですが、このサイトが非常にややこしいページ遷移方式をしていたので、その時の苦労を書き留めておきます。

WEBページをAリンクではなく、form-postで遷移するサイト

Edinetサイトでは、色々なデータが参照できたりダウンロードできる見る人が見れば非常に有効なデータサイトになっているのですが、クローリング作業をやってみて気が付いたんですが、Aタグが通常の書き方をされていません。 href属性に"javascript:actionDo(...)"などのように、javascriptを実行してページ遷移している事が見受けられます。 そして、実際のJS関数を追って見ると、ページ全体がformタグに囲まれていて、重要な受け渡し値がinput type="hidden"で用意されています。 Aタグをクリックすると、ページ遷移させずに、そのinputタグに値を埋め込み、そのformデータをsubmitするという流れになっているようです。 さらにそのあと、Aタグのhref属性を削除していたりして、2度クリック禁止対応の為にこうした処理をやっているのだと思いますが、ここにいくつかの落とし穴があり、スクレイピングで苦労してしまいます。

httpからhttpsに遷移するとエラーが出る

スクレイピングで苦労する一番の原因は、Edinetのトップページが"http://disclosure.edinet-fsa.go.jp/"というURLですが、 その先に遷移するURLが"https://disclosure.edinet-fsa.go.jp/..."という風にプロトコルが変更されてしまいます。 通常のAリンクの場合はこの遷移でもうまくいく場合もありますが、formでpostするという条件では、基本的にErrorになってしまいます。 casperjsやspookyjs、phantomjsなどを使っていると、こうしたエラーが取得しづらいのでページが遷移されないという結果になりがちです。

ポイントは、ssl設定をignoreして解決

これまでのspookyjsの設定は、下記のように標準的に書いていましたが、 new Spooky( , function(err){{ child: { command : '/usr/local/bin/casperjs', transport : 'stdio' }, casper: { logLevel : 'info', verbose : true, waitTimeout : 3000 } } , .. }); 今回のような場合では、下記のようにします。 new Spooky( , function(err){{ child: { "ignore-ssl-errors" : true, command : '/usr/local/bin/casperjs', transport : 'stdio' }, casper: { logLevel : 'info', verbose : true, waitTimeout : 3000 } } , .. }); 「"ignore-ssl-errors" : true,」という１行が追加されているのがわかると思いますが、sslエラーを無視する設定なんですが、これを１行いれるだけで、問題なく遷移できるようになりました。 色々なサイトで書かれているのですが、commandをセットしたり、"ssl-protocol"のセットをすると書いてあるサイトがありましたが、色々試してこの設定だけでOK（この状態）という事がわかったので、その備忘録です。

次なる課題

今回はSSLでのページをFormタグで遷移するサイトの対応だったのですが、実はこのままではゴールにはならず、必要なデータをpost送信して、データをgetするところまでできなければいけないようです。 果たしてspookyjsを使うのがいいのか、requestライブラリでやってしまえないのかを次回検証してみたいと思います。 改めて、WEBページ毎に、統一した方法がなく、現段階でのヘッドレスブラウザは、GIUのような標準化するのがなかなか難しい領域である事がわかりますが、 こうやって、色々なサイトをクローリングしていると、新たな発見がどんどん出てくるので、それに対応して経験値を増していくという前向き思考で乗り切りたいと思います。 僕の場合はブログネタもできて、一石二鳥というわけですね。