晴天好天の昨日は京成線の下町日和きっぷを利用して半日ほどポータルを巡る散歩。

下町日和切符は以前にも雑記に書いたように、京成線の23区内1日乗り降り自由で500円。かなりお得だと思う。京成線は城東地区が中心で駅近辺は昭和の色と匂いが濃厚で艶っぽいところが多い。

IngressではMissionというのがあって、名所旧跡巡りっぽいコースや、駅近辺だけのお手軽なコースがいろいろある。ユーザーがミッションを作って申請できるようになって、バリエーションも増えている、らしい。

京成線途中下車の旅というミッションがあったので、それをやってみた。

京成金町〜柴又〜高砂〜立石〜四つ木〜お花茶屋〜堀切菖蒲園

まだあったんだけど、午後出発してこれら+αを回ってたら17時。あたりはすっかり暗くなってきたし、ヨメもわたしも足がじんじんヨレヨレのテイタラクだったので撤収した。

堀切菖蒲園の十二干支神像。こいつは無駄に凝ってて面白い。いちいち表情があって、12体ずら〜っと並ぶのを眺めて飽きない。

寺の中の小さな鉄塔。色使いが温泉街、場末のスナックのようで思わず撮った。

柴又の夜は早い…てか、まだ17時だってのに参道はもう店仕舞い。

前回の下町日和切符散歩→『京成の一日周遊切符「下町日和きっぷ」』

京成電鉄の「下町日和きっぷ」のページ

http://www.keisei.co.jp/keisei/tetudou/ticket/shitamachi/index.html

柴又や立石から上野やスカイツリーまで、おすすめ。

[更新]2015-06-30 08:33:55

perlのスクリプトでmacの日本語ファイル名がマッチしない、という話題がtwitterに上がっていた。ネタ的に面白そうなので自分でも試してみたところ、macの日本語ファイル名が正規表現で一致しないことに気づいて、ちょっと吃驚。

フォルダには

・test.txt

・あいうえお

・ペダル

・memo.txt

など、アルファベットのファイルや日本語ファイル・フォルダが雑多に入っている。

この中から「あいうえお」と「ペダル」だけを検索で引っ張り出したい。というのが以下のスクリプト。

use strict；
use utf8；
use Encode；
binmode STDOUT=>’utf8’；
opendir(DIR， ’.’) || die； my @files = grep(!/^\./， readdir(DIR))； closedir(DIR)；
foreach (@files){
    my $f = Encode::decode(’utf8’， $_)；
    if( $f =~ m!あいうえお! ){
        print $f ， " <--- hit aiueo !! \n"；
    }
    elsif($f =~ m!ペダル!){
        print $f， " <--- hit pedaru !! \n"；
    }
}

ところが、これでヒットするのは「あいうえお」だけで、「ペダル」はヒットしない。

twitterでの流れを追うとどうやらmacのファイルシステムが（日本語ファイル名に）使うのは NFD という形式らしい（Normalization Form Canonical Decomposition）。これをperlで判定するためには NFC という形式に変換してやる必要がある（Normalization Form Canonical Composition）

NFDとNFCで問題になるのが。

・濁音などがはいると文字コードが違ってくる。

・macの場合はさらに一般的なNFDではなくて、utf-8-mac というちょっと特殊なもの。

『Geekのメモ: Mac OS Xのファイルシステムの文字コード』

↑こちらのページが具体的でわかりやすかった（感謝！）

お馴染みの Data::Dumper で読み込んだファイル名と、スクリプト内の文字を比べると、文字コードが違っていた。まさに上記した utf-8-mac の問題。「あいうえお」は濁音が混じってないので文字コードは同じだけど、「ペダル」は濁音部分で文字コードが違っていた・文字長が増えていた。

上記サイトを参考に、CPANから Text::Iconv をダウンロード、インストールしてテストスクリプト。

１）ファイル名を utf-8-mac から、utf-8に変換する。

２）変換したファイル名にutf8フラグをつける。

use Text::Iconv；
binmode STDOUT=>’utf8’；
opendir(DIR， ’.’) || die； my @files = grep(!/^\./， readdir(DIR))； closedir(DIR)；
my $h； my $n = 1；
foreach (@files){
    my $f = Text::Iconv->new(’UTF-8-Mac’， ’UTF-8’)->convert($_)；
    $f = Encode::decode(’utf8’， $f)；
    $h->{$f} = $n； ++$n；
}
foreach (keys %{$h}){ printf qq{%s ::: %s\n}， $_， $h->{$_}； }
print $h->{’ペダル’} ."\n"；

↑で、無事確認できた。

ついでに。utf8フラグのおさらい。

文字コードのutf8とperl のutf8フラグは別モノ。

perlがスクリプトで内部処理するのにつけるのがutf8フラグということ…って、素人のわたしはよくわかってないので検証。

use strict；
use utf8；
use Encode；
binmode STDOUT=>’utf8’；
my $v = ’弱虫ペダル’；
while(<>){
    if( $_ =~ m!$v! ){ print $_； }
    my $line = Encode::decode(’ENCODE-NAME’，$_)；
    if( $line =~ m!$v!){ print $_； }
}

コマンドラインで引数に渡したファイルを読み込んで、「弱虫ペダル」を含んだ行を出力（プリント）するだけの単純なスクリプト。

・スクリプト自体は文字コード、utf8で書かれている。

・「弱虫ペダル」は文字コードがutf8で、 use utf8 によって、perl の utf8フラグがついている。

・最初の if 文は、utf8フラグのついていないテキストと、utf8フラグのついた「弱虫ペダル」の比較なのでヒットしない。

・Encode::decode で読み込んだファイルのテキストにutf8フラグをつける。

　ENCODE-NAMEはファイルの文字コード。shiftjis、 utf8など。

・次の if 文は utf8フラグのついているテキストと、utf8フラグのついた「弱虫ペダル」の比較なので文字コードが * shiftjisだろうがutf8だろうが * ヒットする。

・スクリプトの文字コードはutf8でも、use utf8をつけない場合（スクリプトにutf8フラグがつかない場合）

・「弱虫ペダル」は文字コードがutf8で、perl の utf8フラグはついていない。

・最初の if 文では入力ファイルの文字コードが utf8 のものだけがヒットする。

・Encode::decode で読み込んだファイルのテキストに utf8 フラグをつける。

・次の if 文は utf8 フラグがついているテキストと、utf8フラグのついていない「弱虫ペダル」の比較なのでどれもヒットしない。

perl の utf8 フラグをつけることによって、スクリプトや、入力されるテキストの文字コードは何でも構わない、という超便利なフラグ（decodeで正しい文字コードを指定する必要はあるけど）

perlのutf8フラグネタでは以前 「utf8移行と自分メモその２」 こっちにも覚え書き（utf8フラグをつけたスクリプトは、変数に日本語が使える、というネタはこちら）

encodeネタでは変換に失敗する文字をチェックするのにencodeの第3引数に、というネタも 「メモ　encodeで変換失敗を第三引数でフォロー」 …ほんと、なんちゅーかほんちゅーか。面倒くさい。

https://twitter.com/JunTajima/status/422190121455063040

話の発端からtwitterを追ってみると、utf16だったことが原因だったということでした。

て、utf16使う状況があるのか！？参考になります。ううううむ。難物。

現時点では、KDPの個人出版物を判定するのは難しい、というのがわかった。

アマゾンAWSのAPIで情報を取得してごにょごにょするのが基本。

APIで取得するXMLには商品のほぼすべての情報が入っているんだけど、kindleストアの電子書籍に関しては販売価格がなかったし、今回取得したXMLを加工なし状態で覗いたところ、どこを探してもKDP（Kindle Direct Publishing＝個人のセルフ出版物）だという要素は見当たらなかった。

法人との仕入れ契約は個人とは全然別のはずだから、裏側というかバックヤード系のデータベースにはしっかり登録されて、区別がつくようになっているんだろうけど、ショップサイドに使うデータとしてAPIでは提供されていなかった（今日時点）

APIの仕様などの一次情報はこちら「Product Advertising API」

https://images-na.ssl-images-amazon.com/images/G/09/associates/paapi/dg/index.html

とりあえずのその場しのぎで、KDPの個人出版物かどうか判定する方法としては。

・既存の出版社から出ている印刷本もあるKindle本は、アメリカのアマゾン .com では販売されていない。

・個人のKDPの場合は .com でも販売されている。

・アマゾンが管理する ASIN コードは一意のものなので、販売する国が違ってもASINは同じ。

てことで、日本のアマゾン .co.jp とアメリカの .com でASINを検索して両方で販売されていたら KDP個人出版物、だろう。

パブー経由のKindle本は、出版社ではないのに .com での販売はないらしいが、数的に取りこぼしても問題はない

スクリプトでAPIを叩いて回ってもいいし、ブラウザで日米のアマゾンを開いておいてASIN検索してもいい。

上記、ASINを入力して調べるやりかた。

でも、ひとつずつ入力するのは面倒なので、各カテゴリをリストしてその中でKDPかどうか判定して表示させたい。

と思ったら、こっちも難しかった。

たとえば「文芸・評論」→「日本文学」で絞って、APIからXMLを取得して表示させたら夏目漱石の「坊ちゃん」をはじめとする青空文庫が大量に出てきた。当然KDPではない。「有料」だけをカテゴリした BrowseNodeId があるはず、と探して回ったけど見当たらず。一括一網打尽の地引き網で有料のコンテンツだけを引っ張り出すのは無理（何か方法があれば、ぜひ教えてください）

「Kindle本のXMLに販売価格の要素がない」ことと何か関係でもあるのかな。

結局、ASINを入力してKDPかどうかを判断するスクリプトが一本できただけ…ブラウザで手作業でASIN検索することを考えると、ほんの少しだけラクかも知れないけど、あまり役に立たないなあ、とガッカリ。

[更新]2026-02-02 07:54:10

書き込み系のチェックもほぼ終了。IE系など見た目のチェックと修正調整、エラーとかヘルプのページ作成が残るぐらい。この調子だと今月末か来月頭には全面的リニューアル公開できそうだ。昨日、今日、いちんち部屋でスクリプトをパチパチやってた甲斐があったというものだ。

…て、スタイルシートの調整がかなりの力仕事汗仕事なのでまだ油断はできないんだけど。

てことで、この連休は地元をうろちょろ。

ヨメが駅前のイトーヨーカ堂でラミネート加工の器具を発見。A4のものだと3480円だ。もっと高いシロモノだと思ってた。紙媒体大好きな我が家だ、とりあえず購入する。使い途は後で考えよう。写真をプリントしてラミネート加工してもいいしね。

雑誌もテレビも、広告媒体としてダメになってきてるらしい。休刊だの減収減益だの。広告だビジネスだと無駄に膨れず、個人でなにができるか、てのを真面目に考えたいもんです。

で、ついこないだからつけ始めた手帳だけど、ううううう、掛け値なしに、わたしの字は汚いっ。とほほ。

どうやら無事に稼働してるっぽい自宅サーバー、牛丼大盛りつゆだく号だ。とりあえずそこそこ快適なレスポンス。メモリをおごっただけのことはある、のかな。

で、稼働したばかりだしここ数日はapacheのログファイルの監視・チェックをこまめにやっていて、妙なアクセスとか豪快なクロウラーに気づく。

apacheのアクセスログ。

XXX.XX.XX:25なんてのがあった。なんでhttpで25番portなんだ？ぶっちゃけこれは謎。maillogやmessagesを覗いても同時刻にメールが動いた気配はない。whoisをみるとこのドメインはカリフォルニアのIPアドレス。アクセスしてきたのは台湾のIP。うううむ。なんだろ。

Baiduspiderという中国版google百度というサイトのクロウラーが豪快というか。そんなしょっちゅうこられても、そんな頻繁に更新してないし。おまけに、地引き網を始めると1秒ほでの間隔で片っ端からもっていく。わたしのサイトはほとんどがCGI。いちいち全部もっていくとかなりのページ数になるし、そもそもサーバーに負荷がかかる。今まで放置してたけど、今回はwhoisで調べて百度が使ってると思われるIPアドレスはすべて却下にした。中国のひとが金町のもつ焼き屋情報を欲しがってるとは思えないしなあ。

掲示板への広告スパムが相変わらず激しい。該当の掲示板は削除してあるのにかなりの頻度でやってくる。で、問題なのが、削除した掲示板はデータベースがらみでmod_perl2のスクリプト。こいつにアクセスされると、そんなファイルはありませんよ、と返事するのはmod_perl2なのだ。これはメモリの無駄遣いでしかない。ので、apacheのmod_rewriteで応答してもらうようにした。

wide charですよ、というutf8がらみの警告もなかなか取れていない。原因はわかっていて、SNSの方はutf8にしたけどこっちはまだeucとutf8が混じった状態なのだ。全部utf8にしたほうがいいんだけど、仕事が始まって、帰って食って寝るだけの平日、時間がほとんど取れないんだよねえ。今日もzaurusで電車内ネット…しょぼいよなあ。

てな感じで、アクセス制限をちまちま追加。

ネットワークやサーバー管理に関する知識を少しはまともに仕入れておかないとなあ。入り口のルーターで一部のportしか通さないはずだけど、意味不明のログが残ってると、不気味だぞ、としか対応できないのはいかがなものか。

でも、サーバーもperlもおもしれーっすよ

[2007/01/12 23:27:41]

なんで25番なのか、気持ち悪いのでapacheのログをもう一度チェック。リクエストがPOSTでもGETでもなくCONNECT。なんじゃそりゃと検索したらproxyとのトンネリングをどうのこうの、と。

…えっと、こいつは踏み台探しだ。カリフォルニアに用事でもあるのか。妙なアクセスがあるなあと思ったらほとんどが台湾のHINETなんだよなあ。

CONNECTを却下するとどんな影響があるのかわかってないので、今回もIPで弾くことにする。httpd.confのDenyばかりがやたら増えていくのは困ったものだ。

[更新]2013-04-18 08:06:38