AmazonだとかiPadだとか、黒船到来、という論調ばかりが目につく。

けどなあ。

電子書籍と言ったところで、PDFの文書は昔っからあるし、ケータイとかPalmとかXMDF形式とかドットブック形式とか昔からある。今に始まったことじゃない。

セルフパブリッシングと言ったところで、コミケに代表されるように同人誌の規模は大きくて、参加してる連中は印刷された本を作ってイベントという公共＝パブリックなところで売っている。今に始まったことじゃない。

「電子書籍でセルフパブリッシング」と言っても、新しいことなんてなにも言ってない。ネットが絡むから新しい？ネットで自作を販売している作家さんもすでに多数。

なのに、この騒ぎはナニ。

イベントで直販する分にはその範囲内なのでいいんだけど、AmazonやAppleを通じて電子書籍を直販するとなると、取次がすっ飛んでしまう。そこが騒ぎの根源。どの業界も流通をつつくとこうなる、てことか。

零細出版社でエロ漫画編集なんてのをしてた頃、取次の部数調整にずいぶんムカついてたりしたので、取次がすっ飛ぶ分にはむしろ喜ばしいところ。（Amazonに並んでいる書籍雑誌は取次経由だけど、なんで取次を経由するのか。版元が直接Amazonに卸せばいいのに、と当時思ってた）

作家のブランディングやPR、保護、作品作りのサポートを考えると、出版社はなくなることはないし、玉石混淆で作品があふれてくればくるほど出版社ブランドは強くなる。

電子書籍だネットだと言ったところで、たとえばわたしの実家はそんなもの無縁。本や雑誌を買うのは地元の本屋さんだ。紙の本がいきなりなくなるとは思えないので、本屋さんの存在感は相変わらず、だろう。

いらないのは日販トーハン栗田大阪屋大洋社その他の取次だけじゃん。というか、今の規模の取次なんてのは不要になるだけの話じゃないのか。見合った規模に取次を統廃合する、だけで今回の騒動は収まるような気がしてきた。電子書籍がAmazonやAppleの店頭に並び、それと同様、本屋さんにも紙の新刊が並ぶ、どちらも成立するソフトランディングというか。

てなことをぼーっと考える梅雨空の日曜だ。

一連のそんなこんなが元となって、電子書籍とダウンロード販売の仕組みを作ろうというモチベーションになった、のは感謝。

・同人誌が何冊もあるんだけどイベントばかりじゃないし。なら自分で出してしまえ。

・部数がとれなくて本が出せない、と。なら自分で出してしまえ。

個人でクレジット決済できる販売ページを作っても、最大の難関、ブランディングとか集客とかが残ってるけど、まずは第一歩。

http://books.doncha.net/hino-yutaro/

[更新]2026-02-03 09:19:00

ということで、知人、というか身内の同人誌ダウンロード販売ページを公開した。DRMフリーの電子書籍というかPDF、３００円均一。

下町飲酒会駄文支部 日野祐太郎

この中では、「Vanish」!が完成度も高く抜けた傑作。次のグループが「あかるいほうへ」「アロイのやさしい神さま」。「猫神リスペクト」が佳品で、「赤貧遁走曲」はエピソードの長さがいちいちもったいない。

といったところかな。

ぜひ一度読んでみてください。身びいきをさっ引いても、かなりおもしろい小説群です。

[更新]2012-06-19 17:04:07

その０．

購入ボタンはこんな感じ

<form name="_xclick" action="PAYPALSERVER" method="post">
<input type="hidden" name="cmd" value="_xclick" />
<input type="hidden" name="business" value="EMAILADDR" />
<input type="hidden" name="currnecy_code" value="JPY" />
<input type="hidden" name="item_name" value="ITEMNAME" />
<input type="hidden" name="item_number" value="ITEMNUMBER" />
<input type="hidden"  name="amount" value="100.00" />
<input type="image" src="PAYPAL PURCHASE BUTTON" />
</form>

item_number以外は必須。item_numberも、商品IDとして使うので、わたしの場合は必須。ユーザーがPaypalから戻ってきたとき・Paypalから即時通知があったときに、この商品IDでデータベースに照合する。

あらかじめ、Paypalで個人設定を仕込む。（以下とは別に、文字コードを日本語、UTF8に設定しておいた）

その１．

「ウェブペイメントの設定」

→自動復帰 オン

→復帰URL ユーザーが帰ってくるURLを設定

→支払いデータ転送（PDT） オン

→暗号化されていないウェブペイメントの受領拒否 オフ

購入ボタン自動生成で暗号化してないので、最後の設定はオフにしておく。

購入ボタンをクリックしてPaypalにいったユーザーが支払いを完了して「マーチャントに戻る」リンクをクリックしたら、復帰URLにパラメータを持って戻ってくる。それをスクリプトで解析する。以下はほぼほぼPaypalにあるサンプルコード（perl版）まんま。

    my $query  = join(’&’， "cmd=_notify-synch"， "tx=$form->{tx}"， "at=PAYPAL_AUTH_TOKEN")；
    my $ua  = new LWP::UserAgent；
    my $req = new HTTP::Request("POST"， PAYPAL_SERVER)；
    $req->content_type("application/x-www-form-urlencoded")；
    $req->content($query)；
    my $res = $ua->request($req)；
    return if($res->is_error)；

    my @response = split("\n"， $self->html_decode($res->content) )；
    my $status = shift(@response)；
    my %tx；
    if($status eq "SUCCESS"){
        foreach( @response){
            my ($key， $val) = split("="， $_)；
            $tx{$key} = $val；
        }
        return \%tx；
    }
    else{
        return；
    }

戻ってきたら、GET でパラメータ＝トランザクションIDを取得して、Paypalの管理ページ、個人設定にある、auth tokenと、定型のコマンドとともに、PaypalのサーバーにPOSTでアクセス。

そこで取得できるcontentを改行でばらして一行ずつ、って先頭の行がSUCCESSであればOK。それ以外だと決済が完了していないので、どうなってるのか調べる必要がある。

というのが「PDT」というヤツ。

ところが、これはユーザーが「マーチャントに戻る」というリンクで戻ってくれないと、情報が何も取得できない。もちろん、Paypalの方からメールがくるし、Paypalの管理画面を見れば、取引状況はわかるので、調べてユーザーに返事を出すこともできる。

でも、今回やりたいのはダウンロード販売。

支払いが終わったらすぐにダウンロードページに行きたいよね…といいつつ、Paypalの「マーチャントに戻る」リンクがまるで目立たない。これじゃ、ユーザーはここでブラウザを閉じて終了、だろう。現に戻ってくる率は２０％もない、という記事もどこかで見かけた。なので、こちらは、もしユーザーが戻ってきたら、ありがとうございましたとか、確認にしばらくお時間くださいとか、表示を選択するためのモノとして使う程度。

そこで、以下のIPN（支払い即時通知）の出番。

その２．

「即時支払い通知（IPN)」

→通知URLを設定

支払いが生じたらPaypalから、通知URLあてに、パラメータを抱えてアクセスがある。それをスクリプトで解析。以下はサンプルコード（以下同文）

    my $query；
    read (STDIN， $query， $ENV{’CONTENT_LENGTH’})；
    $query .= ’&cmd=_notify-validate’；

    my $ua = new LWP::UserAgent；
    my $req = new HTTP::Request("POST" ， PAYPAL_SERVER)；
    $req->content_type("application/x-www-form-urlencoded")；
    $req->content($query)；
    my $res = $ua->request($req)；

    my $cnt = 0；
    my %ipn；
    my @pairs = split(/&/，$query)；
    foreach my $pair ( @pairs ){
        my ($key， $val) = split(/=/，$pair)；
        $val =~ tr/+/ /；
        $val =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C"，hex($1))/eg；
        $ipn{$key} = $val；
        $cnt++；
    }
    if( $res->content eq ’VERIFIED’ ){
        my $err；
        $err = 1 if($ipn{’payment_status’} ne ’Completed’)；
        $err = 1 if($ipn{’receiver_email’} ne MY_PAYPAL_EMAILADDR})；
        $err = 1 if($ipn{’mc_currency’} ne ’JPY’)；
料金などのチェック
        if( $err ){
            open(OUT， ’>>’ . ’_err.txt’) || die；
            foreach (keys %ipn){ printf OUT qq{[KEY]%s ::: [VAL]%s\n}， $_， $ipn{$_}； }
            close(OUT)；
        }
        else{
エラーがなければデータベースに登録したり
ユーザーにメールを出したり
        }
    }
    else{
        open(OUT， ’>>’ . ’_err.txt’) || die；
        foreach (keys %ipn){ printf OUT qq{[KEY]%s ::: [VAL]%s\n}， $_， $ipn{$_}； }
        close(OUT)；
    }

POSTされたパラメータをそのままに、コマンドを付加して、Papalに返すと、パラメータが正しいか間違ってるかだけ教えてくれる。パラメータが正しければ、料金を確認したり、トランザクションIDをチェックしたり。エラーがあったら、ログを吐き出し、正しければデータベースに登録してユーザーにダウンロードURL案内のメールを出す。

わたしはperlが少しわかる程度。それでもサンプルコードどおりに書けばほぼOK。ダウンロード販売ということで、データを受けてデータベースを使って商品を特定したり、ダウンロードURLを作ったり、というところがちょっと面倒だけど、難しいもんじゃない。

最悪、うまくいかないケースが生じても、Paypalからメールが来るし、Paypalの管理ページに行けば履歴を確認したりキャンセル処理ができるので致命的なことにはならない、はず。

それに、ダウンロード販売なので、面倒な在庫管理は不要。

ちなみに、無責任なことに、これを書いてる時点ではまだ本番でのテストはやってないので、あしからずご了承いただきたく。忘れないうちに自分メモ。

原稿があるなら、Paypalを使って、ダウンロード販売ですよ。たぶん、儲けるのは無理だけど、原稿を塩漬けにしてるぐらいなら、ネットに並べておいてもいいんじゃね、と。個人書店があちこちにできて相互にリンクできれば宣伝にもなって面白いんだろうから、お手伝いしますよー。

小説や漫画など、電子書籍を作るのは簡単。問題はどうやってそれを売るのか。

「ホームページに並べて・購入してもらって・ダウンロードしてもらう」

というのをどうすんだよ、てことで調べてみたメモ。

（ちなみに、作った電子書籍はDRMなしのPDFファイル）

結論から言うと。

Paypalのプレミア（以上の）アカウントを作れば、個人でも簡単にクレジットカードを使った小額決済ができて、ちょっと仕組みを作ればダウンロード販売までできる。

Paypalのアカウントは固定費不要。クレジットカード決済に審査も不要。一度の決済手数料は40円＋3.8%～。驚く手軽さ気軽さだ。

ショップとユーザーの流れ

ショップを訪れたユーザーがページにつけられたPaypalの購入ボタンをクリックすると、Paypalの支払いページに飛ばされて、そこで支払い手続きとなる。クレジットカード番号やメールアドレスなどをPaypalに対して入力することとなる。Paypalの支払い完了ページに、「マーチャントに戻る」というわけのわからないリンクが目立たないようあるけど、これをクリックすると、ユーザーはショップに戻される。戻ってきたユーザーは、ショップが用意した「ご購入ありがとうございました」ページなどを見る。

こちらでユーザーを誘導する。

ショップの裏方（たとえばデータベース）とPaypalの流れ

それとはまた別に、Paypalは支払いが生じたら、ショップにお知らせしてくるので、それを元に、ショップはデータベースに登録したり、ユーザーにお知らせメールを発送したりする。

こちらでショップとして売買の確定をする。

上記のやりとりで、なにか不明点があっても、Paypalの管理ページを開いてみれば全部わかるので、後でチェックして対応することも簡単にできる。

Paypalとのデータのやりとりでは

「誰が何を買ったのか」

だけがわかればOK。というかPaypalの役割はここまで。

ダウンロードURLを作って、そこでダウンロードできるようにするのは、ショップ側で作ることになる。

PDTとかIPNのサンプルコードなどの具体例は、以下次号、かな。

# ページは、あとは、本番でのチェックと原稿の校正だけ、となった。

# 七月にはオープン予定で。

paypalを利用してのダウンロード販売ページは、ほぼ完成。デバッグとテストを繰り返しているところ。後は本番環境でひと通りやって、解説ページを作って、肝心の電子書籍＝PDFの校正をやれば正式オープン。

て、ことで、PDFを作り直してみたら。

dvipdfmxでフォントの埋め込みに失敗していた。

Could not locate a virtual/physical font for TFM ”rmlv”

Please check if kpathsea library can find this font

あーだこーだやって、ぐぐりまくり…拡張子を .otf から .ttc にリネームすればいいだけの話だった。がっくし。

paypalとダウンロード販売について、そのうちココに、メモを残しておこう。

[06/20 10:31:04]

って、一夜明けたら、また dvipdfmx のエラーが。なんでやねん。

[06/20 14:38:50]

うそっ！カレントディレクトリにフォントがないとダメ、てアンタなんじゃそりゃ。