Amazon Product Advertising API利用制限
AmazonのAPIが2019年からポリシー変更となった。
ひらたく言うと「売上のないサイトやアカウントはAPIを利用できなくなる」
さらにひらたく言うと、わたしのアカウントは売り上げがないので利用できなくなった。
Product Advertising API (PA-API) の利用ガイドライン
https://affiliate.amazon.co.jp/help/topic/t32/
[重要] Product Advertising API 利用ポリシーの変更について
https://affiliate.amazon.co.jp/help/topic/t52/
Amazonの商品データベースを利用できるAPIはかなり便利で、また使い勝手もよかったので残念。
もちろんアフィリエイトで小遣い稼ぎになるならありがたい話だけど、うちのような辺境にそれは見込めないので、もともと「充実した本のデータベース」として重宝していた。
ISBNさえあれば、ほとんどの本の情報が揃ってるから。
わたしが利用しているのは
・書名
・著者（作者、翻訳者、挿絵など）
・書影
の3点。価格については変動してるのでおまけ程度。
なので、その3点に絞ってamazonのサイトをクロールして情報を取得するように順次変更する。
とりあえず、まずはお問い合わせ（本が登録できんぞ！）をいただいている
「趣味は読書２」https://doncha.net/
をあわてて修正。
これはWEB本棚で、本が登録できないなど論外だ。
amazonの検索結果からも登録できるようにしてあったんだけど、これはちょっと無理。サービスレベルが落ちるがしかたなく諦め。
また、やはりサイトをクロールするより、APIの方がレスポンスが断然早いなあ。クロールだとひと呼吸待つ感じになってしまった。
わたしが公開しているサイトのほとんどはamazonを利用しているので全部の修正は時間がかかりそうだ。とほほ。
紙印刷本から電子書籍から紙印刷本というエコシステム
InDesignからSigil経由のEPUBファイルをInDesignへ。
何を言ってるかわからないと思う。わたしも最初聞いた時は驚いた。
紙で出版されたものが電子書籍として配信されて、今度はその配信されたものを組み直して再び紙印刷本へというお話。
売れっ子グラビアアイドルが、AVに出演した後、温泉街のストリップに流れる、みたいな変遷。逞しい話で、名作(テキスト)は姿形を変えてもしっかり生き残るという良い例だろう(ほんまか)
おそらく元になってるInDesignデータは出せなくて(権利的な話じゃなく、たぶん探すのが面倒、もしくはもうなくなっているので)電子書籍のEPUB3ファイルを元にするしかない。
ということで、そのEPUB3ファイルをバラしてInDesignに流し込みという雇用創出となった。
まだEUPBファイル制作のソフトが出揃ってなかったんだと思う。
ファイルは、一時使われていた縦書きにもできる改造版Sigilで作られているっぽい(EPUBファイルのフォルダ構成やファイルの命名規則がどっかで見たことあるなあと)
でもまあ、青空記法に独自規則のアレンジとかdotBookからのHTMLっぽいデータよりはEPUBファイルの方が扱いやすい。
・組み直しになるので、元のレイアウトにこだわる必要ない。
・小説なので、EPUBファイルから拾い上げるのはルビと圏点、外字程度。
ルビはグループルビのタグがついているし、圏点はsesame(ゴマ)というクラスが指定されている。外字は画像になってるのでそこは「〓」にしておいて校正で対応。
↓InDesignにはタグ付きテキストというのがあって
http://help.adobe.com/ja_JP/indesign/cs/taggedtext/indesign_cs5_taggedtext.pdf
テキストデータにルビや圏点のタグを付けてInDesignに「配置」すればそのままルビも圏点も生かしてくれる。
以下のスクリプトでEPUB3のルビと圏点のタグをInDesignのタグに変換してやれば大丈夫だった。
use strict；
use utf8；
use Encode；
binmode STDOUT=>":utf8"；
my $dir = ’OEBPS/’；
my $xhtml_dir = $dir . ’/Text/’；
opendir(DIR， $xhtml_dir) || die； my @xhtml = grep(/p\-\d+\.xhtml$/， readdir(DIR))； closedir(DIR)；
foreach (@xhtml){
my ($base) = $_ =~ m!(p\-\d+)\.xhtml!；
my $text = $base . ’.txt’；
open(IN， $xhtml_dir . $_) || die；
open(OUT， ’>’ . $text) || die；
binmode OUT=>":utf8"；
print OUT qq{<UNICODE-WIN>\n}；
my $sw；
while(<IN>){
my $line = Encode::decode(’utf8’， $_)；
$sw = 1， next if $line =~ m!<body!；
last if $line =~ m!</body>!；
next if $line =~ m!^\r?\n!；
if($sw){
$line =~ s!\r?\n!!；
$line =~ s!^[ \t]+!!；
$line =~ s!<p><br /></p>!
!；
$line =~ s!<ruby>([^<]+)<rt>([^<]+)</rt></ruby>!&ruby({str=>$1， ruby=>$2})!eg；
$line =~ s!<span class="em-sesame[^>]+>([^<]+)</span>!&goma({str=>$1})!eg；
$line =~ s!<img[^>]+class="gaiji[^>]+>!〓!g；
$line =~ s!<[^>]+>!!g；
$line =~ s!
! !g；
$line =~ s!___cRuby:1___!<cRuby:1>!g；
$line =~ s!___cRubyString:([^_]+)___!<cRubyString:$1>!g；
$line =~ s!___cMojiRuby:0___!<cMojiRuby:0>!g；
$line =~ s!___cRuby:___!<cRuby:>!g；
$line =~ s!___cRubyString:___!<cRubyString:>!g；
$line =~ s!___cMojiRuby:___!<cMojiRuby:>!g；
if($line){
print OUT $line . "\n"；
}
}
}
close(IN)；
close(OUT)；
}
sub ruby{
my $args = shift；
$args->{ruby} =~ s![ ]!!g；
return "___cRuby:1______cRubyString:$args->{ruby}______cMojiRuby:0___$args->{str}___cRuby:______cRubyString:______cMojiRuby:___"；
}
sub goma{
my $args = shift；
return "___cKentenKind:1___$args->{str}___cKentenKind:___"；
}
文字コードでちょっとハマった。
InDesignで「配置」する時、文字コードはShift_JISかUTF16じゃないと文字化けしてしまう。
元にするEPUB3ファイルの文字コードはutf8(BOM無し)。
EPUB3のUTF8をShift_JISにすると文字化けを起こす可能性があるような気がするので、とりあえずutf8のまま上記スクリプトでタグ変換して、エディタで開いて文字コードをUTF16に変換した後、配置した。
Adobeのタグ付きテキストのPDFを見ると、かなり細かく制御できるので、ちゃんと探せばこの手のコンバート系でいろんな強力なツールが出てるはず。
でも、たぶん、そんな継続する案件でもなさそうなので、テキトーな使い捨てスクリプトでやっつけ仕事。
しかし、ほんとニッチな需要もあったもんだ。
ガッテンしていただけたでしょうか。
ブラウザの戻るがよろしくない
てことでUIのためのAjaxなのに戻る先が「てれこ」にしかできないんじゃ論外。スキルがないんでしょうがない。無駄無意味なAjaxは外そう。
そうすると、今度は全画面書き換えで、メニュー部なんてほとんど同じ表示なのにそのためにいちいちDBに問い合わせが生じてレスポンスが遅くなる。最新の本を５冊表示とかランキング表示とか。テーブル構造とSQLが素人芸、しょせんヘボなんで、登録が６万冊越えていて処理が重いのだ。
order by modifytime desc offset 0 limit 5
なだけなのになあ…。
キャッシュを作るか、メニュー部だけのためにコンパクトなテーブルを作るか。
書き込みがリアルタイムに反映される、てのが前提だろうからキャッシュはやりかたをあれこれ考えないといけない。
とりあえず、最新本はwhere句でちょっと絞り込み条件をつけたら早くなったのでこのまま。著者人気順とタイトルの人気順はさすがに重いんで、こればかりはリアルタイムに反映というのは無謀、だよなあ。てことでコンパクトなテーブルを作ってそこにつっこむことにした。
新着と違ってそんなに変動するものでもないし。今のところの動きをみてると週に一度集計すればいいぐらい。集計用のスクリプトをcrontabに登録して動作確認。当たり前だけど軽くなった。ページ表示に2〜3秒かかってたのが１秒におさまった。ただ、それでもHDDへのアクセスが気になるようだとキャッシュを使うしかなさそう。ちょっと様子見。
ちなみに作家１位は恩田陸、タイトル１位は「図書館戦争」。
ポンコツの身にはハードな状況が続くのであった。とほほ。
[更新]2026-02-04 09:57:55
あれこれと
ちょっと整理整頓。
仕事は、平日めいっぱい。その割になんか成果が上がってるわけでもない。サイトの運用、というとなんだかエラソウだけど、どうも違和感がつきまとったまま。ネットで対一般不特定多数をやろうっていうのに、対企業でやってきたひとの目線はあいかわらずの対企業。なもんだから、理想はともかく、実際サイトの作りなんかは企業向けプレゼン。わたしはエロ本エロ漫画編集という対不特定多数どっぷり20年だったので、目線の向きが180度ほど違う。もっとゆるい感じにして距離をつめないとダメじゃん、と思いつつ。
読書SNSは休日それなり。今まで機能してなかったフラグにちょっと化粧を施したら好評。中身は従来とまったく変わらないんだけど、カスタマイズできるのは確かに面白いかも。ほんのちょっとしたことで随分変わるもんだ、と真面目に感謝、というか感心してしまった。
ページビューがどっと増えた…ので牛丼パソコンに頑張ってもらわんと。
そんなこんなで、せっかく校正のバイト仕事の打診がきたけど、時間的な余裕がない。うううむ、このてのは繋ぎでもいいからやっておきたいところだった。
野良サーバーの生きる道…って
昨日は有楽町の立ち飲み屋に亀有の牛角にハシゴした上、帰ってから景虎で、そりゃ飲みすぎですよ。
どれもこれも美味いし…いや、牛角のねぎみじんは本当に美味。これだけでどんぶりメシが2杯は食える。長ネギをみじん切りしてごま油とか塩コショウだろうけど、これを求めて試行錯誤する相方の話ではなかなかこんなにまろくならないんだそうだ。
今日は妙に冷えるので立てこもり。ウチでのったりまったり。
オープンソースの
このへんからソースを拾ってきて眺めてみる。わたしのスキルではたいそうなこともできんのだけど、データベースの構成がどうなってるのか知りたかったのだ。
両方ともすげー数のスクリプトにデータベースで驚いた。phpの特性なのか、チームで作る時のお約束なのか、単機能の細かなスクリプトがぞろぞろ。データベースに関してはオープンゴロットの方がなにやら難しい。viewを駆使してruleを定義しまくり…こりゃどうなってんだかわたしには理解不能。データベースの（postgresqlの）機能をしゃぶりまくってる感じなのだ。オープンピーネの方がまだわかりやすい、かも。あしあと用とかお気に入り用とかいちいちテーブルを用意しないとだめなんだなぁ。管理がめちゃくちゃ大変そうだ。こっちはケータイ版のスクリプトもたっぷりで参考にできそう。
で、mixiもあれこれ触ってて気づいた。レビューってアマゾンのアソシエイトプログラムじゃん。250万からの人数がいるわけで、その中のある程度の人数でもクリック→購入、となるとmixiにとってかなりの収入源だ。うーむアマゾンの出店のようなものだったか。これはうまいやりくちかも。誰も損をするわけじゃない、最近流行のカタカナでウィンウィンというんだっけか。
アマゾンも絡めて考えると面白いかなあ。いや、品揃えはナンバーワンだろうし、ブランド力もあるし、Net-Amazonという便利なモジュールもあるし。
草の根野良サーバーでもできることがある、かもしれない。
[更新]2026-02-04 10:43:17