めも：Windows7でunixコマンド他
unixのコマンドをWINDOWSでも使いたくて、10年以上前はCygwinをWINDOWSにインストールして使っていた。当時はFreeBSDを普段使っていて、仕事でWINDOWSやMac。
仕事の方でもホームページ（当時はWEBサイトではなくホームページ）を立ち上げたり、進行管理のためのCGIを作るようになってActive perlをインストール。となるとコマンドラインでいつものように cp ls grep diffなんてのを叩いてしまう。そのたびに見つからないと叱られるので、Cygwinをインストールして使うようになった。
で、今。普段使うMac OSXはもともとBSDで、unixのコマンドがそのままある。rubyやapacheまである。FreeBSDのGUI環境の X がたまたま Mac になっただけ。
請負仕事の電子書籍制作。
現状では、元のテキストやワードに合わせて、perlの使い捨てスクリプトを書き散らかしている。現物合わせのやっつけ仕事で、Mac OSX のターミナルでコマンドをガシガシ叩いている。
たとえば制作途中のものをWINDOWS7のネットブックに移して続けるにはunixのコマンドが必要になる。非力なネットブックにCygwinはつらいなぁと思ってたところ、unixの主要コマンドを使えるようにしたGOWというプロジェクトがあった。
https://github.com/bmatzelle/gow/wiki
awk ls cp vim grep zip bash など普段使いのコマンドが一通り入っていて大助かり。多謝。
これでネットブックのコマンドラインがストレスなく使えるし、使い捨てスクリプトから使うcp などのコマンド表記をそのままでOKなのでいちいちWINDOWS用に書き換える手間がなくなった。
＊＊＊＊＊
ワードの .docx ファイルから取り出したdocument.xmlを読むのに重宝しているperl の Data::Dumper
便利なんだけど、日本語（ユニコードの文字）が文字化け（ではなく、16進数表記）になって出力されるので読めない。気になる該当箇所がどこなのかぱっと見ただけではわからない。
（ord(あ) → 文字コードにして → sprintf %x → 文字コードを16進数にしているらしい）
前から困ってたんだけど、なんとなくその場その場で解決したので放置。
ここにきてWORDの文書をEPUB3にすることが増えてきたので、さすがに検索した…ら、みな困っているのかスグにヒット。
ふたつ方法があるらしく、まずは自分のわかりやすい方を採用。
いろいろ。ちょっと快適。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
CSSとperlの小ネタめも
電子書籍がらみ。HTMLとCSSでどうやって表示・表現すればいいんだろうと調べたことをメモしておこう。
【横書き】
1M（１メガバイトは）は、２の20乗バイト（2<span style="font-size:0.6em;padding-botto:0em;vertical-align:top">20</span> = 1048576バイト）です。
この文字の右肩に小さくついてる「20」ってどうすんだ、画像にしてくれなきゃ無理だろ、と思わず担当者にメールしようとして思いとどまった。調べた。
右肩に小さくつけたい文字をspanタグで囲み、spanタグにスタイル指定
フォントサイズを小さくして、下側のpaddingを０にして、表示の基準ラインをトップにする
(padding-bottom は指定しなくて大丈夫っぽいけど…どうして指定してあったんだろう)
【縦書き】
縦中横をperlで一括処理する。
単純に、すべての半角アルファベットに縦中横のタグをつけるのは簡単な正規表現。
このあたりに → 『ルビのため perl unicode正規表現』
縦書きなのにやたら英単語が混じると、単語の長さによって縦中横になったりならなかったり、とても読みにくい。ということで、アルファベットの縦中横について
・アルファベット一文字は縦中横にする
・英単語は縦中横にしない
英単語をとりあえず別形式にエンコードして保護しておく。
「tab+アルファベットの10進数」
タブだったら原稿に混じり込む可能性は少ない。タブ＋数字というのはまず出てこないだろう。
一文字のアルファベットに縦中横を定義したクラスを指定。
タブ＋10進数にしておいたアルファベットの英単語を元に戻す
（上記、正規表現のところをいじれば、アルファベット２文字までは縦中横にする、３文字以上の単語はそのままにする、なんてことも出来る。でも、中途半端な設定は読みにくくなるだけ）
ていうか、そもそも、アルファベットの英単語や数字が入り乱れる「実用書」なんて縦書きである必要は感じない。底本が縦書きであっても、電書にする時には横書きで十分。縦書きの底本は全角半角アルファベットがその時々で別々。正直とても読みにくい。小説でもないのになんでまた縦書きにしたんだろう。謎だ。
- 『おかえりください』サウンドノベルWINDOWS版
- 『おかえりください』本編を加筆修正、６つのバッドエンド分岐シナリオを追加してサウンドノベル化！
音と映像が、血まみれのこっくりさんの惨劇を蘇らせる。 - 【無料体験版】はこちら
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
WORD文書をEPUB3に変換
文書ファイルを電子書籍のEPUB3ファイルにコンバートするケース。元ネタになる文書は、サイト用に作られたHTML文書だけではなくて、当然WORD文書もある。
って、わたしはプログラマではないので、アプリが出力するバイナリデータを直接触ってごにょごにょするのは無理。
「テキストデータに変換したものをもらえば対応できますのでゼヒゼヒ」と営業してきたけど、先方はライターから上がってくるWORD文書をそのままEPUB3にして欲しいに決まってるしなあ。と。
調べてみたら、最新バージョンのWORDで保存する、拡張子が .docx の文書はzipで固められたものらしい。unzipで解凍したものが以下。
xmlで保存されていて吃驚。
全部きちんと調べてないんだけど、どうやら「document.xml」が本文。これならAWSのAPIと同じ。XMLなら中身を見ることができるので、ざっくり文章を抽出することはできた。
perl の定番、 XML::Simple と Data::Dumper でデータを眺めると、位置情報やフォントサイズなどの属性も入ってるっぽい。画像も同様。WORD文書に見出しタイトルなどがついていれば、それを目次に登録してEPUB3文書にできる。
とはいえ、やはり検索してみるとすでにWORD文書をEPUB電子書籍に変換＝コンバートするアプリは無料有料があるし、一太郎のEPUB3出力エンジンは定評のあるFUSEeなのでWORD文書を一太郎に読み込んでコンバートというやりかたもある。たぶん凝ったレイアウトなどもうまく再現できる、はず。
わたしが作るとしたら、大量にあるWORD文書をひとつひとつソフトに読み込んで、ひとつひとつ出力していく手作業よりも、WORD文書が入ってるフォルダをボトっとドロップしたらそれっぽいEPUB3文書にする。という大雑把なシロモノになるんだろうなあ。
スクリプトは手順どおりのことをさせるだけなので、面倒くさいけど難しいことはない。必要に迫られたら作ってみよう（本当だったらXMLの公式の仕様書を見ないとメンテができないけど。ね）
XMLってこんなところに使われてたのか。
[04/05 20:28:06] 追記。
ということで 『かんたん電子書籍作成』 に組み込んでみた。
ワードのファイル（.docxなので2010以降かな）をそのままアップロードできるように。ただ、レイアウトやフォントなどのデザイン情報は無視します。挿絵があったら、ダミーの画像を一枚差し込むようにしてみました。
ちなみに、ルビはワードそのまま大丈夫。縦中横もそれっぽいところは自動で指定しています。
（つむぎゆう・『わたし、おねえちゃんの犬になる』より）
[2014/02/14 14:25:34]
こちら、 『かんたんEPUB3作成easy_epub』 にもWORDの文書を流し込んでEPUB3にする機能を追加。縦書き・横書き、ルビ、縦中横はワードの情報を生かします。
いつも何かとふぁっくなMSだけど、XMLで保存はイカしてるぞ！
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ルビのため perl unicode正規表現
EPUB3::かんたん電子書籍作成 https://books.doncha.net/epub/ では、テキストデータにルビや縦中横のHTMLタグを自動で振るためのオプションを用意してある（※ ページ中ほどにある [スクリーンショット、ルビや縦中横タグを挿入するにはこちら] のリンク）
そのための perl の正規表現メモ。
縦中横。
半角の、「!?」「!!」「?!」と、連続するアルファベット、連続する数字に span タグで縦中横のクラス tcy をつける。
ルビ。
「漢字(るび) 」と漢字に続いて半角のカッコに囲まれたひらがな・カタカナをルビとして ruby rt タグをつける。
※ WORDのルビつき文書をテキストで出力すると半角カッコの中にルビが入る
縦中横のタグはけっこうよく使う正規表現なのですんなり。でもルビのための漢字判定がちょっとわからずグーグル様。perlは5.8以降、ユニコードによる正規表現が使えるようになって、文字クラスを下記のように指定することができる。
ルビもこれを使って正規表現。でも、スクリプトでは、どこからルビなのか判断できない。東京都千代田区（ちよだく）と書いてあったら、「千代田区」ではなく「東京都千代田区」に「ちよだく」のルビがつく。「千代田区」にルビですよということで「東京都［#ルビ］千代田区(千代田区)」などとテキストにマークアップする必要がある。
「EPUB3::かんたん電子書籍作成」 のコンセプトは
「何も考えずにテキストを放り込んだら、それっぽい電子書籍ができる」
面倒っぽく感じる・小難しそうなことは極力排除したいので、Wikiやはてなで使われるような独自記法・方言マークアップは却下とした。
レイアウトデザインを作り込みたいということであれば（字下げや文字方向一部変更など）EPUB3ファイルを解凍して直接xhtmlに対してタグをつけて、CSSを作れば可能。「かんたん電子書籍作成」で作るHTMLとCSSは、こんなでいいのかというぐらい手抜きレベルに単純なHTMLなので、編集加工がしやすい元素材でもある。
HTMLタグのついたテキストデータで小説原稿などを保存管理するのは面倒なので、元原稿はプレーンな状態にしておきたい。間違えて元データを消してしまって、HTMLタグのついたデータしか残ってない！という場合に。
テキストデータからHTMLタグを除去する正規表現
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
mixi graphの日記APIで写真つき投稿
先日mixiの日記に投稿するスクリプトを作ったんだけど（「次はmixiのgraph APIから」 https://t2aki.doncha.net/?id=1339828183）これはとりあえず本文だけの投稿で、本文をjsonにしてリクエストしている。
でも、せっかくなので、写真付きの日記も投稿できるようにしてみた。
OAuthのやりとり、access_token や refresh_token の取得などは前回の記事と同じなので、ここでは省略。
perl の lwp を使って multipart/form-data をリクエストするところのメモ。
バウンダリや、文字のエスケープなど、いろいろ考えなきゃいけないことがあって、LWP::UserAgent と HTTP::Requestだけで自作するのはよくわからんなあ、と眺めたり検索すると HTTP::Request::Common というのを使うのが定番だと。さすがperl、欲しいものはちゃんとある。感謝。
てことで
例によってこんだけでOK。
content-type も access_token も、ここで指定するとちゃんと header に入っている。
ちょっとハマったのがPOSTの書き方。対象URLに実際にリクエストするのは、いろいろなケースがあってリクエストするものが違う。リクエストを生成するところとは別、実際に対象URLにリクエストするのは一カ所にした方がコードのメンテがしやすい。
でも、リクエストを生成しようと POST URL ... を入れるとこの時点で対象URLにリクエストしてしまう。
「LWP::UserAgent の post(...) メソッドは$ua->request(POST ...) への ショートカットとして存在しています。」
ということで、POSTと書くと飛んでいってしまう。
なので、
use HTTP::Request::Common qw(POST);
と、Common の POST を使うことを指定して、POSTと書いてもリクエスト生成だけですよ、ということに。
写真の枚数とか画像ファイルの存在チェックなどは、ここにつけたし。
perl最高っす！
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
次はmixiのgraph APIから
twitterは気楽なヨタネタ放言。少し長く書くときは、この雑記帖。facebookとmixiが絶賛放置となる。なので、この雑記帖の駄文たわごとをfacebookとmixiに投稿できればいいよな、ということでここんとこgraph APIというのをお試し中。
facebookは先日作ったので、今日はmixiの日記へmixi graph APIで投稿。
mixiの認証は facebookと同じOAuth2.0。くどく繰り返しておく（忘れっぽいんで）
一次情報はここ https://developer.mixi.co.jp/
１
アプリ登録時に取得して使うことになるのが
consumer key と consumer secret （と、自分で登録したアプリのURL）
２
code を取得するために、consumer key をパラメータにぶら下げて指定URLにGETでリクエストする
ユーザーはmixiの承認ページに。scopeのw_diary は日記への投稿権限
※facebookはrespone_typeというのは不要だったな
３
２で問題なければ・承認されば、自分で登録したアプリにcodeを持ってリダイレクトしてくる
URL?code=XXXXXXXXXXXXX
４
codeを取得したら、次は access token と refresh token を取得するために以下をPOSTのボディに入れて指定URLにリクエスト（POST）する。
※lwp のパラメータ content-type に、application/x-www-form-urlencoded を指定。
※facebookはここもGETだった。
以上で、access token と refresh token が取得できる（twitterのOAuth1.0とかamazon の認証だと、こちらでパラメータを暗号化したりする必要があるので、2.0はラクチン、かも）
mixiとfacebookで違うのが。
facebookだと、access token が永続で使えるんだけど、mixiは有効期限が短い。その分、refresh token というのがある、らしい。
↓access token の有効期限が切れてるよ
↓refresh token を使って access token を取得しなおしてね
ということになる。refresh token の有効期限は、現状だと3か月＋α？
セキュリティのためだろうけど明らかに２度手間。access token が使えるかどうか確認して、使えなかったらrefresh token を使って再取得。だったら、最初からaccess token は、refresh token を使って取得する。ということにした。手元に保存して使う refresh token が期限切れになったら、また手作業で設定しなおす。
５
refresh token で access token を取得しなおす
access tokenを取得したURLと同じURLに以下のパラメータを本文にしてPOSTする
grant_type は refresh_token。これで access token を再取得する。
mixi日記への投稿
写真つきを multipart/form-data で投稿することも可能だけど、今回は、この雑記帖へリンクするので、本文だけでいい。
lwpの content-typeパラメータを application/jsonに。以下のJSON形式で本文を投稿する。
わたしのmixi日記は友人限定なので、privacyのvisibilityをfriendsに。
facebookは投稿する本文に access token をつけるが、mixiはheader部分につける。
とりあえず。これで、facebook も mixiも graph APIを利用して、wallや日記に投稿できるようになった、かな。同じOAuth2.0でも本文に入れたりヘッダに入れたり、tokenの期限があったりなかったり、微妙に違うのが注意が必要。
[07/03 11:35:45]
写真つき投稿の記事はこちら→ 「mixi graphの日記APIで写真つき投稿」
わたしは、気楽なtwitterと、閑散とした辺境のこの雑記帖で十分。
今回 facebookとmixiを改めて眺めた感想。
facebook はわからない。プライバシー設定が信用できない。データをどう使われてるか気持ち悪いところがある。企業ページが充実しているけど、金になってんのかね。アプリをクリックして何が起こるのかわからないので、臆病もののわたしはクリックできない。
全般いろんなところが「わからない」ので使えないんだよなあ。
mixiは最近残念だと思ってたのに、今回改めて見るとページや機能はかなり頑張ってるように見える。今さら。「あしあと」はリアルタイムで見えたからこそ、ユーザーが自分で公開や発言コントロールできる安心感。コミュニティは2chでいうスレ立てで、ひとりのユーザーが気楽に掲示板を持つことができるのは目玉だったような気がする。なんでわかりにくく使いにくくなったんだろう。あしあともコミュニティもユーザーの要望を取り入れて今のカタチになったんだろうけど、ユーザーの声を聞きすぎててんこ盛りのカオス、右往左往になってんじゃないのか。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
