mobipocketと英辞郎 for Kindle(2)
2009年12月31日(木曜日) | 
著者別: で、話の続きなのだが、現在、おそらく多くの人が使っていると思われる「PDICが吐き出したcsvファイルをhtmlにするスクリプト」は、それなりに古いこともあって、吐き出されるhtmlファイルにちょっと問題がある。いちいちあげつらっても仕方ないので割愛するが、とりあえず今回はその修正が目的と言うわけではなくて、kindleで使う場合に（自分が）使い勝手がいいようなmobipocketの辞書になるようなHTMLを吐き出してくれるようにするのが目的。
そんなに大掛かりなスクリプトでもないので、既存スクリプトをいちいち解析して、改造なんて面倒ということでスクラッチビルドってことにした。もちろん、「何を吐き出すべきか」については参考にさせてもらうしか手がないのでその点は大いに感謝というところだ。
新規に作るにあたって、CSVファイルのパーサーを自分で書くなんてことはしたくなかったので、CVS_XSモジュールを使うことにした。あるだろうとは思っていたが、使ったことがなかったので、ググって出てきた先達の方のコードをほぼそのままパクることにする。
ところが、自分の使っている英辞郎は、アルクがCDROM付きの書籍として売っていた「英辞郎」なのだが、CSV化したときに、単語の意味部分が長いと、要素中にキャリッジリターンが含まれる部分が結構あって、これは行区切り、すなわちレコード区切りとみなされたりして、おかしなことになる。（自分のPDICだけなのかどうかは不明）
とりあえず、対処は難しくないので場当たり対応したのだが、これは要するに、フィールド中にnewlineが含まれるパターンで、これについては、お決まりパターンが同モジュールのマニュアルの冒頭に思いっきり載っているのを後で発見してしまった。
最初から、こちらをパクッていればよかったのだが、時すでに遅し。というわけで、いまいちスマートに対応出来ずちょっとダサい感じになってしまっているのが、ちょっと悲しいところ。今更イジリたくないので、とりあえずそのままにしている。
-
- 実は、すでに要改良と思われる点を発見
どうも、word-wrapはスペース区切りでしか行われないようだ。コンマなど、句読点でもやって欲しいのだが。
機種: E-3 絞り値: F8 焦点距離: 179mm ISO: 100 シャッタースピード: 1/250 撮影日時: 2009:12:31 11:59:54
変更点としては、
- 前のアーティクルでも書いたように、生成HTMLのタグのBEGIN-END対応がおかしい点が複数存在するので、そのあたりを修正。
- これは、まだ影響は不明なのだが<idx:key each-word=”true”>タグの出力をやめたり（そもそも、このタグは対応する</idx:key>もなかったりもしたので）
- HTMLエンコードはHTMLモジュールで行うようにする
- 出力されるHTMLファイルの文字コードをutf-8とする
などが動作的に改造した点。ちなみに入力されるcsvファイルはshift-jisを前提としているので、PDICが吐き出したものをそのまま食わせるようになっている。(吐き出すHTMLはutf-8）
加えて、自分にとっての懸案である「1行の冒頭になるべくたくさんの『意味』情報を登場させる」を実現するために、
- 【＠】で始まるカタカナによる「読み方」はばっさり削除
- 語形変化であることを示す「【変化】」という見出しも削除
- 「【大学入試】」マークも削除
- 句読点の「。」「、」を「.」「,」に置き換える
- 括弧類をおかしくない程度にasciiのカッコに置換
- その他のMBCの記号類もSBCに置換
- 「名-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ファイルに埋め込まれる辞書の名前。結果は、標準出力に吐き出されるので、リダイレクトでファイルに落しているの図が上記。
もちろん、このスクリプトを使って、不都合なことが起こっても、責任は取れないので、念のため。なにしろ、自分の環境でしか試していないので。あと、細かいことは、先達の方々のサイトを参考に、ここでワンストップなサイトになるつもりはないし。
Related posts:
分類：
タグ：
こんにちは！
こちらの方法を試してみたのですがうまくいきません。
もしどこか間違っていましたら教えていただけないでしょうか？
①英辞郎のdicファイル（EIJI-117.dicを使用しました）をPDIC（ユニコード版）でeijiro52.csvファイルに変換。
ここでサイズが約130MBから約211MBに。
②Mobipocket Creatorで辞書ファイルに変換。
②でエラーになってしまいます。
3個のWarningは下の通り
・Wiarning(prcgem): encountered an “idx:entry” definition without an “idx:orth” parameter. line:0000019
・Wiarning(prcgem): Cover not specified.
・Wiarning(index build): This index is empty and has been skipped.
あ、すみません、抜けていました。
①の後にeijiro52.csvからEijiro.csv2html.pl でhtmlファイルに変換して②になります。
PDIC(ユニコード版）とのことですので、吐き出されたCSVファイルの文字コードがユニコード(utf-8?, UCS2?)になっている可能性が考えられます。本記事のスクリプトの75行目の
my $encoder = find_encoding(’shift_jis’);
のshift_jisをutf-8などに書き換えて試してみてください。
自分が仕様している英辞郎辞書は本文にもあるように version52で、これは2001年というかなり昔のものです。もしかすると、フォーマットの違いで変換が上手くいかないかもしれません。残念ながら、最新の英辞郎辞書は購入により入手するしかないようですね。
文字コード対応だけで、うまく行くといいのですが。
こんにちは！
CSVファイルの文字コードがutf-8だと思っていたのですが。
見てみたところ、utf-16となっていました。
これをutf-8に変換し再度チャレンジしてみたところ。
htmlまではうまくっているようです。
PRCファイル変換はPCの性能上進行が遅いのでまだ未確認です。
今のところエラーなしです。
ありがとうございます！
こんにちは！
EIJI-117の変換ですが、Eijiro.csv2html.pl でhtmlにできましたので、
Mobipocket Creatorで辞書ファイルに変換を試みたものの
3時間待ちましたが、0%で変換が進行しませんでした。
version52も所有しておりましたのでそちらで実行してみたところうまくいきました。
サイズの関係でしょうかね？（htmlサイズ ver.117：約240MB ver.52:約130MB
ともかくも、英和検索が使いやすくなって助かりました！
ありがとうございます！
自分もいじっているときに、そういうことがあったような気がしますね。おそらくはサイズの問題ではないでしょうね。できれば、最初の1000行ほどを（って多いいかな？圧縮すればそうでもないと思うのですが）送ってもらえませんか？cvsの方ができればいいかな。一応、原因を知っておきたいし。
ご面倒でしたら、別にいいんですけど。
と、思ったらメアドとか、ここからはわからないんですね。guiyh40@yahoo.co.jpまで、よかったらお願いします。
メール送りました。
お時間があれば原因を判明していただけると嬉しいです。
ありがとうございます、さっそく見させていただいているのですが、これはPDICが吐き出したそのままですか？それともutf16->utf8変換後のものでしょうか？
PDICから変換後、utf16->utf8に保存しなおしたものです。
そうですか…。できれば、PDICが吐き出したそのままのものが欲しいのですが…。変換過程で失われているものがある可能性があるので。（誰もが、同じ変換過程をなぞれるとも限りませんし）
こんにちは、
そうですね、utf8変換前もメールしましたのでよろしくお願いします。
Mobipocket Creatorで処理できるHTMLファイルを吐き出すようには出きましたが、最終的に残念なお知らせです。
HTMLのパースの途中で
Error(index build): master record overflow (max=64k): aborting index build.
というエラーのためにビルドを諦めてしまうようです。エントリーが全部で1,919,665個と言う膨大な数になっているために、文字通りindex作成領域を超えてしまったのでしょう。
なんか、無駄にエントリーが多いのは確かだと思います、今の英辞郎は。最初の頃は、この idiom の多さが魅力でしたが、過ぎたるは及ばざるが如しのラインを遥かに超えちゃっている気がしますね。
ちなみに、最初から 1,500,000個目までだと正常にビルドを完了出きます。また、1,500,001個目から最後までだけのエントリーをやってみてもビルドに成功します。
ただ、こういうぎりぎりのことを繰り返していると、必ず例のC++ Runtime Error が出るので、もともとメモリ管理が弱いのは確かなのだと思います（メモリ管理できないのなら、C++使うなよって感じ、マネージドコードの世界だけでプログラム書いとけっ！）。
ここで、間引くと言う話になると、いろいろ趣味・嗜好の話になるので困りものですが、最新英辞郎から作成する場合は、例のchu-jiroとかによって、CSVファイルの段階で間引いてからやってもらうしかないか、って感じです。
明日にでも、時間を見て、UTF-16LE対応版を公開します。
あー、そうだ。エントリーの見出し語が2語以上のものは無条件に間引くと言うのは気持ちよさそうだなー、これだけはやってみようっと。(kindleの on time lookup はどうせ2語以上のはヒットしないし)
で、やってみたら、エントリー数は 270,648個まで縮小。mobipocket reader でざっとみた限りでは、これでも十分なんじゃない？って感じ。実は、この方が検索とかも軽快になっていいのかもしれない。
ってことで、預かったcsvファイルは明日にでも自分のディスクからは抹消しますね。