手作業クローラーチューニングをするときの話（クローラー／Webスクレイピング Advent Calendar 2015）

クローラー／Webスクレイピング Advent Calendar 2015の4日目です。

スクレイピングを自動で行ってくるサービスも最近増えてきました。
kimonolabsやimport ioなど。
APIが用意されているサービスを使うと、もうスクレイピングする処理を書くのは嫌になってきます。
しかし、お客さんの都合だったりシステムの仕様として、スクレイピングが避けられなくなったとき、やはり昔ながらの方法でスクレイピングを行うことになります。

よくある仕様として、以下のようなものがあると思います。

• データが存在しない場合はエラーとしない。
• しかしデータが取得できなかった場合はエラーとしたい。

ここまでなら、データの取得だけテストしておけば、あとは一度取得したデータが取れなくなった場合にエラーとすれば上手く行きそうです。
ここにもう一つ仕様が入ってきたときに、話がややこしくなります。

• それまでデータが取得できていた場合でも、データが存在しなくなる場合がある。

データが取得できないときはエラーとするのに、データが取得できなくなることもあるという、矛盾したような仕様です。
データが取得できないパターンとして

• 本当にデータが存在しない
• デザインが変わって正規表現などにひっかからない

がありますが、この二つをどうやって区別し、後者の場合にエラーとするか。
人間の目で確認すれば、「デザインが変わった」なんてことは簡単に分かるのですが、プログラムではデータ付近以外のHTMLは普段から無視するものなので、なかなか分かりません。
またデータ部分以外のHTMLも確認箇所とすると、データは取得できているのに軽微なデザイン変更でもエラーとなってしまう場合があります。

人間の目と脳ってすごいですねと感心しますが、コンピュータにも人間の目のようにデザイン変更を検知させることができます。
そう、HTMLのデザイン担当とも言えるCSSです。
CSSファイルも普段から取得しておき、最後にデータが取得できたときから、データが取得できなくなった段階でファイルのハッシュ値に変更でも有れば、それはデザインが変更されたと認識可能です。
CSSファイルが普段から変更される場合は、データ付近のデザイン定義だけを抜き出してハッシュ化しておくのも方法の一つでしょう。

少なくとも、デザインが変更されたタイミングでデータが取得できないのとCSSが変更されるのは相関があるはずです。
これでデータが取得できなくなってから慌ててデバッグを開始する必要もなくなりますね。