スクレイピングをブロックされるの巻
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」
WEBサイトのValidator偏執狂
WEBサイトを制作したりするんで、HTMLやCSS、javascriptの必要最低限のエラーや警告のチェックはしている、つもり。
「W3C Markup Validation Service」https://validator.w3.org
というサイトもあるし、HTMLやCSSの構文チェックをするツールは各種いろいろある。
…なんてこと言いつつ。
エラーも警告も出ない・出さない、いってみれば100点満点のWEBサイトの必要はあるんだろうか。
たとえば、webサイトでアマゾンECSやgoogleアドセンス、あるいはtwitterやfacebookのシェアなど、よそさまのサービスを自分のサイトに組みこむことなどよくある。そして、それらのコードがすでに警告やエラーの対象となってたりする。
そのせいで、100点満点のWEBサイトにならない、だからこれらのコードは使わない、よそのサービスを組込まない、とか言いだしたら本末転倒だろう。
何のためのWEBサイトかと。
Validatorで警告もエラーもない100点満点のWEBサイトのために、本来やりたいこと見せたいものを制限してどうする、てことだ。
ふた昔前は、Validatorでエラーや警告のあるサイトはSEO的に不利だと言われていたけど、今どきはどうなんだろう。googleさまは日進月歩。metaタグのdescriptionよりbodyの文章を「解析、判断して」表示するようになったのはもう何年前のことか。あれ？昨日までmetaタグのキーワード大事じゃなかったっけ？とか、コンテンツの見出しタグ、altタグはどうだっけ？とか。
だいたい、SEOのために100点満点のきれいなHTMLあるいはCSSを頑張るより、googleさまがユーザー視点から解析の精度をあげて検索結果に適切なものを表示するようになることの方が期待できる。
必死になって100点満点を目指してる・警告もエラーもないことをセールストークにしているのを見かけることがあるんだけど、W3Cにお墨付き・認められたからといってユーザーに認められることにはならない。それで作ったサイトはユーザーにとって使いやすいのか・見やすいのか。
HTMLやCSSのエラーは確実に潰すことができるし、それで100点満点に近づくのは充実感・自己肯定感が得られるので面白いんだけど。
ユーザー視点の欠如だ。あるいはただの自己満足。
最低限、ブラウザでの表示で致命的なエラーとなるHTMLのタグの不整合のチェックはするにしても、Validatorで少しでもエラーがないようにするにしても。
そこにこだわってるヒマがあったら、コンテンツの充実や情報設計というか動線やラベリングについて検討すべきだろうと思う。
もちろん、エラーや警告が許されないものもある。上記はWEBサイトについて(念のため)
たとえば電子書籍(EPUB)の納品はシビアで、エラーはひとつでもあったらアウトだ
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» web(157)
paypalを使って電子書籍のダウンロード販売
電子書籍元年が何度もきたおかげで、電子書籍(デジタルコンテンツ)のダウンロード販売がDRMもついてAmazonや楽天kobo、iBookstore、KADOKAWA☆BOOKWALKERに並べることができる時代となった。
また、電子書籍専門というわけではなく、デジタルコンテンツをダウンロード販売できるサイトも百花繚乱雨後筍で、コンテンツさえ用意できれば個人で簡単に販売ができる。
「デジタルコンテンツをダウンロード販売できるサイトを比較してみた」
http://writing-san.blog.jp/archives/32017213.html
また、ワードプレスにはダウンロード販売のためのプラグインまであって、販売チャンネルの選択肢はたくさんある。
「Easy Digital Downloads - ダウンロード販売サイトを簡単に作れるWordPressプラグイン」
http://netaone.com/wp/easy-digital-downloads/
集客力販売力、販売手数料や手間ひまを考えて自分に合うところにコンテンツを置けばいいし、そうすれば販売ページへのURLや購入ボタンをSNSや自分のサイトに貼りつけて告知できる。
ぶっちゃけ、わざわざ自分でダウンロード販売の仕組みとか作るのは時間と労力の無駄なのでオススメしない。
面白そうだ、という好奇心自己満足。それと、もしかすると、何らかの事情で他社サービスにコンテンツを置くわけにはいかないような場合に。
てことなので、以下はわたしの技術メモ。備忘録。
内容的には2010年の雑記とPayPalとのやり取りなどはほぼ同じ。
「paypalと電子書籍のダウンロード販売（その１）」
http://t2aki.doncha.net/?id=1277017233
「paypalと電子書籍のダウンロード販売（その２）」
http://t2aki.doncha.net/?id=1277130006
今回の雑記では自サバ側のこともメモしておく。
【じぶんちでの設定】
コンテンツをサーバーの所定のフォルダにアップロード。
サーバーのデータベースにコンテンツの商品登録。ここで商品にIDを付ける。
以下3つのスクリプトを用意
・ご購入ありがとうございますページのスクリプト
・IPN受信&データベース登録用のスクリプト
・ダウンロード用スクリプト
【PayPalでの購入ボタン作成・各種設定】
「トップ」→「販売ツール」のメニューにある「売り手の設定」から
→「PayPalボタン」
[今すぐ購入]サンプルボタンあたりを雛形に「ボタンの編集」で商品名や値段などを入れる。ここではオプションの商品ID（＝データベースで決められたID）を入れるのを忘れずに。
ボタンを作ったら「コードをコピー」して自分のサイトの購入ボタンを設置したいところにコードをペーストする。
→「ウェブサイトの設定」(ウェブペイメントの設定)
・ウェブペイメントの自動復帰「オン」
・復帰URL：ご購入ありがとうございますページのURLを記入
・支払いデータ転送「オン」※IDトークンをコピーしておく
・暗号化されていないウェブペイメントの受領拒否「オフ」
・PayPalアカウントオプションサービス「オン」
・連絡先電話番号「オフ」
・エクスプレスチェックアウトの設定「いいえ」
→「即時支払い通知」(IPN)
・通知URL：IPNを受信するスクリプトのURL
・メッセージの配布：有効
→「PayPalボタンの言語コード化」
・「詳細オプション」→「UTF-8」
【PayPalとのやりとり】
ユーザーの動きは以下の3つ。
1)ユーザーがオレオレサーバーの購入ボタンをクリックすると
2)PayPalの決済ページに飛んでそこでお支払い
3)お支払いが終わるとオレオレサーバーの購入ありがとうございましたページに戻ってくる。
ユーザーのお支払い終了と同時にPayPalからオレオレサーバーに購入データが飛んでくる。
購入データは以下の2種類。
データを取得して解析するためのサンプルコードがPayPalに用意されていて、そのまんま利用させてもらう。
3)PDT(Payment Data Transfer)
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・ユーザーが購入ありがとうございますページにリダイレクトされてくる時に、トランザクションを持ってアクセスしてくる
→オレオレサーバーからPayPalへ
・トランザクションと管理ページの「支払いデータ転送」の項目に記載されているIDトークン、コマンドをPOSTでPayPalにリクエスト
→PayPalからオレオレサーバーへ
・POSTした内容が正しければ一行目に「SUCCESS」と書かれたデータを返してくる
このPDTデータは
SUCCESS
first_nameJane+Doe
lst_name=Smith
payment_status=Completed
など、1行にひとつ「ネーム＝バリュー」形式、NVP形式のデータとなっている。
※ユーザーが支払いを終えて待たずにすぐブラウザを落としたりするとデータ取得できない。購入ありがとうございますページにリダイレクトされてやってきて初めてデータのやり取りが生じる。
PDTデータ取得＆解析のサブルーチン
※HTMLデコードと文字コードをutf8にしているところ以外はサンプルコードのまんま。
PDTデータのpayer_emailやitem_nameなどを「ご購入ありがとうございます」ページの「～様」や「～をご購入いただきありがとうございました」などの個別の表示に使う。
PDTデータのitem_number(商品ID)でダウンロード商品なのか、別の商品なのかを判定して、ダウンロード商品の場合はダウンロードURLを表示する。ダウンロードURLはユーザーのemailやtransactionidなど一意のものから作成している。
4)IPN(Instant Payment Notification)
ユーザーから見える言わば表側のPDTと違って、こちらは裏側。
ユーザーがお支払いを終えると管理ページで指定したURLにデータが飛んでくるので取りこぼしがない。
PDTはユーザーに見せるご購入ありがとうございますページに使う程度で、オレオレサーバーのデータベースに購入の記録を残すためにはこちら、IPNを使う。
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・購入データが送られてくる。いわゆるWEBのフォームデータで「&」で繋がれた「ネーム＝バリュー」形式
→オレオレサーバーからPayPalへ
・送られてきた購入データにコマンドをひとつつけてPayPalにPOSTする
→PayPalからオレオレサーバーへ
・「VERIFIED」か「INVALID」か一行返ってくる。これ以外は調べる必要があるらしいが滅多になさそうだし、PayPalの管理画面で確認すれば良い。
IPNデータ取得＆解析のサブルーチン
エラーはIPNのデータをつけてメールするように。
VIRIFIED(データが正しい)場合でも以下の4点を確認する。
・支払いのステータス「payment_status」が完了「Completed」であることを確認
・すでに完了した取引の悪用防止のために「txn_id」が過去のものと重複していないことを確認
・不正アカウントに支払いされないように「receiver_email」がPayPalアカウントに登録したメールアドレスであることを確認
・価格が変更されていないか確認(商品IDなども)
確認できたらオレオレサーバーのデータベースに必要情報を登録して、ユーザーにお礼とダウンロードURLを書いたメールを送信する(自分にも同じものを送信)
※データ確認の部分やメールの部分以外はサンプルコードのまんま。
【ダウンロードについて】
ダウンロードはダウンロード用のスクリプトがファイルを返すようにしてある。
たとえば、わたしが自分だけで作ったコンテンツなんかはどうでもいいんだけど、表紙が依頼原稿だったり、アンソロジーでほかの人の原稿が入っていたりするとそうもいかない。回数や期間を無制限にするわけにはいかない。
なので、ファイルの置き場所＝URLをそのままユーザーにお知らせできない。
ダウンロード用のスクリプトを噛ませて
・ダウンロードのURLは購入者ごとに違うものを作る
・ダウンロード回数を制御する
・ダウンロード期間を制御する
といったことを仕込んだ。
また、ダウンロードごとにIPやUserAgentを記録すれば、不正なアクセスやダウンロードできない事故などの問題解決にも役立つ。
以前の雑記にも書いたように、PayPalは管理ページに記録が残ってるし取引が生じたらいちいちメールも飛んでくるので、致命的な問題にはならないはず。サポートもびっくりするというか恐縮するぐらいに厚い。
残念なことに(法律的に？)日本では単純にクレジットカードだけで支払いはできなくなった(ペイパルへのアカウント・会員登録が必須となった)けど、個人での少額決済に手軽に使えるので助かるなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
なろうをタテにしてEPUB3電子書籍でヨム
カクヨムをEPUB3の電子書籍に変換してダウンロードするスクリプトを書いたんだけど、カクヨムはR18禁止なのでR18がOKのなろうに退避するケースもあるとかないとか。
カドカワもTL(ティーンズラブ)小説があったような気がするけど、エロではない、ということかな。
てことで、なろうに上がっている小説をEPUB3に変換してダウンロードするスクリプトをでっち上げた。
ttp://ncode.syosetu.com/XXXXXXX
↑小説トップページ(?)目次ページのURLを入力すると電子書籍としてダウンロードできます。
とはいえ、なんだかなろうは商標についてのページや利用規約やガイドラインなんかを見るとどうもややこしいところのようなので(印象)、ダメっぽかったら取り下げます。悪しからずご了承くださいませ。
https://t2aki.doncha.net/tmp/narou2epub.pl
↑例によって直リンクできないフォルダなのでこちらのリンクからどうぞ。
ちなみに。
なろうを電子書籍化するサービスやアプリはすでにあるので、ニーズにあったものを探して利用してみましょう。ウチのより高機能。
「なろうを電子書籍化」WEBサービス
http://narou.nyanpass.jp/
「Narou.rb」rubyアプリ
https://github.com/whiteleaf7/narou/wiki
「AozoraEpub3」javaアプリ
http://www18.atwiki.jp/hmdev/pages/21.html
カクヨムを電子書籍に変換してダウンロードするページはこちら
https://t2aki.doncha.net/?id=1457873699
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(102) » 電子書籍(278) » perl(106) » web(157)
カクヨムをタテにしてEPUB3電子書籍でヨム
時事ネタ。
カクヨムの作品URLを入力したらEPUB3の電子書籍としてダウンロードできるようにしてみた。
カクヨムに上がっているWEB小説をEPUB3ファイルにすることで、KindleやiBooks、Kobo、Knoppy(紀伊国屋)、hontoなどの電子書籍リーダーやアプリで読むことができる。
サイトをクロールしてEPUB3にパッケージするスクリプト程度なら手元の部品の継ぎ接ぎでそれっぽいのができるので作った。
（カクヨムのHTMLの構造が変わったらそれまでだし、たぶんカドカワのことなのでそのうちEPUB3変換のクチも別メニューで出てきそうで、メンテするのも不毛なのでこれっきりの一発ネタだろう）
https://t2aki.doncha.net/tmp/kakuyomu2epub.pl
↑カクヨムを電子書籍にしてダウンロード
※直リンクできないフォルダなので、ご利用の場合はこのリンクからよろしく。
アンドロイドのスマホでダウンロードできないことがあるけど、アンドロイドアプリのFirefox（https://play.google.com/store/apps/details?id=org.mozilla.firefox&hl=ja）ならダウンロードできます。それ以外、PCやMac、iphoneなどは問題なくダウンロードできます。
カクヨムは横書きのサイトなので半角の英数字などは縦書きにしても寝転がったまま…うーん、こりゃしょうがあるまい。
(かなりテキトーなでっちあげ)
[2016/03/15 16:15:01] 追記。
連続する半角数字以外に、半角の「!?」「?!」「!!」に縦中横のスタイルを当てるようにした。
[2016/03/19 10:59:01] 追記。
それっぽい奥付生成。
完結したストーリーの本文を取りこぼすバグ修正。
[2018/05/22 21:44:12]
カクヨムのHTMLが変わっていて目次を取得できなくなっていたのを修正。
また、一部の文字(実体参照)は面倒なんで削除することにした。
なろうを電子書籍に変換してダウンロードするページはこちら
https://t2aki.doncha.net/?id=1460978141
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(102) » 電子書籍(278) » perl(106) » web(157)
ブログの立ち読みサンプルを縦書き段組にする
Kindleの無料サンプルを縦書き段組にして表示するというのをやってみて、ついでに、「はてな」などのブログ記事掲載のサンプルを縦書き段組にしてみた。
CSS3のマルチカラムは縦書きの段組には(現状)使えないので、段組の一カラムずつの塊を返す（レイアウトデザインを崩さずコントロールするためにはこの方法しかなさそうだ）
百聞は一見に如かず。
「はてな」
http://t2akii.hatenablog.com/entry/2016/02/15/182240
「HTML直書きのサンプルページ」
http://sandbox.doncha.net/sample-tategumi.html
「はてな」を例にしてみると。
その1。
ブログ記事を「編集 見たまま」で作成する。
その2。
表示させたい立ち読みサンプルを、テキストエディタ(sakuraやxyzzy、秀丸、miやcoteditorなどなど)で開いて、コピー。
その3。
「編集 見たまま」で、立ち読みサンプルをペーストする。
そうしたら「HTML編集」に切り替える。
赤い部分がコピペした立ち読みサンプル部分。
その4。
このコピペした立ち読みサンプルの冒頭の「＜p＞ 神さまに会いに行く」の「＜ｐ＞」の部分に「HTML編集」の状態で以下を記入する
赤い部分
<p id="sample-tategumi" data-cols="28" data-lines="20">
のように編集。
・data-colsは一行の字数
・data-linesは一カラムの行数
その5。
以下のコードを立ち読みサンプルの下あたりに貼り付け。
HTMLに書きこまれたテキストを縦書きにするだけなので、立ち読みテキストがグーグルさまなどの検索エンジンにちゃんと拾われるのもお得な感じになった、かも。
HTML的なことをいうと。
idがsample-tategumiの要素の中のテキストを縦書き段組にするので、pタグだけじゃなくてdivタグなんかでもOK。
…にしても、wordpressもはてなも、CMSってのは余計なお世話が多いなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
