Namazu-devel-ja(旧)

[Yukio USUDA <usuda@xxxxxxxxxx>]

臼田です

knok@xxxxxxxxxxxxx wrote:
>  perl 5.8 対応については、HEAD (2.1系)でやってしまうのがいいかなあ、
ということですので考えていることを整理がてら、、

Tadamasa Teranishi wrote:
> コード変換に関しては、次のように個人的には考えています。
> 
> 1. 従来通り全環境で様々なコード変換プログラムを使って作る。
> 2. 5.8 以降は Encode を使い、それ以前は様々なコード変換プログラムを
>    使って作る。
> 3. 5.8 以降に限定し、Encode を使う。
> 4. 5.8 以降は Encode を使う。それ以外は、様々なコード変換
>    プログラムを使う。5.8 以降でも、スイッチにより Encode を
>    使わないモードで使うことができるようにしておく。

私は最大公約数的な案４だろうと思っていました。
（動作検証対象が増えるので、いまのmake checkの全体検査のほか
にshare/{pl,filter}以下のモジュール等の単体検査の方法も考えて
いくのがよさそうですけど）

互換性は維持しておくもののPerl5.8のメリット（当面は速度？）
を元に移行を促し（メリットがみつからないと積極的に移行しない
ですよね）そのうえで将来の移行状況を視野に入れてindexをUTF-8
化できる準備を整える。といった感じでしょうか？

indexのutf-8化は内部処理eucのままでもできるかもしれないですが
内部処理utf-8化しないと多言語対応にむかわないでしょうし、
内部utf-8化まではPerl5.8のみにする理由は弱いと思います。
段階を踏んでやるのがよいのか一度にやってしまうのがよいのか
難しいですね。

案４のようなコードにするとして具体的には各フィルターモジュール
がやっている環境チェックのような感じで
codeconv.plが最初に呼び出されたときに使用できる環境をチェックし
coodeconv.pl内変数に登録し、処理時には変数を参照しつつ利用可能な
ツールで処理（場合によってはスイッチで強制的に指定）し、コード変
換の外部ツールはフィルターモジュールから直接呼び出すのはやめる。
となるのでしょう。

ただ、コード変換はどこが責任をもってするのか？、変換前コード名の
特定はどこでするのか？というところを整理したほうがよいと思ってい
ます。

現状はコード変換は原則 mknmz内、場合によってfilterモジュール内
となっています。これはfilterモジュールが
　・モジュールに渡される前のコード変換
　・モジュールから渡した後のコード変換
の必要の有無をpre_codeconv,post_codeconvとして1or0で事前に登録
しているためだと思います。

post_codeconvについては文書を読み込む前に必要性の有無のみ登録
しているだけで、filter内で実際の文字コード名が判明してもmknmz
に知らせることができず利用価値が低いものになっています。
（ms-wordやexcelのファイルは内部コードがsjisの場合とutf8の場合
　がありファイルを読み込むまでわからない）

Ａ．モジュールからの返り値として文字コード名を渡す
　　フィルターモジュールの引数が一つ増えるので互換性が少し悪く
　　なる。post_codeconvは参照しない。
Ｂ．post_codeconvの返り値を1,0だけでなく文字コード名も返すよう
　　にしてフィルターモジュールでの文書処理が一件終わるごとに呼
　　び出す。('sjis','euc','utf-8'を返し、0が返ってきたときはeuc
    1が返ってきたときは文字コード名不明として扱うことで互換性を
    保っておく）post_codeconvの事前呼び出しはやめる。
Ｃ．コード変換はフィルターモジュール内で責任をもって完了させる。
　　post_codeconvは参照しない。
Ｄ．nkfやPerlのEncodeのguessにまかせてしまって今の形で済ます。
　　既にnkfもutf-8も扱えるように改良されているので
　　http://www.namazu.org/ml/namazu-users-ja/msg02780.html
　　post_codeconvは今の扱いのまま。

といった対応を考えたのですが、APIが変わるのを気にしなければＡが
シンプル。（現在の$$$$$という引数は既に多いような気がしますが）

また、codeconv.plでのラッパーを充実させて使いやすくして文書化し
てしまえばＣがよい。（一太郎のファイルが１つのバイナリファイル
の中でUTF16BE、UTF16LE、SJISと複数種類使用しておりＡ，Ｂ，Ｄの
方法では対処しきれない場合が他にも出てくるだろうと思えます）

Ｄは文字コード名が分かっていても推測しなおすのは不思議な気がし
ます。文字コードの推測が完璧で時間もかからないということならば
これもわかりやすいのかも。
（nkf1.71へのリンクも切れてしまっているのでチュートリアルのページ
はnkf2向けになおさないといけないですね）

とよくわからなくなってしまいました。

臼田幸生