(=suffix.txtを探す)いぬだ(=dictionary.txtを探す)を見れば「犬だ」が拾えるようになり、一気に守備範囲が広がるようになりました。文脈IDを無視して繋ぐと、すこし不自然な変換が発生する場合がありますが...そこは、よしなに。実はMozc辞書ではほぼカバーされているように見えて、おかし、おけいこ、ふせいかい、みぶんるいといった単語は2語ではなく1語で単語登録されています。細かい点はきりが無いので、これが最後のキモの部分です。573が採番されている単語を特別扱いします。「温ま」+「った」のように、単語にsuffixの「っ」が続く語が1000語程度あります。(例:有、漁、生き残、入れ替、埋ま、怒、終わ)このID573「以外の」単語に、「っ」で続けてもしっくりきません。犬った、食べった、とか。よって、文脈IDが573か否かで、あとに続くsuffixを許容するか否かを判定する処理を入れました。(この千語はDBとは別に、直接コード内に持ちました)このへんの話は、実際に変換をやってみないと気が付かないし、たぶん調整の余地は次々に出てくると思います...が、とにかく試しに変換機能を作って実際に文章を書いてみたほうが早い気がしました。細かい調整を"全て"入れていくと、最終的には(既存の)Mozcのライブラリが完成するだけなので、それなら最初からMozcをフルで導入すればいいと思います。結果そうなるのもアリですが、まずは自分の目的に合わせて工夫・実装してみましょう。日本語の仕様ではなく、DBの観点でサイズの削減を目指す話です。まで(未加工)で合計55MBくらい。ここから、文脈ID列を削ってDBへ突っ込んだら、100MBくらいになりました。都合、100個以上に分割する必要があります。(分割はともかく、総量100MBは大きい...以下ではもう少し削減を試みます)私の場合は先頭文字と総文字数で区切りました(「イヌ」だと「イの二文字DB」に入れる)犬、居ぬ、往ぬを同じDBに入れて、一回で取り出したかったので。変換前後で同じ(つまり「平仮名」のまま登録されている)データが大量に有ります。中身を見る例として、10文字以上の無変換の語。"ありがとうございました"のような変換です。そこへ「カタカナ」に変えただけのものも加えると、もっとあります。レインボーマウンテンブレンド、レギュラーソリュブルコーヒー、とか。カタカナに変換して返す)、とすれば、DBのデータ量を減らせます。辞書内の他の語と被らず、支障の無いてきとうな一文字で)検索処理的には一手間増えるわけですが、DBサイズを減らすことを優先しました。†Androidに、SQLiteとして辞書情報を入れたのですが、SQLiteの数字(NUMBER)のサイズって可変なんですね。収まるっぽいのですが、コスト(単語の優先順位情報)は127を超えるのが大半です。128以上で2byteになれば、単純にサイズも倍、ですね。今回は予測変換や学習機能は使わない、つまり、文脈IDとの組み合わせによる正確なコスト計算を行っていない、ので、DBに入れる際に、コストは127未満になるように振り直すことにしました。今回は付けるのはやめました。インデックス分のサイズが増える割には、付けなくても十分早かったからです。これは環境や設計方法によるので、実際に動かしてみないと分からないと思います。SQLite用のDBを作ります。上記を踏まえて、もっと上手くやる為のアイデアの一助になれば、なによりです。副産物として、面白かったのは「逆変換」です。Office)とかには付いていましたよね、確か。いぬ」にもどすやつです。全てのDBを、しかもキーではない値を全検索なんて、正気の沙汰とは思えない処理だったのですが、やってみると、想像よりは遥かに早かったです。dictionary0*.txtコマンドラインで「この程度」の早さなら、DBでもそこそこの早さが期待できるんじゃないか、と想像がつくと思います。使ってみると、面白い、です。フィードバックしておこうと思いメモを残しました。データが古くても良いなら、このランキングづけ遊びはわりと楽しいです。grepで拾ってコストでソートすれば、誰が有名(?)なのか分かります。使用して作成しています。使用しています(このサイトについて)。