書誌情報データを求めて三千里
一昨日、新元号の発表があった4月1日に国立国会図書館の書誌データAPIが解禁となった。
今までも検索などに使えていたけど、データベースとしてガツガツ使うには登録が必要だったり面倒くさかったのが、4月1日からは誰でも自由に使ってもかまわんぜ！になった。
てことで、今さら国立国会図書館の書誌データAPIをごそごそ覗いてみた。
国立国会図書館サーチについて＞API仕様の概要
https://iss.ndl.go.jp/information/api/riyou/
わたしの、というかわたしが公開しているサイトの使い方は前にも書いた通り。
「ISBNをキーにして書誌データと書影URLを取得したい」
たとえば、スティーヴン・キングの『シャイニング』
ISBNは978-4167705633
これを国立国会図書館のAPIで探すには以下
https://iss.ndl.go.jp/api/opensearch?isbn=978-4167705633
→書誌情報のXMLが返ってくる
https://iss.ndl.go.jp/api/openurl?isbn=978-4167705633
→検索結果ページが返ってくる
https://iss.ndl.go.jp/api/sru?operation=searchRetrieve&maximumRecords=10&query=isbn%3d9784167705633
→書誌情報XMLが返ってくる（このsruはさらに細かく検索方法の指定もできる）
うちの場合、必要な書誌情報はopensearchで十分。
著者についてももろもろ考慮されて（同性同名や読みなど）おり、データのクオリティは信用できる。さすが。
https://www.ndl.go.jp/jp/data/faq/author.html
蔵書のある図書館の情報なども取得できるので、位置情報と合わせて「目当ての本がある最寄りの図書館」なんて検索も実装できるし、その手のアプリがすでにあるのは、国会図書館のデータが元ネタじゃないかな。
だけど、書影がないのはほんと残念。
本棚を眺める楽しみのひとつ、というか欠かせないのが表紙だもんなあ。
基本的な書誌情報は国立国会図書館で、書影・表示画像はamazonなどのショップサイトのURLを別途取得…とか1冊の本のために2回も外部にリクエストしてるとサイトの表示がもたつく原因になってしまう。
てことで、うちのサイトのデータ取得方法は現状のままとする。
国会図書館のデータはまた何か別の用途で利用させてもらおう。しっかりとしたデータは見ていて気持ちいい（データオタク）
ちなみに。
「一般社団法人 日本出版インフラセンター」という版元主導のところも3月25日に書誌データベースのサイトをオープンしたけど、APIもなく、手入力でポチポチ検索できるだけ、なのでスルー。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
スクレイピングをブロックされるの巻
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」
WINDOWSでバックアップ
何を今さらバッチファイルてことなんだけど。
WINDOWSであるディレクトリのバックアップをとりたい、という時にエクスプローラーを二つ開いてコピーするのがだるい。
mac（unix）ならrsync一発なのにと思ってたら、WINDOWSにもrsyncのようにディレクトリ、ファイルを同期してコピーできるコマンドがあった。
robocopy FROM TO /MIR
FROM（元のディレクトリ）をTO（バックアップ先のディレクトリ）に/MIR（同期して）コピーする
そこで、このコマンドを使って、USBにバックアップを取るバッチファイルを急遽でっちあげ。
EドライブのworkディレクトリをUSBにバックアップする。
USBが刺さっていたら＝Fドライブのworkディレクトリが存在していたら、robocopyをミラーリング指定で実行。
robocopyはいろんなオプションがあって、ログを取ったりすることもできてけっこう便利。いちいちエクスプーラーでコピーするよりコマンドプロンプトでrobocopyを使った方が1024倍早い。
バカにしていたWINDOWS先輩、ごめんなさい。
…にしても、バッチファイルなんて何年ぶりだろう。
日本酒を堪能してきた！
末広町「魚や 藤海」
https://tabelog.com/tokyo/A1311/A131101/13188420/
↑日本酒が好きなら全力でおススメ
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» 日常(941)
前後5分、身の回り5m
時間的には前後5分。
5分以上前の自分はアカの他人だし、5分以上先のことなどわかるわけがない。
空間的にはだいたい半径5m。
それ以上先には何があるのか把握する必要もなかろう。
というのが基本。
人間、歳くうとシュリンクしていくもんで。
なもんで、自分で作ったサイトのコードを久しぶりに眺めると「誰やこれ書いたの」という新鮮な驚きがある。いや、良い方悪い方、両方向に。
AmazonのAPIが使えなくなったんで、WEB本棚のコードを修正しようとデータベースの構成なんかも覗いてみたら、これがすげーシンプルでびっくり。2006年に作ったものだから、5分前どころじゃなく13年前のアカの他人だ。13年前の誰かに感心してしまった。
Amazonにリクエストを送って書誌情報をがっつり持ってきてるもんだとばかり思ってたら、データベースに入れてるのはISBNとタイトル、作者だけ。書影は表示の都度、アマゾンの画像URLを取得して表示させている。
本棚のその他の機能は独自のもので、つけ足すのも取り外すのも簡単にできるようになっていた。
SQLも単純なものばかり（って、当時はSQLの知識も今ほどなかったし）でわかりやすい。
ただ、酷いのはWEBまわりというか表示系。
呆れたことに、パラメータなんかがベタベタにハードコーディングされている。ちょっと修正したら、たぶんあちこち整合性が取れなくて、表示が崩壊する。
javascriptでやってることも今っぽくない。今だとCSSでやるところだ。
ボケ防止のためにも公開しているサイトは手入れしていかんとなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» 日常(941)
アナログ仕事
たとえば。
たかだか100行程度のCSV。エクセル上でフィルタを使いながら手順通り目で確認して15分程度。
とはいえ、毎日15分かかるとして、これが10日だと150分、一年だと90時間ぐらいになる作業。おまけにひとのやることだ。チェック漏れ、間違いは必ず起こる。
面倒なので、perlでチェックツールを作ってそれを使って5分以内の作業に短縮。今まで漏らしていたところも間違いなく確認できるようになった。もちろんすべてをカバーするわけではないので、漏れもあるが、クリティカルなところは潰してあるので、漏れても問題のないところだ。
…んだけど、それはいけないらしい。
「手順通りではない」からダメで、さらには「楽をするな」と。
いやもうなんというか。アナログというか昭和の悪しき風習というか。
機械のように手順通りにやれ、ということなら、機械にやらせるのが正しい。なぜなら、ひとは間違うから。
楽をするなというけど、楽をしようがしんどい思いをしようが、結果同じなら楽にできた方がストレスもなく効率的。
無職初老のフリーターなもんで、複数掛け持ちしてるけども、なかには変な職場もあるんでハゲの進行が止まらないぞ。
こういうところは、割に合わなくなったらとっとと逃げてしまおう。そのための複数掛け持ちだしね。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» 仕事・就職(133) » 日常(941)
