What I wanna talk ABOUT

‘英辞郎’ のタグが付いてる分

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

何かと言うと、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


気づいてはいたのだが、対応方法がわからなかったので仕方ないと思っていた点がある。

たとえば、makeなんて単語は、実際の文中では makes, made などの形で登場するし、tallなどは taller, tallestという形でも登場する。しかし、単純に「語」の完全一致で辞書検索されると、もちろん、makes も made も make には引っかかってくれない。名詞の複数形も同様である。

kindleに標準でついてくる The New Oxford American Dictionaryでは、このあたりがちゃんと検索されるので、何らかのデータの持ち方で実現できることは、容易に想像ができるが、では、そのデータ形式は？となると、お手上げ状態であった。

が、とは言うものの、mobipocketの書籍、辞書のデータってあれほどフリーでたくさん出回っているのに、その内部フォーマットが秘密なんてことはどうもありそうにないではないか？というのが、最初の疑問。実は、やり始めの頃にも、いい加減なテンションでそういう資料がないか、ちょびっとググってみたのだが、そういうロー・テンションなので、すぐに諦めてしまっていた。

しかし、一応自分でhtmlも生成するとなると、ちょっと調べておこうかと、少しだけエンジンを吹かし気味で調べてみると、こんなページが見つかった。このページの 2.2 Inflections for Dictionaries が語形変化に対応するためのデータ形式のようだ。幸い、英辞郎の辞書データにも、それぞれの品詞に語形変化がある場合は、「【変化】」というヘッダとともに変化形を保持しているので、これを各エントリーで引っ張り出してきて、このような要素を作り出してやればよさそうだ。

ちょっと、心配なのは mobipocketリーダー的にはOKだが、kindleの辞書検索機能がこのデータを仕様して語形変化追従を実現しているかどうか不明な点だが、これ以外に語形変化に関するデータはなさそうなので、とりあえず、この形式のタグを含むHTMLファイルを生成するように変更してみた。

ついでに、このページ近辺の資料をもとにして吐き出すHTMLファイル自体も少し整理した。

で、結論から言うと、首尾は上々。ちゃんと、語形変化に追従して検索するようになった。これで、ずいぶん使い勝手が向上する。

ところで、前のアーティクルにいただいたコメントに対する調査で、知ったのだが、英辞郎辞書って、すでに version 118 とからしい。自分の使っている version 52って、2001年という超古いものらしい。で、最新のバージョンはunicode対応になっていて、おそらくはCSVで吐き出すデータもutf8とか、もしかするとUCS2なんてことになっているかもしれない？（さすがにUCS2ってことはないとは思うのだが）

それで、オプションで第3引数を受け付けるようにscriptを変更した。ここにutf-8とか書くと、CSVファイルをUTF-8のファイルと思ってオープンするはず。残念ながら、手元に英辞郎の118とかがないので、それ以外の問題が起こるのか？などについては試していない。

もう一つ、もともとのデータでキャリッジリターンが入っていたところ（PDICで見ると改行されて見えるところ）は、前のスクリプトでは、そのCRを除去して、後続の内容をそのまま続けていたのだが、これもkindleでのリアルタイム検索の表示用に、CRをスペースに置き換えるように変更した。貴重な2行表示を有効に使うためにワードラップしやすいようにするのが目的。

では、Eijiro.csv2html.plをここに落としておくことにする。拾った方はネコババしても大丈夫だけど、何かあったときに落とし主に文句を言わないように。

で、話の続きなのだが、現在、おそらく多くの人が使っていると思われる「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ファイルに埋め込まれる辞書の名前。結果は、標準出力に吐き出されるので、リダイレクトでファイルに落しているの図が上記。

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