機械太郎の東京静止空間

紙の書籍に最初から“自炊”データ付けて売っちゃえよ

紙の書籍にデジタルデータをつけて販売するとき、本当の読者を識別するにはどうすればいいか、を考えた。

デジタルデータはインターネットでウェブブラウザを使って閲覧・ダウンロードできるようにしておく。そのとき、「このユーザは確かに本書を購入した読者である」を“ほぼ確実に”識別する方法だ。簡便な方法として、書籍に印刷されたコード番号をユーザがブラウザから入力する、というのが考えられる。

このとき、コード番号がネットの掲示板なんかに晒されたら、コード番号の本来の意味がなくなってしまう。では、どうするか。

一つ考えられるのは、書籍に印刷するコード番号を一冊ずつ変えておく、という方法。この方法だと書籍本体にコード番号を印刷するのは難しいだろう。だからカバーの裏側なんかに印刷する方式になる。そのユニークなコード番号は、ネットでの認証では1回しか使えないようにしておけばいい。

ただし、カバーを汚損などで失ったときには使えなくなる。そもそもカバーの裏側にユニークな番号を印刷するという工程でコストが増える。

そこで、考えた。

書籍の全ページにランダムでユニークなコード番号を印刷しておけばいいんじゃね？

各ページにコード番号を印刷しておく。これは版下の段階で決めてしまう( 自動で )。つまり、出版された書籍には全く同じ組み合わせのコード番号が掲載されていることになる。そして、ネットでの認証で、「○○○ページのコード番号を入力してください」の質問に正解しないと閲覧やダウンロードのサービスを受けられないようにしておく。

たとえば、各ページの上下にランダムでユニークなコード番号を印刷したとすると、300ページの本の場合 600パターンのコード番号が載っていることになる。でもって、ネットでの認証での質問を 2個のコード番号を組み合わせて正解しないとパスできないようにしておけば、600×600＝360000パターンの認証に使えるというわけだ。30万部売れそうな本だったらこれで十分。3個の組み合わせにしてやれば600×600×600＝2億1600万パターン。こんなに売れる本はないだろう、ね( 暗算できなくて電卓出しちゃったよ )。

「○○○ページの上(下)のコード番号を入力してください」を 3回ということ。

ネットに晒すとしても、600パターンをページとの対応表でリスト化しないといけないのでコスト的に見合わないだろう。OCR読み込みが難しいように淡色で印刷するとか、ちょっと変わった字体にするとか、コード番号を縦書きだったり横書きだったりとか変えて難読化しておけばいいかも。

出版社側は、印刷前の版下データでコード番号の一覧表を持つことができるから、閲覧・ダウンロードのサイトでの認証システムなんてのは簡単にできそうだ。出版と同時にウェブでのサービスをスタートさせやすい。

こういう方法を使ってやれば、紙書籍→電子書籍への時代の変化にソフトランディングできるんじゃない？　“自炊”なんて面倒なことしないで済むし、読者的には歓迎なんだけど。

※300ページの場合、正確には2正解型で 600×599＝359400通り、3正解型で 600×599×598＝214921200通りなんだけど、ま、膨大な数をまかなえるということで。

【追記 2011/01/21】
参考： 「自炊の森」が店舗再開　大手出版社、自炊業者に対抗策も - ITmedia News
あ～、もう、いつまでこんなとこでガタガタやってんだ、という気分です。ていうか、「FREE」な世界に移行するだけの何かが決定的に欠けてるのかなぁ、と。

XML::FeedPP で複数のカテゴリがあるときはネスト対応する

なんか、また技術的メモ。

JapanLocal.info のトップページ右側に、このエントリが表示されるようにしているんだけど、これは tafworks.com (実はココログ) にポストしたエントリが自動表示されるようにしているだけ。エントリに「JapanLocal」というカテゴリがセットしてあったら、エントリデータを取得して JapanLocal.info の中に組み込む、という具合にしてある。

これまではカテゴリが単独の「JapanLocal」だったら取得できたが、別のカテゴリが同時にセットしてあると取ってこなかった( ていうより、そこまで頭が回らなかった )。が、複数カテゴリでも対応できるようにしてやろうということで、プログラムを少々改良した。

@niftyのココログにポストしたエントリのフィードを、さくらインターネットで perl使って取得している。ポイントは次のとおり( 必要なところだけ )。

　　my $feed = XML::FeedPP->new( $source ) or die;
　　foreach my $item ( $feed->get_item() ) {
　　　　my @i_category = $item->category();
　　　　my $chk_categ;

　　　　if(@{$i_category[0]} == 0){
　　　　　　$chk_categ = @i_category[0];
　　　　}else{
　　　　　　$chk_categ = join("\t",@{$i_category[0]});
　　　　}
　　　　
　　　　if(index($chk_categ, '何かキーワード')>-1){
　　　　　　# 何か処理
　　　　}
　　}

( JapanLocal.info で読んでいる人は上記コードが読みにくいと思います。ごめんなさい。リンクをたどってオリジナルのエントリをご覧ください )

カテゴリが一つのときは @i_category[0] のように配列先頭をスカラで取ればいいんだけど、カテゴリが複数になるとここが多次元配列になる――と、書いてみるとあまりにも当然すぎるんだけど。

ただし、ここで単純に @i_category[0] を join しようとしても ARRAY(0x…) のようにリファレンスが戻ってきてしまうので、 @{……} のようにして要素を呼び出してやる必要があるらしい。面倒だな～。

これで複数カテゴリをセットしても、目的とするカテゴリがセットしてあれば識別できるようになった。

【参考】 リファレンスについては次のページなんかが役に立った

・Perlのリファレンスの話 - ケーズメモ
http://d.hatena.ne.jp/ksmemo/20071214/p1

・リファレンス | Perl講座 [Smart]
http://rfs.jp/sb/perl/02/10.html

なんとか通勤をはじめた

先週まで自宅でリハビリして、今週から本格出社。といっても、外来通院などがあって、完全に通常業務態勢に戻れるのは来週になるだろう。

切除された患部の検査が終わってわかったのは、自分が早期なんかじゃなくて、ステージ３という進行した癌だったということ。なので、今後は年単位で化学療法をやることになるのだろう。

５年生存率がおよそ75％ほど。よせばいいのに、それで“期待値”なんてもんを考えてしまった。ウェブマーケティングなんてやってるせいだ。

５年の75％は３年９ヶ月。数えてみると、息子が小学校に入学した４月じゃん。５月の連休までは行き着けないじゃん。

おかげで、この２日間はひどく落ち込んでいた。

でも、きのうの朝、写真のような空と雲を見たら、少し気が晴れた。行けるとこまで行くしかないじゃん。誰かが書いていたけど(茂木健一郎さん？)、５年後に75％生きていて、25％死んでいるなんてのはない。生きれば100％だし死ねば０％だ。75％なんて、統計上のアンサンブルにすぎない。

とにかく、自分と、自分を支えてくれる妻や職場のスタッフ、そして自分を取り巻く世界、何よりも息子のためにできることを、笑いながら一所懸命にやるだけなんだな、と。