(金)今さら、ハマったんでメモしておこう。ディレクトリを開くopendir()でディレクトリとして認識してくれず、そのディレクトリだけ見えない状態だった。WINDOWS10で、ActivePerl。日本語のディレクトリ名で、たぶんこいつだろう、という見当はついていた。815c罫線というか日本語のダーシ?ダッシュ?に使われる記号。ありがとうございます。「―」はshiftjisだと「815c」で、この「\x5c」がファイル名やパスの末尾にあるとperlはうまく扱えない、らしい。回避するにはディレクトリ名の末尾に「'/.'」path区切りをつけてカレントディレクトリのピリオドをつける。苦肉の策ではあるけど、これで無事ディレクトリを辿ることができた。'/.'などとやって無事perlからディレクトリが見えるようになった。(再帰的にディレクトリを辿るサブルーチンにさっそく採用させていただいた)ディレクトリ名に日本語を使いたくはないんだけど、仕様で必要とされるケースがあるので、しかたなく。しても、ほんと今さらなトラップに仰け反ったぞ。(木)管理ページからダウンロードしたデータがNNNNN.csvという名前なのに、中をみるとタブ区切りでびっくりしてたんだけど、perlでいつものようにごそごそやると文字化け。エクセルに読み込んで別名保存すればいつもの意図通り。エクセルで保存すると文字コードはcp932、いつも通りになるからだ。BOM付き、でビックリ。これはperlで扱いにくい文字コードで、確か以前悶絶して諦めた記憶。結局一度エクセルなどに読み込ませて別名保存でcp932にしてからperlで処理していた。今回、頻度ボリュームともけっこうあるので、こんなひと手間をかけたくない。perlだけで処理したい。いうことでぐーぐる様。WindowsでPerlを使ってUnicode処理(1)http://blog.livedoor.jp/numa2666/archives/52344850.html↑こちらのサイトを参考にさせていただきました。ありがとうございます。}詳細は上記サイト参照。ここではやってることの説明だけ。理解してるわけでなく、結果オーライでやってるので間違ってる可能性があるけど。・入力はバイナリモードで読み込む必要がある。・ファイル全部一気読みのために、入力レコードのセパレーターを殺す。・utf-16でデコード(スクリプトで処理するため)perlの内部形式にデコードしてしまえば、あとはそのまま処理してもいいだろうし、他の文字コードにエンコードしてもいいし。ここから先はいつも通り、となる。...にしても、どうしてutf16なんてものがあるんだろう。(perlで扱いにくいってだけなのかもしれないけど)スゲーめんどくさい。(水)一昨日、新元号の発表があった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もなく、手入力でポチポチ検索できるだけ、なのでスルー。(火)ISBNをキーに本の情報(タイトル、著者、書影)を求めて三千里、だ。あらすじその1かれこれ15年以上、ずっと利用させてもらっていたAmazon(PA-API)の利用条件が変更となり、うちのように売上のほとんどないサイトだと利用するのが難しくなった。状態を見ていると、使えたり使えなかったり、というかほとんど使えないんだけど、時々使えることがある、といった感じ。その条件がよくわからない。あらすじその2PA-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が変わることも考えられる。自鯖でのキャッシュを期間限定とした。今回のことでちょっと調べてみたら、スクレイピング行為がなにやらマーケティングだのなんだので使われていて、スクレイピングについてのスキルを持っているといろいろ重宝されて優位に立ち回れるとのこと。いやいや、ちょっと待てよ、だ。公開されているものとはいえ、他人の著作物から、自分の都合の良いデータだけ切り取ってもってくるのがスクレイピング。そのデータは権利者の意図とは違う使い方をされるのがほとんどだろう。カタカナ言葉でなんかごまかそうとしているけど、単なるタダ乗り行為。なんちゃら猛々しいんじゃねえのかとか、便所バエの自覚はないのかと昭和老害は思うわけですな。オライリーからこんな本まで出てるんだなぁ。