データベースに全パターンを用意する時間はない。
そこで考えたのは、入力文字を操作することでした。
ユーザーが入力した文字をいったん加工して、
加工した文字でデータベースを検索するようにするのです。

具体例で説明しましょう。
ユーザーが入力した文字を「siwa」とします。
この中にケアナビ式以外の書き方が含まれていた場合、
それをケアナビ式の書き方に変える加工処理を行います。
この場合「si」を「shi」に変えるわけですね。
加工された文字とデータベースの内容との一致を調べます。
一致すれば、それを候補として表示します。

この加工処理を、入力文字にかけるフィルタと考え、
「si」は「shi」に、「tu」は「tsu」というように
このフィルタを通して文字列を変えてしまうようにします。
どんな文字をどんな文字に変換するかのパターンは、
あらかじめ一覧表を作っておき、フィルタとして
システムに組み込んでおく仕組みにします。

こうしたフィルタがあれば、データベース側で
バリエーションを用意しなくてもいいので、
作業量は大きく軽減されます。

これで楽勝やね～！と思っていたのですが、
これには大きな落とし穴がありました。
すべてが単純変換すれば良いわけではない、
ということに気付いたのです。

例えば「ti」がそうです。
「ち」と入力したくて「chi」の替わりに「ti」とした、
あるいは「てぃ」と入力したくて「ti」と入力した、
という２つの可能性があります。
「tii」は「地位」のつもりなのか「ティー」のつもりなのか
ローマ字を見ただけではユーザーの意図が判断できません。

このため、ただ単にフィルタを通して処理すると
「tii」は「chii」と加工され検索されてしまうことになり、
適切に入力しているのに「ティー」は表示されません。
これは大きな問題です。

ローマ字にはこうした厄介な表記がいくつかあり、
万事解決かと思われたフィルタの導入も頓挫。
また苦悩の日々が続くのでした。

2007.12.01 15:09 - すなみ