スクレイピングをブロックされるの巻
ISBNをキーに本の情報（タイトル、著者、書影）を求めて三千里、だ。
あらすじその１
かれこれ15年以上、ずっと利用させてもらっていたAmazon（PA-API）の利用条件が変更となり、うちのように売上のほとんどないサイトだと利用するのが難しくなった。
状態を見ていると、使えたり使えなかったり、というかほとんど使えないんだけど、時々使えることがある、といった感じ。その条件がよくわからない。
あらすじその２
PA-APIがそんな状態なもんだから、Amazonの商品ページをスクレイピングしてのデータ取得に変更。すんなりデータが取れた、と思う間もなく（ほとんど7日以内）スクレイピングがAmazonにブロックされてしまった。
データが取れなくなったんで、取得するHTMLを眺めたら、自動アクセスしているようだけどAPIがあるからそちらを使いなさい、というコメントが入っていた。
そもそもアマゾンは規約でスクレイピングが禁止されてるので、やっちゃいかんのだ。
てことでamazonについては、ほぼ利用できなくなった。
（アフィリエイトタグ、リンクやアカウントには問題はない。データベースとしてAmazonが使えなくなったということ。念のため）
何度も書いてるように4月になったら国立国会図書館がAPIを公開するので乗り換えを検討。
ただ、どんなAPIなのかどんなデータが使えるのか、実際に公開されてから確認となる。
いま公開していて、ユーザーさんが利用してくれているサイトもあり、いままさにどうするのかということで、繋ぎでいいのでなんとかしなければならない。
AmazonのPA-APIが不定でたまにしか使えない（たまに使えるからかえって未練たらたらとなる）
Amazonに対するスクレイピングは規約も不可。
ということで、その場しのぎのでっちあげ、というわたしの得意技。
AmazonのAPIを使ってページを公開しているサイトをピックアップして、そちらをスクレイピングすることにした。
アマゾン本家ではなくAPIを利用しているコバンザメからデータを持ってくる便所バエ作戦だ。
本のデータを取得するためだけに、文字通り機械的にアクセスするわけだから、そのサイトにとっては何の利益にもならない、ただの無駄なアクセスとなる。amazonのようにインフラも強固巨大なサイトならともかく、規模的に小さなサイトだとちょっとした負荷も迷惑でしかない。
さすがに申し訳ない。
のべつ幕なしリクエストを投げるようなことを避けるために自鯖内で期間限定のキャッシュすることにした。
図式的には
・本の情報が欲しい時はまず自鯖のキャッシュを確認
・キャッシュされていればそれを利用
・キャッシュになければPA-APIを利用してデータ取得を試す
・PA-APIでデータ取得できればそれを利用。取得したデータをキャッシュ
・利用制限でデータ取得できなかったら他サイトをスクレイピング。
・スクレイピングでデータ取得できればそれを利用。取得したデータをキャッシュ
てことにした。
キャッシュするのは、ISBN・タイトル・著者の基本3点セット。さらにデータがあれば書影のURL。
本のタイトルや著者をキャッシュすることは問題ないはずだけど、書影（画像）についてはたぶん権利関係がらみで面倒くさいことがあるだろう。
画像をダウンロードして利用するなどもちろんアウト…というかただの犯罪行為。
公開されている書影のURLについては問題ないと思うけど、書影を公開しているサイトと書影（画像）の権利者とでどのような約束があるのか不明で、おそらくずっと同じURLで公開しない。もしかしたらアクセスのたびにURLが変わることも考えられる。なので自鯖でのキャッシュを期間限定とした。
今回のことでちょっと調べてみたら、スクレイピング行為がなにやらマーケティングだのなんだので使われていて、スクレイピングについてのスキルを持っているといろいろ重宝されて優位に立ち回れるとのこと。
いやいや、ちょっと待てよ、だ。
公開されているものとはいえ、他人の著作物から、自分の都合の良いデータだけ切り取ってもってくるのがスクレイピング。そしてそのデータは権利者の意図とは違う使い方をされるのがほとんどだろう。カタカナ言葉でなんかごまかそうとしているけど、単なるタダ乗り行為。
なんちゃら猛々しいんじゃねえのかとか、便所バエの自覚はないのかと昭和老害は思うわけですな。
て、オライリーからこんな本まで出てるんだなぁ。ううううむ。ほんまかいな。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
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」
ワード(docx)からEPUBファイルへ下準備
epubファイルを作成するのに元データがワードというケースがあったりなかったり。
電書オリジナルもそうだし、既存の本のOCRもデータがWORDファイルということになる。
このネタ、過去にも何度かここに書いていて、くりかえしになるかもしれないので、今回は途中で使うスクリプトをアップロードして差別化…ていうかやっとくだらないバグが取れたので(汚いケド)晒してもいいかな、と。
スクリプトを使って
・ワードファイル(.docx)を解凍(展開)
・ワードで指定されているルビ、縦中横、圏点、太字をxhtmlのタグに変換
・ルビのオフセットを出力
やることは以上3つ。
用意するものは。
・例によってperl
WINDOWSは https://www.activestate.com/activeperl/downloads からダウンロード、インストールが必要。
それ以外のOS、Macやunix系は特に必要なし。
・コマンドライン版のunzip
WINDWOSは https://github.com/bmatzelle/gow/downloads このへんからダウンロード、インストールが必要。
それ以外のOS、Macやunix系は特に必要なし、かな。
・以下のスクリプト
https://t2aki.doncha.net/tmp/docx2xhtml-tag.zip
ターミナルのコマンドプロンプトで
perl check_docx.pl word.docx
と叩くとdocxを展開して、ルビはxhtmlのタグに変換。縦中横や圏点は独自タグに変換。
「_docx-yyyymmdd.txt」というファイルを出力する。
同時に「check_docx.log」というルビとそのオフセット位置を記述したファイルを出力。
なんでこんなファイルを出力するのかというと。
ルビを削除したい時にオフセットをいじってルビを見えなくする、という凶悪なことをやってるケース。ワード上ではルビは見えないのにデータにはルビが殘っている、という迷惑なことが何度かあって ムカついたから オフセットが変なルビを確認するため。
次にターミナルのコマンドプロンプトで
perl _docx2xhtml-tag.pl _docx-yyyymmdd.txt
と叩いて、縦中横・圏点・太字をxhtmlのタグに変換。
「_docx-yyyymmdd-converted.txt」というファイルを出力する。
ワードファイルを真面目に解析すればワード上のレイアウト情報も取れるんだけど、そもそもepubファイルに変換する時に、ワード上のレイアウトを再現することを要求されることはほとんどない。
必要な情報はルビと文字装飾(縦中横・圏点・太字・傍線)ぐらいなものなので、これだけで実用には十分。
以上のことをwordを開いて目視確認(目grep)して、タグづけしてたんじゃとてもやってられんので、スクリプトにやらせることにした。このおかげで3〜4時間作業が20分作業となって取りこぼしも激減。
(スクリプトではwordのxmlを解析してごにょごにょやってるんで、そっち系のひとにはほんの少しは面白いネタかもしれない)
てことで、今日は家人と築地市場で海を食ってきた！
いや、なんというか、ほんとに美味かったなあ(涎)
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(102) » perl(105) » 日常(907)
Androidタブレットでepubcheck
タイトルが大嘘ですみません。
AndroidタブレットZenpadにtermuxでLinux環境を作って仕事・作業もこれで間に合わせよう、というネタ。
電子書籍、EPUBファイルの作成仕事をいただいている。
作業環境というか制作に使うのはエディタとperl。
そして作ったepubファイルが正しくできているかチェックするのに必要なのがepubcheckというjavaで走るスクリプト(プログラム？)。これでチェックしてエラーや警告のないことが納品の前提となる。
wordやinDesign(の出力したepub)をエディタで確認、epubファイル生成用の独自タグを埋めこんだりその他タグの調整をして、perlのスクリプトに食わせてepubファイルのできあがり。
とりあえず作ったepubファイルをepubcheckにかけてエラーの確認。
使っているスクリプトは各クライアント用にカスタマイズ済なので、初めての案件でもない限り、ほぼエラーは出さない。
このエラーのないepubファイルを電子書籍リーダー(Kinoppy)に読みこんで確認・修正作業となる。圏点や太字の漏れや、字下げ、文字サイズ、空行の調整などを原稿(WORDやPDF)を見て、該当するxhtmlファイル(epubファイル)をエディタで開いて手作業での修正だ。
わたしは雑な性格なもんで、ここでエラーを紛れこませてしまう(なので、できるだけスクリプトにして極力手作業は避けるようにしている)
せっかくepubcheckでエラーのないファイルを作っても、その後の手作業修正でエラーにすることがある、ということだ。
ファイルを修正するたびに必ずepubcheckでエラーの確認をしている。
なのでAndroidタブレットでjavaがない、epubcheckが使えないのは致命的。
termuxでjava(jdk-8)を動作させているハッカーのひともいるけど、素人のわたしはパッケージとして用意してもらわないとまず無理。
歓喜の持ち歩けるLinux環境が宝の持ち腐れだ。
わたし得意の「とりあえず」の「やっつけ」で、epubcheckは無理だけど、できたファイルをチェックする程度のスクリプト(perl)を「でっちあげた」
前提として、epubcheckの通ったファイルであること。
手作業で紛れこませるエラーは、タグの不整合(閉じ忘れ・削除し忘れ)、追加や変更があってopfにファイルの登録し忘れ、といったところがほとんど。これらを潰せればだいたい問題はない。
タグの不整合チェックにperlのHTML Lintを入れてみたんだけど、ちょっと使い勝手が思ったのと違うので見送り。タグの数をチェックするだけで十分てことにした。
また、META-INFのcontainer.xmlから辿って、opfファイルを読みこみ、ファイルの有無、manifestとの整合もチェックする。
もちろん、この程度のものが業務実用になるとは思わないので、納品前にはepubcheckを通す。ただ、途中途中、外出先などでの確認作業はこれぐらいで十分だろう。これで急ぎの対応なんかも可能となる。自画自賛。
termuxのコンソールで走らせてニヤニヤした勢いでこの雑記を書いてるんだけど、こりゃただの日常雑記、何の役にも立たんな。
いや、ほんと申し訳ない。
ポケモンGOのイベントがひと段落したら、本格的に持ち歩きLinux環境の稼動だ。
[06/21 19:26:40]
EPUBファイルと同じ階層にスクリプトを配置。
引数にEPUBファイルを渡すと
1)unzipを呼びだして解凍
2)フォルダ構成を表示
3)opfに登録されているファイルが、EPUBパッケージの中で登録通りの場所に配置されているかチェック
4)逆にEPUBパッケージに配置されているファイルが、opfに登録されているかチェック
5)タグの不整合のチェック
・opfに登録されている「contents014.xhtml」ファイルが見当らない
・「cover00.jpg」「contents020.xhtml」がEPUBパッケージ内にあるけど、opfに登録されていない
・spanタグがおかしい。開始タグが1つあるのに閉じタグがない
・contents001.xhtmlの42行目あたり
てな感じ。
昨日書いたように、epubcheckの代わりになるものではない。あくまでも、とりあえず最低限(にも足りないけど)の確認だけ。epubcheckをちゃんと使って確認していることが大前提。
こっちのPCではepubcheckが使えるけど、こっちのPCだと使えない、というような場合の緊急避難的安心感を得るためのもの。いや、こんなんでもけっこう助かる、おれは。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
termux環境でXML::Simpleのインストール
Androidタブレットのlinux環境、termuxにperlをインストールして普段の仕事環境を構築していくネタ。
XML::Parserのコンパイルでハマったのでメモ。
結論からいうと、expat.h expat_external.hというふたつのファイルをexpatの本家サイトからいただいてきて/usr/include/に配置して解決。
expat本家→https://github.com/libexpat/
perlのXML::SimpleというXMLを解析するためのモジュールは必需品。
WEBで提供されるもろもろのデータのほとんどはXMLかjson形式なので、なくてはならないシロモノだ。
また、ワード(.docx)やエクセル(.xlsx)も、その本体はXMLファイルなので、ワードファイルの解析にもXML::Simpleは必須。というか、XML形式のデータは日常のあちこちに広く深く潜んでいる。
このXML::Simpleというモジュールは、MacOSXでも、WINDOWSのActivePerlでもデフォルトで入っている標準のモジュール(…って記憶が曖昧)
ところが、termuxのperlのパッケージには入っていないので、CPAN(perlのモジュールならなんでも揃う巨大なアーカイブ)から持ってくることにした。
CPANのインストール
pkg install cpan
makeのインストール
pkg install make
XML::Simpleをインストールするために必要なXML::Parserは(ていうか、XML::Simpleは被せもの・ガワでその実体はSAXとかParser)「.xs」ファイルを生成する必要がある、Cコンパイラが必要なので。
Cコンパイラのインストール
pkg install llvm
pkg install clang
これで準備完了。cpanのコマンドラインで
install XML::Simple
とやればインストールできるはずなんだけど、XML::Parserのインストールでエラーとなって止まってしまう。面倒くさいけどインストールのログを見ると
コンパイルに必要な「expat.h」が見つからない、というエラーで終了している。
「XML::Parser cpan expat.h」などとぐーぐる様に訊ねてみたらさくっと解答が出てきたので、expat本家サイトから「expat-2.2.5.tar.bz2」をいただいてきて解凍、その中に入っていたexpat.h(と、expat_external.h)を「/usr/include/」にコピーしたら無事インストールできた。
とりあえず今日はここまで。
というのも、termuxのlinux環境はファイルのpathが独特、というか閉じた中でやってるみたいで、スクリプトの中でファイルのコピー操作が意図どおりにいかない。これは調べなきゃ、だなあ。
termuxというAndroidのlinux環境。こりゃ久しぶりに面白いもの見つけたなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ひとりツイッター
久しぶりにスクリプトをでっちあげた。
前からちょっと欲かったシロモノ「ひとりツイッター」クライアント、だ。
この雑記帖ほどまとまった量でもなく、やること・やったこと・やらなきゃいけないこと・思いつき・考えたこと・忘れちゃいけないこと、なんかをただただメモするだけ。
だったらメモ帳でいいじゃん…てことだけど、それだとまず続かない、かなぁ。
ツイッターのように時系列で、ひとつずつの塊として記録して流していくのってけっこう面白いものだし、TODOっぽい機能をつけたので役にも立つ。
それに、そもそもスマホやPC、複数のデバイスからアクセスしたいのでメモアプリはちょっと違う。
だったらグーグルカレンダーやアウトルックでいいじゃん…てことだけど、どっちも大袈裟・ご大層。ちゃっちゃと開いてちゃっちゃと書くという感じじゃない。構えなきゃいけないのは続かない。
だったらgmailで自分宛にメールすればいいじゃん…てことだけど、いちいち件名とか入れるのが面倒くさい。だいたい、数時間とか数分ごとに書きこんだりするのに、大量のゴミメールがストックされるとうっとーしーのでメールそのものを見なくなる。
だったらツイッターで鍵アカを作って書けばいいじゃん…てことだけど、わたしはWEBサービスを信用してない。人に見せることを前提にしていないのだ。もし万が一にも書いたことが漏れたら大変だ。個人的なこと、ひとには言えないことなんかもあるかもしれない。
てことで、この「ひとりツイッター」あるいは「王様の耳はロバの耳の穴」とか「ライフログ」的なものとなる。
・何か思いついたら書きこんでチェックイン。
・書いたものが終ったら、片付いたらチェックアウト。
・書いたものは新しもの順に並ぶ。
・TODOとしてチェックしたものはトップの方に表示する。
・チェックアウトしていないものを抽出できる(TODOにする必要はない)
・検索ができる。
というのが最低限の仕様。
エントリの編集機能？
いやいや、ツイッターを見てくれ。投稿するか削除するかの二択で十分だ。
リマインダーのメールを飛ばす？
いやいや、いろいろとしんどい時もある、そんな時にリマインダーなんぞ見たいか？
カテゴリわけする？
いやいや、いちいちそんな整理整頓やってられるか？時系列で並べば十分だろ。超整理法とかって聞いたことないか？
しばらくこんな仕様で使ってみよう。
ボケ防止にもなる、はず。
[2016/12/01 21:33:22]
さっそく昨日から使いだした。思った以上に使い勝手が良い（自画自賛）
というか、スマホ前提にしたのが勝因かな。いつでもどこでもメモ、独り言、譫言だ。
こいつのデータベースはSQLiteなので、実体はファイルひとつ。今はlolipopに置いてるけど、レンタルサーバーを引っ越すことになってもひとつのファイルをコピーしてもっていけばいいだけだ。
下のスクリーンショットからもわかるように、誰の役にも立たない独り言。こーゆーのもいいもんだ。
 |  |
| 最上部のテキストエリアに記入したらチェックイン | こんなくだらないことを書くわけだから「ひとりツイッター」というか「独り言」 |
 |  |
| 日付順に並ぶ。まだチェックアウトしてないものも混じる。チェックアウトしてないものはゴミ箱に捨てられる。 | テキストエリア左下のチェックアイコンをクリックしてチェックアウトしていないものをリストアップ(リストアップ状態ではチェックアイコンがリロードアイコンとなる) |
 |  |
| 虫めがねアイコンにチェックいれて、テキストエリアに検索ワードを入力してチェックインすると（ここでは「検索」） | 検索結果と検索にヒットした件数も表示 |
こんな独り言アプリはすでにあるらしい。
SNS、ソーシャルとかでひとと繋がりたいばかりじゃない。そういうのがめんどいとかしんどいとかって時はブツブツ独り言でいいんじゃないかな。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
