Namazu-devel-ja(旧)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ooo.pl (OpenOffice.org用フィルター)commitしました。
寺西です。
Yukio USUDA wrote:
>
> Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx> wrote:
> > 現状、perl 5.8 しか動かないという制約をつけるのは厳しいかと
> > 思います
> > これらは perl 5.8 の「Encode」は機能的にまずい問題があるということで
> > なければ、という前提の話です。
> Perl5.8のEncodeの評価のほかにも
> mknmzがPerl5.8で問題なく動いているという報告が欲しいです。
これは欲しいですね。
> また、5.8への移行が問題になるスクリプトがNamazuでなくても存在するようならば
> 当面はあまり強く推奨できないようにも思えます。
そう思います。
> Perlのモジュールをたくさん利用している人ほど再インストールの手間から移行を
> 嫌がるような気もするのですがいかがでしょうか。
# 自分も Perl 5.8 にしていないのに書くのは何ですが...。
まぁそうですが、逆に Perl 5.8 を使っている人にとっては、
わざわざ外部プログラムを別に入れないといけないのは、
わずらわしいでしょう。
今までの Perl は(Namazuにかぎらず)バージョンアップしなくても、
あまり困らなかったからというところはあるかと思います。
5.8 に関しては、Unicode 正式対応ということで、少しだけバージョン
アップの魅力があるように思っています。
# 世間的にはどうなんだろう。4 から 5 へは簡単に変わったのになぁ。
> 今後国際化のために内部をUTF化するとかという構想が出ればまた別の議論が必要
ここまで広げると、ちょっと大変ですね。でも、国際化の野望は
あったように思います。
今回は、国際化の話とは分けて議論したいと思います。
> になるのでしょうがNamazuは内部EUCで処理しているようなので???_to_euc()と、
> filterスクリプトのstatus()に対して変換できる環境の準備ができているかどうか
> を返すサブルーチンの2つだけ用意してあげれば現状十分なのでしょう。
入力が Unicode の外部フィルタに渡すこともありうるかと思いますので、
???_to_euc() では不十分かと思っています。
まぁ、今のところは ???_to_euc() で良いわけですが。
将来、???_to_??? を増やしていくというのもいいですが、
from_to() で統一するのも良いのではないかと思います。(フィルタに
関しては)
# とりあえず to は eucjp だけサポートとしても。
> ただ、問題はそれぞれの変換ツールによって、
> ・変換結果が違わないか
> ・日本語文字コードの範囲外のものを渡したときの結果
> ・UTFのコードの範囲外のものを渡したときにおきる結果
> がどうかという点を気にしています。
無難なものから優先的に使うしかないかと思います。
または、フィルタ固有の問題があるなら、フィルタ内で優先順位を指定する
仕組みを用意するのがいいのではないでしょうか。
優先順位によっては、ある変換ツールは使用しないといった指定が
できれば良いのかもしれません。
外部プログラムへの対応がひとつ増えた場合に、自動的にそれに
対応するのはうれしいことですが、支障がでるのでそのプログラムは
使いたくないといった場合もあるので、ここの仕様は難しい
ところだと思います。
また、こういった互換性の問題を排除する意味でも perl 5.8 の
「Encode」を意識しておくことは重要かと思います。
5.8 必須はまずいとしても、5.8 ならコード変換の外部プログラムの
インストール/互換性問題から開放されるのなら、5.8 をインストール
しようと思う人も出てくるでしょう。
> 一太郎7以降のフィルタでUTF16→EUCをしているのですが罫線等のコントロール
> コードが混じったまま変換ツールに渡しています。これらを除外するのは
> EUCにしてしまってからの方が楽なので私が処理をサボっているのですが、
> 厳密な変換ツールだとバイナリデータは変換できないといって処理を拒否する
> ことと思います。
必要ならゴミを削除するフィルタをかますべきでしょうね。
> Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx> wrote:
> > 今のところ、NKF に関してはあまり考慮していません。(あれだけは、
> > 併用していいかなという気がしています。)
> NKF2.0のUTF対応が十分であればこれの使用で統一してしまうのも良いの
> ではとも思っています。
NKF は 1.9X の問題があったりしますし、2.0 は大丈夫なのかと
いう心配もあります。
また、NKF 2.0 必須というのもちょっときついかなぁという気も
します。(perl 同様、namazu 以外の用途に使っているケースも多々
あるので、2.0 を強要するのは大丈夫だろうかと思います。)
> Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx> wrote:
> > と、ここまで書いて実際フィルタを覗いてみると、現状 lv で utf8 を
> > euc-jp に変換しているぐらいしか使っていませんね。
> 現状UTFを扱わなければいけないfilterも少ないのでコード変換部分を修正
> するのは大した手間ではないと思います。どの変換ツールを採用し、どの
> ような形で呼び出すのが良いかというポリシーを決めておくのが大事だと
> 思っています。
そのようです。
--
=====================================================================
寺西 忠勝(TADAMASA TERANISHI) yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E