Namazu-devel-ja(旧)

[Yukio USUDA <usuda@xxxxxxxxxx>]

臼田です

たくさん反応があったので、私も意見を書かせてもらいます、長文ですみません。
下のメール参照部分はかなり切り貼りしているので、原文の意を損ねているかも
しれません、元のメールも参照してください。
また、文字コード問題についても詳しくないので識者の意見をいただきたいところ
です。

HIROSE Yoshihide <yoshihide@xxxxxxxxxx> wrote:
> 出てくるのは不可避ですよね。かといってnamazuでそれらの機能を
> 独自に実装するというのも非現実的です。また、フィルタのメンテナの
> かたの負荷が増えてしまうようでは、嬉しくない気がします。
自分で一太郎フィルタを付け加えておいて言うのもなんですが
確かに車輪の再発明は避けた方が良いと思います。
NamazuProjectでメンテナンスする部分が増えるのもよくないので
他でメンテナンスされているものを利用するのが良いと思います。
ただ、ライセンスがGPLでいっしょに配布してしまってよいものがあれば
いっそ同梱してしまうという選択もあるのかもしれません。

Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx> wrote:
> 現状、perl 5.8 しか動かないという制約をつけるのは厳しいかと
> 思います
> これらは perl 5.8 の「Encode」は機能的にまずい問題があるということで
> なければ、という前提の話です。
Perl5.8のEncodeの評価のほかにも
mknmzがPerl5.8で問題なく動いているという報告が欲しいです。
また、5.8への移行が問題になるスクリプトがNamazuでなくても存在するようならば
当面はあまり強く推奨できないようにも思えます。
Perlのモジュールをたくさん利用している人ほど再インストールの手間から移行を
嫌がるような気もするのですがいかがでしょうか。

Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx> wrote:
> perl 5.8 の「Encode」のインターフェイス互換の lv, iconv の
> ラッパを用意すると、移行が楽かもしれませんね。
> # そこまでやる必要があるかは別問題です。

> 各フィルタを perl 5.8 の「Encode」に対応する作業は、確かに負荷の
> 高いものですが、やるだけの価値(利用者にとってのメリット)は
> あるかと思います。
"Sakuma,Hiroaki" <sakuma@xxxxxxxxxx> wrote:
> Encode機能を使ったラッパのようなものを実装しておいて，フィルタ側から使えるよ
> うにして頂けば，使いやすいかと思います．
今後UTFが利用された文書が増える可能性はあるのでshare/pl/codeconv.pl内に
サブルーチンとして準備しておくのが良いと思っています。

Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx> wrote:
> perl 5.8 「Encode」ライクなモジュール(といっても from_to ぐらい)を
> 提供し、フィルタはそれを使ってもらうようにするということです。

> ただ、フィルタプログラムを見たところ、そんなにコード変換が必要と
> いうわけでもなさそうなので、

> あとは、フィルターから文字コード名を渡して、現在の環境で使用できるか
> どうか問い合わすことのできる関数があればよいと思っています。
> (これはフィルターの status() 辺りで利用するため)
今後国際化のために内部をUTF化するとかという構想が出ればまた別の議論が必要
になるのでしょうがNamazuは内部EUCで処理しているようなので???_to_euc()と、
filterスクリプトのstatus()に対して変換できる環境の準備ができているかどうか
を返すサブルーチンの２つだけ用意してあげれば現状十分なのでしょう。

> こうすることで、フィルタを作る人は楽にコード変換ができます。
> (どのような外部コマンドがインストールされているのか気にする必要が
> なくなります。)
これは今後に備えて必要かと思っていました。
変換ツールのどれを使えばよいか悩まなくてすむようになります。
ただ、問題はそれぞれの変換ツールによって、
・変換結果が違わないか
・日本語文字コードの範囲外のものを渡したときの結果
・UTFのコードの範囲外のものを渡したときにおきる結果
がどうかという点を気にしています。
それによって複数インストールされている場合の優先順序や、
非採用にしなければいけない変換ツールなどがあるかと思います。
一太郎７以降のフィルタでUTF16→EUCをしているのですが罫線等のコントロール
コードが混じったまま変換ツールに渡しています。これらを除外するのは
EUCにしてしまってからの方が楽なので私が処理をサボっているのですが、
厳密な変換ツールだとバイナリデータは変換できないといって処理を拒否する
ことと思います。

どの変換ツールを使用するかについては、
・Namazuインストール時に決めてmknmzrcに書き込む
・mknmzのinit()実行時に走査して決める
・各filterのstatus()実行時、実際の変換時に走査して決める
のどれかになると思います。
いまのところ
・インストールをしなおさなくても良い
・mknmzに手を加えなくても試せる
ということからfilter内で処理するように考えていますが
小さな処理でも無駄なので徐々に手を加えていく必要があると思っています。

Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx> wrote:
> 今のところ、NKF に関してはあまり考慮していません。(あれだけは、
> 併用していいかなという気がしています。)
NKF2.0のUTF対応が十分であればこれの使用で統一してしまうのも良いの
ではとも思っています。
利点としてWin32用バイナリ配布ではNKFのPerlモジュールをmake済みで
提供しているのでうまくすれば追加インストールするものが一つ減らせ
るのではと思っています。
このあたりはWin32用のバイナリを作成している方の意見が聞ければと思
います。

Ryuji Abe <raeva@xxxxxxxxxxxx> wrote:
> CPANにEncode::compatというのが存在します。これはText::Iconvの
> wrapperです。
Perl5.6以前用にCPANにJcode.pmという定番ものもあるのですが
・Perl5.8への繋ぎの過渡期であるので一つのものに依存しない方がよい
・Jcode.pmのインストールの他にJcode.pmが要求するMIME::Base64のインス
　トールなど本来求めること以外にすることが増える
ので選択肢から外しました。

Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx> wrote:
> と、ここまで書いて実際フィルタを覗いてみると、現状 lv で utf8 を 
> euc-jp に変換しているぐらいしか使っていませんね。
現状UTFを扱わなければいけないfilterも少ないのでコード変換部分を修正
するのは大した手間ではないと思います。どの変換ツールを採用し、どの
ような形で呼び出すのが良いかというポリシーを決めておくのが大事だと
思っています。

どのように実装しても大した問題ではないのかもしれませんがせめて
namazu-develで利点欠点等うかがってから手を加えたほうがよいと思って
おります。

いろんな視点での意見がいただければと思います。

臼田幸生