- » Kindle
- » iBooks
- » kobo
- » B.W.
- 100円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 490円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 300円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 600円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 400円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
doncha.net制作・発行:KindleやiBooks、楽天kobo、BOOK☆WALKERで読む電子書籍
Amazon PA-APIの代わりにスクレイピング

ウチのサイトで売上がなく、AmazonのPA-APIの利用制限に引っかかって使えなくなったのが前号までのあらすじ。
充実した本のデータベースとしてありがたく使わせてもらってたんだけど、Amazonも営利企業だ、売上に貢献できてないのだからやむを得ない。
しかたがないので、Amazonのページをスクレイピング(クロール)、ページを解析して必要な情報を取得することにした。
Amazonが公式に提供してくれるAPIは仕様も明らかにされていて使い勝手がいいし、変更も予告されるので事前準備ができる。
その点スクレイピングは自力でhtmlを解析しなきゃいけないし、サイトのちょっとしたリニューアルのたびに解析のやり直しとなる。て、そのちょっとしたリニューアルなんて頻繁なので追随するのが大変。
APIを使わず、サイトをスクレイピングするメリットなどない。
売上がたってAPIの利用制限を回避できるようになるまでの暫定手段…て、現状、まるで期待できんけど。
とりあえず目先必要なモジュールを書き換え・置き換えたので、忘れないうちにメモ。
わたしが公開しているサイトのほとんど、Amazonから取得する本の情報が使われている。
馬鹿のひとつ覚えで、どれもisbnをキーに本のデータを取得してその中から、タイトル、著者名、レビュー、書影をサイト表示に使っている。また、検索結果を表示させているページもある。
今回APIからスクレイピングに変えることで、検索は止めることにした。
最初はAmazonの検索URLの検索結果からデータを取得しようと思ったんだけど、アマゾンのページを見ればわかるように、検索対象以外の本が、ベストセラーだのオススメだのと入り混んでくる、雑音が多いページなので却下。APIだと雑音はなかったんで、それなりに有意だったのに、このありさまじゃわざわざ実装する意味がない。
てことで、ISBNをキーにして、タイトル、著者名、書影、レビューが取得できればそれでOKとした。
…と、なんだか小難しいことをおおげさに言ってるけど、そんなことは全然なくてAmazonのページURLを見ればなるほど簡単の種明かしだ。
たとえば。
https://www.amazon.co.jp/dp/4575513393
↑『アレルヤ』桜井鈴茂の商品詳細ページ
ページのURLにASIN(4575513393の部分)が使われている。ISBNさえわかればASINに変換してURLにしてリクエストしてやればページのHTMLが取得できる。
あとはHTMLを解析して必要なデータを取ってくればいいだけだ。
13桁のISBNを、Amazonの10桁のASINに変換するネタが2006年の雑記帖に。
「来年からのISBNの13桁に」
https://t2aki.doncha.net/?id=1167061487
この時作ったモジュールが今も現役。
Amazon商品ページのHTMLのどのタグ、どの文章を正規表現で切り取ってるか、など具体的な詳細をここで今書いたところで上記したように明日にも構造が変わってしまうことがありうるんであまり意味がない。
スクレイピングする時のわたしなりの定石というかポイントだけ。
クロールする対象はPCサイトではなくて、スマホ版。
スマホ版の方がHTMLが素直なので解析しやすいから。PC版だとテーブルが邪魔になることが多い。HTML解析のモジュールもあるのでそれを利用すればいいんだろうけど、汎用的なモジュールは、結局は対象サイトに合わせてカスタマイズが必要となる。だったら、最初から解析が比較的ラクなスマホ版を対象にすればいい。
何はなくてもタイトルタグ。
SEOのこともあるので、大きなサイトは、タイトルタグの内容に関しては安直に変更したりしないので信用できる。
Amazonの商品ページで言うと、書名・著者が必ず入っている。ウチ場合、ISBNをキーに欲しいデータはこれだけといってもいいほど。ページ本文(HTML)の解析なんて必要がない。
とはいえ、書影のURLやレビューはHTMLを解析する必要がある。
それには、HTMLの中にあるhタグとページで一意(ユニーク)なidをチェックするだけでほとんどことは足りる。
perlなら欲しいところを
@buf = $contents =~ m!tag(.+)tag!g
で一網打尽
くどいようだけど、スクレイピングはamazonが公式にサポートしてくれるAPIと違う。
APIだと変更などはアナウンスされるのでそれを待ってればいい。でも、スクレイピングしてデータを取ってるとHTMLの変更を検知、追随する必要がある。
ヘルスチェックのスクリプトを書いてクローンで走らせる必要があるなあ。
来月、2019年4月から国立国会図書館で書誌情報の提供、APIでの提供が始まるらしいので、そちらに乗り換えることも考えておこう。
http://www.ndl.go.jp/jp/news/fy2018/190219_01.html
[2019/03/12 04:18:29]
てことなので良い子はマネしないように。
そりゃそだな。公開されているとはいえ、スクレイピングって、他人の著作物から勝手にデータを抜き出して使うわけだから、あまり行儀のよいことじゃない。
解散。
国立国会図書館のAPIに期待…だけど、電子書籍とか書影とか対応してるのか気になるところ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」