初めてのchromebook購入
amazonのブラックフライデーという歳末大売り出しにつられて、ASUSのchromrbook (CX1101CMA-GJ0019)を購入。31000円ほど…て、これまたスマホより安いパソコンだ。これに追加でマイクロSDカードやBTマウス。
PCを新規に購入するなら、その最低必須条件は
・画面サイズが10〜11インチ
・CPUがインテル
で、安いに越したことはない、というのも入れると、Chromebookとなった。
必須条件の理由は。
自宅作業がローテーブルという名のちゃぶ台環境なので、デスクトップや大きなサイズのノパソは邪魔になるだけ。
インテルのCPU採用なら、メーカーのサポートが終わってもunix系OSをインストールして復活できる可能性があるから。
画面サイズで絞るとCPUがインテル以外のものばかりで、CPUで絞ると画面サイズが15とか巨大なものばかりが並んでた。
条件クリアしたのが、このASUS chromebook CX1。
画面:11.6インチ
CPU:intel Celeron N4020
メモリ:4G
ストレージ:64G(eMMC)
OS:ChromeOS
今、メインで使ってるのもASUSのvivobookというノートパソコン
「22980円のノートパソコンvivobook購入」
↑購入時のvivobookはWIN10だったけど、今はChromeOS Flexというgoogle謹製フリーのChromeOSで使ってる。
今回購入したCX1はキーボード配置などハードウエア的にも正規正統のchrombook。
これはフリーOSのFlexとは違ってgoogle playが使える。すべて対応してるかどうかはまだわからないけど、こちらの正規版（？）chromebookは、アンドロイドのアプリも使えるらしい。
さっそくlinuxをONにして、15Gほど割り当てて環境設定。
といっても、vivobookで使ってる設定ファイルをこっちに持ってくればほぼOK。
aptやcpanでインストールしたものも同じ。
「CloudReadyのバージョンアップ(94系から96に)」
↑メモっておいたことが珍しく役に立った。
CX1はストレージが64G。32Gのvivobookの倍だし、apache2もインストールしてローカルでWEBサーバーを立ち上げておくことにした。
vivobookでも最初は立ち上げてたんだけど、いろいろインストールするうちにディスク容量がちょっと心配になり、あまり利用する状況もなかったapacheは削除していた。
Chromebookのlinux環境（debian）のapache2はconfファイル（設定ファイル）が役割ごとに分けられてたり、以前もわりとハマったので、改めてメモ。
apache2のインストール
sudo apt install apache2
↑インストールはaptで一発。画面を眺めてるだけ。
インストールしたらまずやるべきこと。
・chromebook側
「設定」→「デベロッパー」→「linux開発環境」
→「ポート転送」
ここで、ポートを追加する。ポート番号は慣例的に「8080」が何かと無難。この設定はlinuxのコンテナを終了させるとOFFになるので立ち上げるたびにONにする必要がある。
・Apache2の設定
ターミナルでlinuxにログインして設定していく。
Apache2の設定ファイルは /etc/apache2/ 以下。
/etc/apache2/ports.conf
をエディタ（vim）で修正する。
Listen 80 → Listen 8080
変更したら、ターミナルでapache2を再起動。
sudo systemctl restart apache2
chromebook側で
https://localhost:8080
↑にアクセスして、デフォルトのスタートページが表示されたら問題なくapache2が動いている、というのを確認できてひと安心。
ここから以下、自分の環境に合わせてもろもろ設定していくことになる。
前提として。
・perlでCGIを使う
・任意のユーザーディレクトリでCGIを使う
・ローカルのサイトはSDカードで運用する
というのがあって、案の定ハマったりした。
・SDカードにシンボリックリンク
SDカードを差したらchromebookの「ファイル」アプリ
「USB Drive」という名前になっていてファイル名の半角空白は事故の元なので「USBDrive」に名前変更。
名前変更したら右クリックして「linuxと共有」する。
ターミナルで ls /mnt/chromeos/removable/USBDrive/
ができてたら、ローカルサイト用のディレクトリを作って、HOMEディレクトリにシンボリックリンクを作成すればOK。
・CGIを使うためのモジュールを設定
sudo a2enmod cgi
↑これでCGIが使えるようになる。
ちなみに。
apache2の設定ファイル群は「*-enabled」「*-available」というディレクトリに入っていて、
「enabled」が読み込まれている設定
「available」が利用できる設定
と分けられている。
利用したい設定をONにするのが
「a2enconf」「a2enmod」「a2ensite」
読み込まれている設定をOFFにするのが
「a2disconf」「a2dismod」「a2dissite」
（やってることはシンボリックリンクの作成/削除）
・apacheの実行ユーザーを変更
デフォルトだとapacheは「www-data」というユーザー、グループで実行する。このままでも問題はないんだけど、任意のユーザーディレクトリでCGIを実行するにはディレクトリやファイルの権限でひっかかって面倒くさい。
/etc/apache2/envvars
↑apache2の設定ファイルで使われる変数を設定しているファイルがある。
この中で実行ユーザー、グループが設定されているので
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
「www-data」を自分のユーザー名に変更すると、自分のHOMEディレクトリ以下でローカルサイトを展開できる（HOMEディレクトリ以下は、www-dataのままだと権限がないので、403エラーとなる）
・VirtualHostで設定
/etc/apache2/sites-enabled/
を見るとデフォルトの 000-default.conf
がONになっている。これを別名（mylocal.confとか）でコピーしてエディタで修正、編集していく。
修正が必須なのは以下の2点「VirtualHost」「DocumentRoot」を書き換える。
VirtualHost *:80 → 8080
DocumentRoot /var/www/html → /home/usrname/dir
8080番ポートに設定、ローカルサイトを展開するディレクトリを自分のHOMEディレクトリに設定。
公開するディレクトリの約束事をmylocal.confに追加記載する。
<Directory /home/usrname/dir/>
Options +ExecCGI -Indexes +FollowSymLinks
AddHandler cgi-script .cgi .pl
AllowOverride None
Require all granted
<IfModule mod_dir.c>
DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm
</IfModule>
</Directory>
「+ExecCGI」
このディレクトリでCGIを実行できるようにする
「AddHandler」
cgiファイルの拡張子は「.cgi」と「.pl」
編集が終わった「mylocal.conf」を /etc/apache2/sites-available/
にコピーして、その設定をONに設定、apacheを再起動して完了となる。
sudo cp mylocal.conf /etc/apache2/sites-available/
sudo a2ensite mylocal
sudo systemctl restart apache2
エラーになったら以下の２つで確認。
sudo systemctl status apache2.service
sudo less /var/log/apache2/error.log
…て、ほぼほぼ、configファイルのエラーなので、設定ファイルを作ったら
sudo apache2ctl -t
で、設定ファイルのエラーを確認するのが吉。
とりあえず今日時点ここまで、かなあ。
公開してるサイトをコピーして、ローカルで動作確認ができるようにしておきたいところだ。
ホッカペに湯たんぽに電気毛布まで。寒さ対策の達人。
[11/30 15:22:42] 追記
lolipopと同じように使うためにいくつか必要で。
perl の場所が違う
→/uer/bin/perl を /usr/local/bin/perlにリンク
DocumentRootが違う（当然）
→/home/以下にディレクトリを作って、本体のあるSDカードのディレクトリにリンク
perlで足りないモジュールのインストール
JSON
→cpanでインストール
imagemagick
→cpanだとエラーになるので、apt install perlmagickで取得
DBD::SQLite
→cpanでインストール
とりあえず。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ブラウザでバーコードをスキャンしてISBNを取得する
2006年公開のWEB本棚「趣味は読書２」のスマホ版にバーコードをスキャンして本を登録できるようにしたのでメモ。
このWEB本棚は、なんだかんだ15年以上続けていて、最初は自宅で組んだパソコンをサーバーにして公開してたんだけど、東日本大震災があって、計画停電とかいつ停電してもおかしくない状況というのがあって、レンタルサーバーに引っ越し、現在にいたる。
WEB本棚「趣味は読書2」 https://doncha.net/
もともと自分で使うことを考えてたので、既読・未読がわかって、簡単なメモやカテゴリをつけられればいいので、機能的には十分足りてる。
ただ、1冊ずつISBNを手入力するのがちょっと面倒くさい。ガサツなわたしはISBNをタイプミスしてエラーになることも少なくないし。
なもんで、後づけで、アマゾンの検索結果を一覧にしてチェックしたものを本棚に登録できるようにして使ってたら、2019年のAPIの利用規定改定でアフィリエイトで売上のないアカウントはAPIを利用できないということになった。当然アフィリエイトの売上などないわたしは、APIを利用した検索結果からの一括登録ができなくなってしまった。
これを作った当初の状態に戻っただけなので、まあしょうがないな、ぐらいな感じ。本を買っては／読んでは、ちまちま本棚に登録していた。
てな昨今だったわけだけど。
イーロン・マスクがTwitterを買って、何かと騒がしいので、以前アカウントを作っていたマストドンに久しぶりにログイン。
ここは本好き、本読みのひとが集まるサーバー（インスタンス）で、流れてくる話も小説がらみが多くて静かに面白い。本の整理、積読なんかの話も流れてくる。
本好きの集まるマストドンはこちら
Bookwor.ms
それに刺激されて、ふたたびだかみたびよたびだか、WEB本棚の見直しをしてみた。
機能的には満足しちゃっていて、データベースの構造もシンプルで必要十分、昔の自分をちょっと褒めてもいいかもだった。
UIを含めたデザインが古臭くて気に入らない。でも、変更するとなると、かなり面倒くてさすがに手をつける気合気力体力がない…IE対応なんかのスタイルシートも混じってて、そのうち考えないとなあ。
スマホ版も見直しかな、とスマホでログインして触ってみて、そういやISBNの入力をバーコードスキャンでやりたいと思ってたんだと。
さっそく検索してみた。
…て、ここまで、自分でもびっくりするぐらい無駄なまえがき、無用なゴタクが長くてすまん。もう爺、老人なもので許してください。
ブラウザからスマホのカメラを使うためのjavascriptライブラリも公開されていた。
Quagga.jsというライブラリで、公式ページはこちら→ QuaggaJS
javascriptも詳しくないし、読み取り精度をあげるためには、HTML5あたりのcanvasも使う必要があるらしい。
あちこち実装されてるかたのサイトを拝見しては、ちょっとずつ試して試して、最終的にこちらのサイトに助けられて、どうにかISBNのバーコードスキャンに成功。
QuaggaJSを使ってブラウザでバーコードスキャン：なんぶ電子
ほんと、こちらのページには感謝しかない。
テストページでいろんなコードを試してまる一日。javascriptだけじゃだめで、canvasも使う必要があるのが大騒ぎで、javascriptが意図通りじゃないのか、それともHTML的な問題なのか切り分けるのに時間がかかった…って、どっちも自分のスキル不足が原因なんだけど。
WEB本棚「趣味は読書２」スマホ版 https://doncha.net/sp/
WEB本棚「趣味は読書２」ついて https://doncha.net/about.pl
WEB本棚「趣味は読書２」で出来ること https://doncha.net/about.pl?c=help
たぶん、小学校の頃、自動車文庫（移動図書館）がなければ、いまの自分はなかった。
ほんと、小説は面白いぞー！
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
winmergeという神ツール
バージョン管理ツールというのがある。
バージョン管理ツールというのは「テキスト」の変更履歴を管理するツールのこと。
今日時点だとネットではgitが決定版と言われていて、ほかにもCVSやsvnなんてのもある。
このあたりは、ひとつのプロジェクトをチームで動かしているようなケースでは必須のツールだろう。実際にFreeBSDやlinuxなどOSのソースコードはこの手のツールで管理運用されている。
ただ、個人で、ひとりの作業で使うにはどうだろう。
これからはgitだ、というんでインストールしてみたものの、個人でちまちまやってる分には大袈裟すぎて管理のための管理作業が発生して面倒なだけだった。仕事で他の人が管理しているツリーにメンバーとして参加、コミットしたりとか程度でがっつり使ったこともないし、実際のところはよくわかってない。
とはいえ、
「納品20210110.zip」
「納品20210110b.zip」
「納品20210110-修正1.zip」
「納品20210110-修正0115.zip」
ということもよくあって、変更履歴の管理はさすがに痛感しているので、納品後の修正や差し戻しがあったら(って、なんでやねん、という話だけど)ディレクトリごと別ディレクトリとしてコピーして作業するようにしている。
こういう時に、もう10年ぐらい重宝しているのが、winmergeという差分確認、マージ(差分擦り合せ)のためのツールだ。
https://winmerge.org/
これがなければ仕事にならないし、これのためにWINDOWSを使い続けている、といっても言いすぎじゃない。
神ツールとはまさにwinmergeのことを言う。
2つのファイルの差分をチェック
百聞は一見に如かず。
ふたつのファイルで違いのある箇所が左側のルーラーの黄色の部分。
メインの左右画面では違いのある箇所が赤く表示される。
差分、変更箇所がすぐに目視できる。差分のある箇所を個別にどちらかに合わせることもこの画面ですぐ、だ。編集されて上書き保存されたら元ファイルは拡張子が.bakになって保存される。
これはeasy_epubという電子書籍作成スクリプトのソースコード。
左側がオリジナルのリフローEPUB用、右側がハイブリッド対応版
無駄に機能追加したり、つぶしきれないバグフィックスをするたびに、別フォルダにコピーして修正。修正したらwinmergeで修正箇所、修正漏れの確認をして動作確認。動作が意図どおりじゃない時などもwinmergeのおかげで修正箇所の洗い出しが一発なので楽チン。
ディレクトリごとの比較
winmergeにファイルではなくてディレクトリを指定して読みこませると、ディレクトリ内で違いのあるファイルがこれまた一目瞭然。
違いのあるファイルが黄色くハイライトされている。
これはdoncha.netのサイトの一部。スクリプトやhtml、css、javascriptなどいろんなファイルがてんこ盛り。
webの場合、デザイン変更ひとつ取ってもhtml、構造の変更なのか、css、見た目のデザイン変更なのか、そのためにスクリプトやデータベースの変更は必要なのか、などなど、いろいろ絡んでくる。どのファイルを変更しなきゃいけないのか、実際どのファイルを変更したのか。
winmergeが一目で教えてくれる。
差分のあるファイルを選んでクリックすると２つのファイル比較となり編集更新ができる。
テキストの変更箇所、差分を教えてくれる、直感的で超絶便利なツールがこのwinmergeだ。
ということは。
プログラムとかエンジニアだけのものじゃなく、webのソースとかデザイナーだけのものじゃなく、テキストを扱うすべてのひとにとっての神ツールということだ。
小説書き、モノ書きのひとにとっても、語尾や用語を合わせる前後や、追加エピソードやセリフの確認とその比較に使える。
一太郎やワードはさらにモノ書きに特化した機能満載だから、それで間に合っているかもしれないけど、一太郎もワードも入っていないパソコンもあるしね。
gitやsvnのように更新、変更履歴を追うことはできないけど、winmergeさえあれば、個人でやる仕事については、万全磐石の安心感。
だがしかし、めちゃくちゃ残念なことにwinmergeはWINDOWS版しかない。macにもchromebookにも当然ない。
わたしの弁当箱macはすでに最新のOSアプデ対象外となっていて、今はただの鉄の箱だからいいとしても、去年末あたりから使い始めたchromebookで使えないのは致命的。このchromebook化したASUSのvivobookで委託のWEB運用、請負の電子書籍制作をやっていて、特に電子書籍の方はwinmergeでの作業がはいる。
原本、底本の元データと電子書籍化したEpubデータの差分チェックは欠かせない。
作成中にルビを取りこぼしたり、全角の空白を潰したりしてしまうこともあるし、修正依頼に対応したら修正の必要がない箇所に影響したり、などなど確認項目は多岐に渡る。
そのためだけに、WINDWOS機を起動してwinmergeで確認してたんだけど、さすがにどうにかせんといかんなあ、と必死のぱっちでぐーぐる先生。
「漢」ならdiffで頑張れ
とか言われてるんだけど、いくらなんでも無茶すぎ。そこでvimの出番となった。
エディタのvimがほぼ万能で、こいつもできないことを探すほうが難しいやつ。
vimdiffという差分チェックができるモード(？)がある。見た目もwinmergeとほぼ同じ、ていうか、vimdiffの方が先だろう。これで、ディレクトリ内のファイルの比較もできればなあ、と。
たぶん、いや、間違いなくvimだけでできると思うんだけど、わたしにそんなスキルも時間もないので、diffでディレクトリ比較した結果を適当に整形して読みこんで画面分割してやってみることにした。
winmergeほど便利じゃないんだけど、やりたいことはほぼこれでできることとなった。
ちなみにvimについては
https://knowledge.sakura.ad.jp/23018/
↑こちらのサイトがおすすめ。
しかしなあ。
21世紀にもなって、ラクをしようとするな、ツールなんか信用するな、というクズな仕事場もあって心の底から呆れるばかり。どうぞそのまま滅んでくださいとしか。
» ローカル環境で電子書籍を作る、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」
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」
paypalを使って電子書籍のダウンロード販売
電子書籍元年が何度もきたおかげで、電子書籍(デジタルコンテンツ)のダウンロード販売がDRMもついてAmazonや楽天kobo、iBookstore、KADOKAWA☆BOOKWALKERに並べることができる時代となった。
また、電子書籍専門というわけではなく、デジタルコンテンツをダウンロード販売できるサイトも百花繚乱雨後筍で、コンテンツさえ用意できれば個人で簡単に販売ができる。
「デジタルコンテンツをダウンロード販売できるサイトを比較してみた」
https://writing-san.blog.jp/archives/32017213.html
また、ワードプレスにはダウンロード販売のためのプラグインまであって、販売チャンネルの選択肢はたくさんある。
「Easy Digital Downloads - ダウンロード販売サイトを簡単に作れるWordPressプラグイン」
https://netaone.com/wp/easy-digital-downloads/
集客力販売力、販売手数料や手間ひまを考えて自分に合うところにコンテンツを置けばいいし、そうすれば販売ページへのURLや購入ボタンをSNSや自分のサイトに貼りつけて告知できる。
ぶっちゃけ、わざわざ自分でダウンロード販売の仕組みとか作るのは時間と労力の無駄なのでオススメしない。
面白そうだ、という好奇心自己満足。それと、もしかすると、何らかの事情で他社サービスにコンテンツを置くわけにはいかないような場合に。
てことなので、以下はわたしの技術メモ。備忘録。
内容的には2010年の雑記とPayPalとのやり取りなどはほぼ同じ。
「paypalと電子書籍のダウンロード販売（その１）」
https://t2aki.doncha.net/?id=1277017233
「paypalと電子書籍のダウンロード販売（その２）」
https://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」
