Namazu-devel-ja(旧)

[Yukio USUDA <m6694ha392t@xxxxxxxxxxxxxxx>]

臼田です。

Tadamasa Teranishi wrote:

> > pl/codeconv.plから
> > shiftjis<->eucjpに使われていた
> > eucjp_to_shiftjis, etos, shiftjis_to_eucjp, stoe, toeuc
> > を削りました。
> > 
> > あわせて
> > filter/win32/{oleexcel.pl, olemsword.pl, olepowerpoint.pl}
> > からのcodeconvの呼び出しを変えました。
> 
> 中身を見ずに書くのも何ですが、perl 5.8 の方は良いとしても、
> nkf 2.04 を使う方では、これを削除しちゃうのはまずくないでしょうか?

> というのも、nkf 2.04 を使って変換しちゃっているのではないかと
> 思うからです。(違ったら御免なさい。)
そのとおりです。nkfのほうだけでなくperl5.8のほうも全部正規化しています。
uri変換に使えば問題になります。
一度何が欲しくて、何が問題なのかを最初から整理して直していこうと
思っています。


> この辺りの関数は半角カナをそのまま半角カナとして変換することを
> 期待しています。nkf を使ってしまうと全角に変換されて困ったこと
> になるはずです。(純粋に漢字コードの変換のみを行う関数郡)

> # そんなことはちゃんと考慮しているよってことでしたらごめんなさい。
ファイル名の変換をshiftjis→euc（正規化つき）→uriエンコードしている
手順に問題があるのですが
shiftjis→euc→uriエンコードとしてもeucにない文字が消滅したりするため
結局完全な仕様とはなりません。

shiftjis→uriエンコードという変換のみにしておけばこの問題は根本
から解消されます。
> では、$INDEXFIELD_FILESYS_CHARSETは廃止して、文字コード変換をせずに
> 元のバイナリコードのままuriエンコードすることにします。
> （という意味の統一ですよね）
> 
と書いたのはこれのことです。

そのため表示用に別途NMZ.field.duriというのを設けてみました。
あるいは、元のバイナリコードからuriエンコードしたNMZ.field.uriを
namazu側で文字コード変換処理をして表示するのがよいと思います。

元のファイル名のバイナリコードが保管されないことによる問題は
可読性を高めたいという要求に応じようとすれば
いずれWin32のshiftjisのみでなくutf-8等でも発生します。

消してしまったルーチンはWin32でしか使われていないものでした。
文字コードの問題はWin32特有の問題ではないため、一般化して考える
ほうがよいです。あえて消していこうと考えました。

> > filter/rpm.plのsummary作成個所にバグらしきものがあるのを見つ
> > けたので修正しました。（utf8index-branchのみ）
> 
> 冗長な部分とか無意味な部分とかありましたが、バグらしいものも
> ありましたか。
filter内でSummaryを生成する処理だったのですが、式の順序が逆に
なっていてなにも入らないような処理になっていました。
nkfに渡す処理のところでエラーが出たため発覚しました。

臼田幸生