What I wanna talk ABOUT

‘mobipocket’ のタグが付いてる分

で、話の続きなのだが、現在、おそらく多くの人が使っていると思われる「PDICが吐き出したcsvファイルをhtmlにするスクリプト」は、それなりに古いこともあって、吐き出されるhtmlファイルにちょっと問題がある。いちいちあげつらっても仕方ないので割愛するが、とりあえず今回はその修正が目的と言うわけではなくて、kindleで使う場合に（自分が）使い勝手がいいようなmobipocketの辞書になるようなHTMLを吐き出してくれるようにするのが目的。

そんなに大掛かりなスクリプトでもないので、既存スクリプトをいちいち解析して、改造なんて面倒ということでスクラッチビルドってことにした。もちろん、「何を吐き出すべきか」については参考にさせてもらうしか手がないのでその点は大いに感謝というところだ。

新規に作るにあたって、CSVファイルのパーサーを自分で書くなんてことはしたくなかったので、CVS_XSモジュールを使うことにした。あるだろうとは思っていたが、使ったことがなかったので、ググって出てきた先達の方のコードをほぼそのままパクることにする。

ところが、自分の使っている英辞郎は、アルクがCDROM付きの書籍として売っていた「英辞郎」なのだが、CSV化したときに、単語の意味部分が長いと、要素中にキャリッジリターンが含まれる部分が結構あって、これは行区切り、すなわちレコード区切りとみなされたりして、おかしなことになる。（自分のPDICだけなのかどうかは不明）

とりあえず、対処は難しくないので場当たり対応したのだが、これは要するに、フィールド中にnewlineが含まれるパターンで、これについては、お決まりパターンが同モジュールのマニュアルの冒頭に思いっきり載っているのを後で発見してしまった。

最初から、こちらをパクッていればよかったのだが、時すでに遅し。というわけで、いまいちスマートに対応出来ずちょっとダサい感じになってしまっているのが、ちょっと悲しいところ。今更イジリたくないので、とりあえずそのままにしている。

変更点としては、

1. 前のアーティクルでも書いたように、生成HTMLのタグのBEGIN-END対応がおかしい点が複数存在するので、そのあたりを修正。
2. これは、まだ影響は不明なのだが<idx:key each-word=”true”>タグの出力をやめたり（そもそも、このタグは対応する</idx:key>もなかったりもしたので）
3. HTMLエンコードはHTMLモジュールで行うようにする
4. 出力されるHTMLファイルの文字コードをutf-8とする

などが動作的に改造した点。ちなみに入力されるcsvファイルはshift-jisを前提としているので、PDICが吐き出したものをそのまま食わせるようになっている。(吐き出すHTMLはutf-8）

加えて、自分にとっての懸案である「1行の冒頭になるべくたくさんの『意味』情報を登場させる」を実現するために、

1. 【＠】で始まるカタカナによる「読み方」はばっさり削除
2. 語形変化であることを示す「【変化】」という見出しも削除
3. 「【大学入試】」マークも削除
4. 句読点の「。」「、」を「.」「,」に置き換える
5. 括弧類をおかしくない程度にasciiのカッコに置換
6. その他のMBCの記号類もSBCに置換
7. 「名-1」のように品詞についた添字のハイフンを削除

などの処理を行った。今のところ、以上がやっていることのすべて、のはず。使っているうちに気づいた段階で、さらに置換ルールを増やす可能性はあると思うが、今の段階でも、パッと見問題なく使える感じにはなったと思う。

で、そうじゃないかという気はしていたのだが、PDICが吐き出した全内容をHTML化したファイルであっても（内容を間引かなくても）、mobipocket　Creatorが異常終了しなくなった。多分、HTMLタグの不整合をなくしたからではないかと思われるが、あくまでも推測の域を出ない。

例えば、HTMLタグの不整合によって、HTMLのパーサー部分でメモリ破壊が起こっていたのではないだろうか。そもそも、論理的におかしなHTMLファイルを通してしまう段階でバグではあるが、まぁ、おかしなものを喰わせておいて、お腹をこわす奴が悪いと責めるのもなぁ～って感じではある。

というわけで、PDICが吐き出したCSVファイルから、mobipocket-creatorで辞書化できるHTMLファイルを吐き出すperlスクリプト:Eijiro.csv2html.plを恥ずかしながら公開しておこうと思う。

このスクリプトは、shift-jisを吐き出す英辞郎version52というかなり古いバージョンでしかテストしていない。他のバージョンの英辞郎で動くかどうかはわからない。少なくとも、英辞郎version117 Unicodeバージョンでは、吐き出すcsvがUTF-16LEであり、また語数が非常に多いなどの問題もからんで、動かないことを確認している。(動くバージョンはこちら。新しいリンク先のバージョンでは語形変化の追跡にも対応しているので、できれば、本記事のバージョンは使わないで欲しい。)

サポートは基本的にないけど、気分次第っていうところ。以下がコマンドプロンプトでの使い方、カレントディレクトリは適当。

C:\> perl Eijiro.csv2html.pl eijiro52.csv nejiro > newjiro.html

上のリンクを右クリックとかで「リンク先を保存」とかにして、Eijiro.csv2html.plとかなんとか言う名前で保存。スクリプトはutf-8じゃないといけないので、普通にクリックして、コピペでファイルに落とす場合は、utf-8で保存しなくちゃいけない。

第1引数が、入力となるPDICが吐き出したCSVファイル、第2引数はHTMLファイルに埋め込まれる辞書の名前。結果は、標準出力に吐き出されるので、リダイレクトでファイルに落しているの図が上記。

もちろん、このスクリプトを使って、不都合なことが起こっても、責任は取れないので、念のため。なにしろ、自分の環境でしか試していないので。あと、細かいことは、先達の方々のサイトを参考に、ここでワンストップなサイトになるつもりはないし。

大晦日は朝から雪。一旦、日が射したりもしたが、結局はずっとチラチラと降り続く一日となった。

そこで、久しぶりに、kindleネタ。
kindleを買ってから基本的に、仕事がらみもあって「Programming C# 3.0」だけを読んでいた。この本は割と英語がシンプルで、非常に読みやすかったことと、日本語化した場合の英語のフォントがなんとなく読みづらい気がしたので、結局ファームウェアはオリジナルに戻して使用していた。

そうしているうちに、新しいファームが公開され、何かと便利になったりもしたので、あんまり日本語化ファームに変えようと言う気がしていなかった。が、mixiのkindleコミュで、フォントのトピックが上がっていて、その人のscreenshotのフォントがなかなか悪くない感じで「これなら、日本語にしてもいいかな？」って思ったのが運のつき。もう、大晦日だっていうのに。

まず、例によって、前回もお世話になったyoshiさんのサイトで、新しいファームに対応したUnicode Font Hackをいただいてきた。それの説明を見ると、今回からTrueTypeフォントを自分で調達すれば、自由にフォントを変更できるようだ。ただ、日本語コードだけフォントを変更して、あとはkindleオリジナルで、となると、フォントの合成とかなって、font-forgeが必要で、とかなると、linux環境か、cygwin環境が…とか、なるようで、ちょっと面倒だなぁ～感が…。

ってことで、とりあえず、溺愛の…じゃなくて出来合いのフォントをいくつか試してみて、最終的には、umeplus-gothicに落ち着いた。英字部分のフォントも、それほど細くなくグリフ自体も見やすく、標準フォントとは、まるで違うにも関わらず、これなら英文を読むのもそれほど苦にならないのではないかと思う。

で、そうなると、辞書も英和辞書にしたくなるのが人情。これは、kindleを日本語化した多くの人が望むことなので、ちょっとググると、いろいろ出てくる。基本的には、kindle ONLYと言う話ではなくて、mobipocket形式の辞書のeBookを作成すればいいって話。実は、わざわざ「作成」せずとも、東村ジャパンさんから、mobipocket形式の英辞郎とか、その他の辞書とかも発売されていて、1,890円とリーズナブルな値段で手に入る。自分も面倒だってことで、もう少しでダウンロード購入しちゃいそうになったのだが、kindleで読めるmobipocketはDRMのかかっていないものに限られるため、ここで購入した辞書は、kindleでは使えないんだそうだ。いやぁ～、危ないところだった。

まぁ、なんで「買っちゃうか～」と思ったかというと、ちまたに出まわっている英辞郎辞書データから、作成するmobipocket辞書をkindleで使用した場合、どうにも使いにくいと言うか、使いたくない感じなのだ。

kindleで辞書を使うっていうのは、その辞書を単独で開いて、調べると言うのではなくて、他の本を読んでいるときに、カーソルを分からない単語に移動すると、勝手に、画面最下段に辞書引きの結果が2行ほど表示されるという「しかけ」を使うってこと。

ところが、英辞郎の辞書をそのままmobipocketにすると、単語の意味部分の冒頭が、品詞や発音記号、さらにはカタカナ読みなど、単語そのものの「意味」以外がドドドドーッと2行全部に表示されてしまう、肝心の単語の意味がそのままでは見えないのだ。もちろん、そこからリターンキーボタンをポチって辞書全体表示にすれば見えたりはするのだが…、それでは使い勝手が悪すぎ。

さらには、今普通に出回っている英辞郎の辞書データ Eijiro52かな？の辞書をそのまま、CSV化して、さらにそこから、出回っているperlスクリプトで HTML化したファイルは mobipocket Creatorで変換しようとすると、mobipocket CreatorがC++ Runtimeエラーとやらで異常終了してしまう。

このエラー自体は、もとのHTMLファイルがある程度小さいと回避できるらしく、辞書のエントリーを間引く chu-jiroなるスクリプトもあったりする。これはもともと他のデバイスで読む場合に、英辞郎の用例などの長文データのために読みづらくなるのを緩和するためのものらしいのだが。

で、そのchu-jiro仕様の小さくしたhtmlファイルを、kindleで読みやすくなるように、エディタの置換機能などを使って、編集したりしていたのだが、その過程で csv2html4mbp2x.plが吐き出したHTMLファイルに、論理的におかしい(タグの対応など)点や、今ひとつ理解しがたい部分もあり…、こりゃ、変換自体を自分でやった方がよさそうだ、と思ったのが昨夜の午前3時頃。

そこで、一旦就寝することにした…つづく。

前に書いたように、PDFを xxx@free.kindle.comに送って、azw形式に変換すると、英語・日本語に関係なく、表組みの属性がなくなってしまう。さらに言うと、同一文書中へのリンクの情報も消えてしまう。どちらも本当なら残っていてくれると大変大変ありがたいのだが…と思っていた。

が、思わぬ方向から解決策が現れてくれた。実は、kindleで読むことができるe-Bookの形式に、mobipocket形式というのがある、らしい。英語を含むヨーロッパ圏では「グーテンベルグ・プロジェクト」つって、著作権の切れた文書を、ボランティアというか有志の皆様方ががんがん電子化しているらしいのだが、それらが、このmobipocket形式で公開されているらしい。なんでも、当初からライセンスなどで囲い込まないというポリシーで、こういう風に使われるようになった…らしい。あんまり自信はないのだが。

で、このmobipocket形式って、そういう経緯もあって、多くの電子ブックリーダーで読めるらしいのだが、kindleも同様、っていうか、たぶん azw形式って、まさしく mobipocket形式と同じであるような気がする。いや、もしかしてkindle-book全部そういうことなのかな？どっかに書いてあったような気がするが…。

さらに今回これが役に立ってくれたのは、無料で公開されている、mobipocket形式のファイルを、さまざまなソースから作成するmobipocket createrなるソフトウェア。変換元として、MSWord, plain-text, HTML, PDFが選べるのだが、HTMLから変換すると、リンクの情報や表組みの情報を使って mobipocket化してくれるのだ。

自分の場合、WEBページ⇒PDF⇒azwと変換していたわけだが、WEBページ⇒mobipocketと直接変換することで、あとはkindleに転送すれば、リンクや表組みを残したまま閲覧できるようになった。まぁ、実際は WEBページを一旦HTMLにしてやらなくてはならないし、実はそうして作成したHTMLからebookとしてはあまり役に立たない、むしろ邪魔になるサイドバーの部分とか削除したりしなくてはならないのだが、逆にPDFじゃなくて、HTMLだからテキストエディタでバッサリ消せるとも考えられる（ただし、下手すると、HTMLタグの対応が崩れてしまう可能性も高いが)で、繰り返しになるが、表組みの部分も罫線はなくなるが、形式が崩れることはないし、冒頭の目次リンクもちゃんとたどることができる。ちょっといただけないのは、またもや例の□がちらほらと本文の途中とかに現れるくらいかな。気にならないこともないが、大きな弊害ではない。

そういうわけで、Mobipocket Createrのおかげでますますkindleで資料などを持ち出す利便性が高まったと、そういうお話。

おっと、おまけで、kindleへのファイルの転送や充電には、kindleに刺さるusbケーブルが必要なのだが、kindle本体の方のUSBのジャックは、いわゆる「microUSB」という規格らしい。一昔前に買っておいたUSB4徳コネクタキットには、この新参の「microUSB」がなくて、しくしく。amazon.co.jpとかで探すと、miniUSB⇒microUSBの変換アダプタが見つかる。

が…、ふと思い出した。そういえば、この前まで使っていた WILLCOM03がこのmicroUSBだったはず。が…、ない…ケーブルがない…。　と、必死に探して、ようやく本体に付属してきた充電器と、ＰＣに接続するケーブルを発掘してきた。これで、とりあえず、AC電源からも、USBからも充電できるし、部屋のPCでもkindleにデータを注入することができる。（基本的にリビングのノートPCだけにkindleはつなごうと思っていた―っていうか、そもそもPCにつながずに充電しかしないくらいの勢いだったのだが、結局そうはいかないようだ）。

昨夜、会社からの帰りにホームと電車の中で取り出して読んでみたが、車内はちょっと暗いかな、本ほどのコントラストがないので、字が小さいとちょっときびしい。むしろ、ホームの方が読みやすかった気がする。そこそこ混んではいたが、一応座ることができたので両手を使って読むには何の問題もなかった。ただ、割と混んでいる車内で片手は吊革という状態だと微妙にきびしいかもしれない。少なくとも片手なので、辞書引きなどはできない、ページの前後のみとなる。朝の通勤は座れるってことはないので、今の時間の電車に慣れてきたら試してみようと思う。（11月から出勤時刻が変わったので）

そこで、実はちょっと前から残念に思っているのが、ストラップホールがないこと。これってやっぱ日本でだけ需要が高いのかな、iPhoneとかでも騒がれていたが、基本的に向こうのものってストラップホールがないものらしい。kindleを電車で読むのなら、ぜひストラップをつけたいのだが、どうしたものか思案中。頑丈なストラップホール付の部品みたいなもの（それも極小の）を瞬間接着剤とかでくっつけたらよさそうだと思うのだが、まだ、そういうものは売られていないようだ、まぁ、あまり需要があるとも思えないが。自分でプラ板を加工してつくる？いやいや、さすがにそれは…。なんか、ちょうどいい部品ってないものかなぁ～。

さてさて、C#も読まなくちゃ。