What I wanna talk ABOUT

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

あれから、メインマシンのOS入れ替えなどがあって、さらに公開が延び延びになっていたEijiro117.csv2html-v4.plだが、どうにか落ち着いてきたので、環境を作って、動作を確認できたので、とりあえず公開させてもらおうと思う。

eijiro for kindle.7z

今回は珍しく2ファイルをアーカイブに固めてみた。ただし圧縮形式は7zip。解凍できない方は「7zip」でググって解凍ソフトを入手してもらうしかない。

使い方は、今までと同じ。ここいらあたりを参考にして欲しい。

しかし、amazonが新しいkindleを発表してから、kindle関係で当サイトを訪れてくれる方が多くてびっくり。まぁ、前にも書いたが、多いといっても、せいぜい200view/day 程度なんだが、200を超えることどころか、普通100も超えないって感じだったので、ちょっと驚き。

せっかくきてもらっても大した内容がなくて申し訳ない限りだ。最近は、通話用ケータイ＋is01をバッグに入れて、さらにA850まで入れていたりするので、kindleを通勤バッグに入れていなかったりする。電車やバスでは、is01でネットうろうろかソリティアしているし。もっと大きいバッグにしてkindleを持ち歩いて、読まなくてはっ！と思いつつ。なんか、3kg近くもあると肩が凝っちゃいそうでやなんだよなぁ～。

バイクで通勤したいなぁ～。と思いつつ、バイクで通勤すると落ち着いて写真が撮れないからなぁ～。

【実は4月末には書いていた記事なのだが、直後に人生最大か？とも思えるバタバタに見舞われ公開せず仕舞になっていた。修正版スクリプトとともに公開しようと思っていたのだが、とりあえずそのまま中途半端な感じで公開だけして、スクリプトはまた後でってことにさせてもらうことにした】

何せ、気が向いたときにしか読まないので、未だに読了していない「More Effective C#: 50 Specific Ways to Improve Your C#」なのだが、先日読んでいて、ふと引っかかってしまった。

というのは、「obscure」の変化形である「obscures」でインライン辞書がヒットしてくれないのだ。まず、疑ったのは「obscures ….」というidiomがインデックスに登録されてしまっているんじゃないかということ。だが、メインのindex(無名のindex)には、1語のエントリーしか登録していないから、実際のところ、これはあまりなさそう?だとすると、そもそもobscareの語形変化にobscaresが書かれていない？ってことなどを疑ったのだが、結局どれもハズレ。

obscareのエントリーをcsvファイル内で見てみると、

"obscure","【形-1】（薄）暗い、よく見えない
【形-2】ぼんやりした、はっきりとしない、不明瞭な、曖昧な、不透明な
・The origin of the Japanese language remains obscure. 日本語のルーツははっきりしていない。
・This sentence is obscure [ambiguous]. この文章の意味は曖昧だ。
【形-3】〔物事が〕目立たない
【形-4】〔人が〕無名の
・She prefers obscure writers to famous ones because she's a translator. 彼女は翻訳家なので、有名な作家より無名の作家を好む。
【形-5】〔場所が〕人目に付かない、辺ぴな
【他動-1】～を暗くする、見えなくする、目立たなくする
【他動-2】覆い隠す、～の輝きを奪う
【他動-3】～を曖昧にする、分かりにくくする
【＠】オブスキュア、【変化】《形》obscurer | obscurest、《動》obscures | obscuring | obscured、【分節】ob・scure","",6,0,0,"xbskju(r)"

という感じになっている。で、現在のスクリプトだと読点の「、」がデリミタと見なされるので、「《動》」以降の語形変化は無視されてしまうということが起こっていたわけだ。まぁ、確かに他のエントリーを見ても読点をデリミタと見なすのは間違っているようなので、これは修正が必要。実際は、この本文エントリー内をもっとまじめにエントリーに分解するようなルーチンを書けばよかったな、こんなことになるなら、と今頃思っても後の祭り。

で、修正して、今まで無視されていた語形変化のエントリーも拾われるようになったのはいいのだが、なんと、そうしてできたHTMLファイルを mobipocketクリエーターに喰わせると、懐かしの「C++ Runtime エラー」で異常終了してしまう。前回と違ってタチが悪いのは、本当にもうすべての処理が終わって、あとはセーブするだけというところまで行って、そこでこけるのだ。

前と同じように、タグの不整合によって、再帰呼び出しが異常に深くなってしまい、落ちているのかと思い、さんざん調べたが、どうもそうではないようだ。その課程で勘弁してくれよと言う、語形変化のエントリーも見つけて、すわっこれが原因か！と思ったが、残念ながら、そのエントリーの有無に関係なく異常終了は起こるので、それも原因ではないと思われる。じゃ、なにが原因かと言われると皆目見当がつかない。

修正前に作成されたHTMLファイルとの差を突き詰めていくと、結局語形変化エントリーが増えたことが、何かの遠因となってこの現象を引き起こしているとしか考えられない感じ。

そうだとすると、もうまじめな対処方法はない、ってことになるわけで。一応、HTML化する語を４語までとすると、最後までいくようなので、これでごまかすしかないかなぁ～と今は思っている。

寝ているときに、ふと思いついてしまったので、実装を試してみたくなってしまって…。

何かと言うと、PDICでやっている「<→参照先>」というマクロ。これは、HTML的には<a>タグに置き換えることができるはず。本来はサーチしたいところだが、まぁ、リンクでもなんとかなりそう。

ただし、「参照されている」エントリーのリストを前もって準備する必要があるので、2パスになってしまう。1パスでできないことはないと思うが、そこまで頑張る気はしてなかったりして。

というわけで、「Eijiro117-LinkedEntries.pl」で、前もって linked.txt を作成した上で、「Eijiro117.csv2html-v3.pl」を実行すると、「<→参照先>」形式のエントリーをリンクに置き換えたhtmlファイルを吐き出す。

ただ、csv上に存在しないエントリーを参照しているものが、もともと300個以上あるので、mobipocket-creatorでビルドの時に、「リンク先の場所を解決できない」というウォーニングがその数だけ（330個強ほど）出る。ま、これは仕方ないので、無視することにした。

ってわけで、いつもながら不親切だけど、実行画面とスクリプト。「linked.txt」というファイル名は決め打ちなので、注意が必要。それ以外は、前のアーティクルを参照してください。（スクリーンショットでは、perlスクリプト名が -v2 になっているけど、-v3で保存した人は -v3にしてください…って、今気づいたけど、has been のはずが、なぜか has be になってる、恥ずかしい）

Eijiro117.csv2html-v3

（追記）このスクリプトに関するコメントなどのやりとりがここにあります、タイトルからは辿れそうにないのでリンクを張っておきます。

kindleにUnicodeハックを入れさせてもらい、さらにprimary dictionary を英辞郎から作成した英和辞書に変更してから、kindleの使い勝手が、もう劇的と言ってしまってもいいんじゃないの？ってくらい『快適』になった。

そうなると、なんかまた読んでみたくなるわけで…、実はkindle購入とともに購入していた「Programming C# 3.0」も、まだ80%ほどで止まっている状態なんだけど、あの手の本と言うのはいつもだいたいこのくらいのところで飽きてきちゃうんだよね。

ってことで、またぞろ新しい本をポチってしまった。もちろん、いきなりポチったわけではなくて、sampleをダウンロードして、最後まで読んじゃってから、やっぱ続きが読みたいよ～となって、勢いで「Buy Now」しちゃったということなんだけど。で、またまた、C#のプログラミング本で「more Effective C#」というもの、主には genericはこんなふうに使うと凄いんだぞーみたいなことが書いてあるようだ。moreなしの旧巻もあるんだが、そちらは .NET 1.1のときのもので、要するに初期のC#に基づいてEffectiveなプログラミング技法について書かれているものなのだが、.NET2.xになって、画期的な新機能(主にはgeneric)が加わって、新たに書き直されたという感じか？旧巻も読むべきか、微妙な感じなのが、ちょっと気になるが、とりえあず、新しい方を読み始めた。

それは、いいや。で、問題の英辞郎辞書で気になる点を、Eijiro117-csv2htmlのバグも含めて、いくつか修正した。

どうも、Eijiro117-csv2html.plには、意味カラムの内容から、語形変化部分(【変化】で始まる、それっぽい領域)を抽出する部分にバグがあったようで、もしかすると、Eijiro117～を使用した場合は語形変化追従しない辞書ができていたかもしれない。自分は、英辞郎の117バージョンを購入していないために使用していないために発見が遅れしまった、ごめんなさい。今回のバージョンはおそらく語形変化追従できるはず。

前回の Eijiro117-cvs2html.pl でとりあえずkindleのオンタイム辞書検索にて、語形変化にも追従していく辞書の作成はできた（と思っていたのだが、実はバグっていたかもしれない）。しかし、大部分の単語は正しく変化形の場合も、元の単語の意味が正しく表示されるのだが、ときどき、この語形変化の追従が上手くいかない場合がある。辞書のエントリーが例えば、以下のような場合だ。

1. 「dog」というエントリーがある。
2. 「dog」には、「dogs」という複数形がある。
3. 「dogs」という1単語だけの独立した、別のエントリーはない。
4. 「dogs and gods」というエントリーがある。

というふうに辞書が構成されている場合、dogs という単語にカーソルが合ったときに、当然、dogの意味を表示して欲しいわけだが、これが出てこない。(これはあくまでも例であって、実際のkindleでdogsに当てたときにdogが出てこないと言うわけではない)

kindleの辞書検索では、まずdogsのまま、検索し、そのエントリーがない場合に語形変化を検索するという手順を踏むようだ。ところが、上記のような構成では、「dogs」で検索した場合に、「dogs and gods」がヒットしてしまうらしい(「dogs*」と検索しているのだろう)。

ヒットしたので、語形変化形を探さないのだが、その先で、ヒットしたエントリー「dogs and gods」と「dogs」は一致しないため、ヒットしたエントリーはなしということになっているらしいのだ。

実は、対応は簡単で、要するにindexのエントリーが2語以上である場合は indexに入れなければいい。ただし、当たり前だが、2語以上のエントリーの検索はできなくなってしまう。痛し痒しというところ。

で、解決策ではないのだが、今のところ、この「2語以上」のエントリーはindex化しないというのではなくて、<idx:entry>タグのname属性を「”idiom”」として、別のインデックス扱いにしている。1語のエントリーはname属性なしとしていて、mobipocket creatorのbook settingsでも、default lookup index を空欄ししたままなので、1語のindexのみが使用されて検索されるようだ。

と、以上のことを、ごにょごにょしている、その過程で語形変化のタグ作成の処理のバグも見つかったというわけ。

ただし、残念なことに、この「idiom」という名前を付けたindexは使いようがない。無理やり使うとすると、mobipocket creatorのbook settingのdefault lookup indexにidiomと書くくらいだが、これだと、wordでの検索が行えないことになるので、使えない辞書って感じになってしまう。

そもそもは、mobipocketの <a onclick=”index_search(“idiom”, “*dog*”, ホニャララ) ” />みたいな感じに、辞書本文表示のエントリータイトルのリンクで、idiom検索の集合が出てくれたら素敵だと思って、こういう事にしたのだが、kindleのmobipocketリーダーは、<a>タグの onclick属性をサポートしていないのだ、というか、そもそも index_search()などのjavascript関係の実装がどこまでされているのかも、ちょっと怪しい感じだし。

まぁ、とりあえず、いつか、kindleのリーダーが、こうしたフィーチャーをサポートした暁には、対応がスムーズに出来るようにしておこう～ってくらいの意味しかないっていうのが現状。

Eijiro117.csv2html-v2：例によって、何が起こっても責任は持てないのであしからず。使い方は、下のscreen-shotをクリックすると出てくる感じ。（あと、細かいことは、前のアーティクルも見てね）

【追記/2009-01-25】なんか、kindleブームのようでアクセスが（超マイナーブログだったのに）異常に多い（日に200もアクセスがあるなんて…200万じゃないです、正味200です、はい）ので、念のために、このスクリプトのバグ修正版をここで追加しているので、こちらを使用願いたい。ってことで、やっぱり、上のリンクは外しておこうと思う。

う～ん、意外とハマりこんでしまった感じはあるが、とりあえず一段落しそうだ。

英辞郎ver117辞書(unicode版)から、PDICによって吐き出されたCSVファイルの文字コードはUTF-16LEという文字コードになっている。素直にこれをPerlIOで読み込んでしまうことが、とりあえず先決。

すんなりと言うわけには行かなかったが、PerlIO::encodingを使って、読み込み時に勝手にコード変換してもらえば、あとは新たにやることはない。

はずだったが、そこに行き着くまでに、まずCVS_XSの入力部分を、前述の通り、CSV_XSマニュアルの冒頭にある enbeded newline 対応コードに変更した。これは、どうもunicode版のCSVにはCRコードが含まれていないように見えたからなのだが、どうもエディタのいたずらのようで、version52のShift-JIS版と同じようにCRコードは入っているようだ。

この変更のために、CRコードと言うか、意味部分の改行の扱いがちょっと変わったので、その対応を追加。

しかし、ハマったのは、そこではなくて、なんとShift-JIS版の変換においてのこと。

PerlIO::encodingを使うようにしたので、コード変換はスマートになったのだが、Shift-JIS版に含まれる「発音記号」の部分に、unicodeへ変換出きない外字が含まれているらしく、そのワーニングが画面にゾロゾロと出てしまい、煩わしいことこの上ないのだ。これをどうにかしようとして頑張ったのだが、結局はあきらめることにした。出力には影響ないようだし。

で、Shift-JIS版はいいとして、問題のunicode版から吐き出されたHTMLファイルであるが、mobipocket Creatorに喰わせると、HTMLのパースはうまく行くようなのだが、パースの最後で、

Error(index build): master record overflow (max=64k): aborting index build.

というエラーが200個ほど発生し、結局ビルドをあきらめてしまうという結果になる。

この時の語数は1,919,664個である。max=64kの意味が不明だが、とにかくこの語数を処理するのは無理らしい。ちなみに、先頭から1,500,000個で処理させると、諦めずにprcファイルをビルドしてくれる。で、念のために 1,500,001個目から最後までのファイルも作成して処理させてみたが、これも問題ない。

と、以上は前々回のアーティクルのコメントにも書いた、さらに次もコメントに書いたが、そもそも英辞郎辞書自体の語数が多くなりすぎている気がする。純粋にデータとして考えた場合、多ければ多いほどいいというのは、理解できるが、「辞書」と考えるとそこにはやはり何らかのフィルターが必要だろう。

で、気づいたのだが、そういえばPDICで見たときに「レベル」っていうのがアルジャーノン。と、閃いた～と喜んで調べてみたら、なんと、このレベルの値は、現在『アルク』によって策定された「SVL12000」なるランク付けにおけるレベル値になっているとのこと。その名の通り、12000語に、1から12の12段階のレベルを付けているのだ。って、逆に言うと、190万エントリーもあるけど、レベル分けされているのは、そのうちのたった12000語だけ…って。使えねーとしかいいようがない。

あー、そうそうレベルの件を思いつく前、昨夜寝る前に思い立って試したのが、これもコメントに書いたが、見出し語が1語のみで成り立っているエントリーのみの抽出。実際、kindleでの使用を考えると、これだけでも事足りそうな気もする。確かに、idiomを全部切ってしまうと言うのは英辞郎辞書の数少ない『取り柄』をもぎ取ってしまうようなものではあるが、背に腹は変えられない。

あとは、見出し語の語数でフィルターを掛けるとか、その程度しか手はないような気がするが。

そういうわけで、UTF-16LEの入力に対応し、見出し語の語数で出力エントリーにフィルターを掛けるバージョンを落としておこうと思う。実のところ、ほとんど真面目にテストしていないのでkindle上に持っていった場合に不具合があるかもしれない。対応の約束はできないけど、なんか致命的に変なことがあったら教えて欲しいと思う。

Eijiro117.csv2html(バグっていたのでリンクを外しました、修正版はこちら)

おっと、使い方を忘れていた。

1. 第1引数は、元になるCSVファイルのパス。
2. 第2引数は、辞書の名前だが、ここに細工があって、WIK:nn という形式で抽出するエントリのキーの語数を指定できる。これがないと、全部取ってくるので、当然 version117とかだと、prcのビルドに失敗する。
   • WIK:1を指定すると、270,647エントリー
   • WIK:2を指定すると、1,061,544エントリー
3. 第3引数は、CSVファイルの文字コード。117の場合は UTF-16LEを指定すること。shift-jisの場合はcp932を指定する。shift-jisの場合、発音記号の部分で「ユニコードにマップできないよ」エラーが大量に出力されるが、無視してよいと思う。
4. で、肝心のHTMLは標準出力に吐かれるので、リダイレクトして好きな名前のファイルに保存すればOK。

コマンドラインは、こんな感じかな？
C:\xxxx> perl Eijiro117.csv2html.pl eijiro117.csv ejr117-WIK:2 UTF-16LE > ejr117-WIK-2.html