Namazu-devel-ja(旧)

[knok@xxxxxxxxxxxxx]

> >   uri の encoding を何らかに統一することは賛成です。国際化を考慮すると、
> > やはり UTF-8 にするのが良いのでしょうか。
> 
> とりあえず euc-jp で。
>
> UTF-8 化はインデックス全部のコードを変更する際(いつのことやら)に
> あわせておこないましょう。

  はい、性急に今すぐ対応しよう、という意図はありませんでした。

> > > マルチバイト文字コードの操作に、libmbflを使おうと考えています。
> > 
> >   うーん、普通に iconv で良いような。
> 
> unicode に対応していない(だったか、Shift_JIS だったか) OS 付属の 
> iconv があったりするので、GNU iconv を強制的に使うようにするのなら、
> それでも良いかもしれません。

  NetBSD 方面では、また別の iconv 実装もあるようです。それはともかく 
iconv を推したのは、標準(UNIX98?)的な API であるものの方がいいかなあ、
と思った次第なのですが、複数対応するのもアリかなという気もしてきました。

At Mon, 08 Dec 2003 21:24:54 +0900,
Yukio USUDA wrote:
> http://search.namazu.org/namazu-devel-ja/02981
> で試したころにmknmzでのインデックスUTF-8化はそれなりにできそうな
> 感触を得たのですがテストを作るのが大変そうなので手をつけていませ
> ん。
> エンバグは心配なので、とりあえずUTF-8対応化のブランチを作ってはじ
> めませんか。

  HEAD でやってしまってもいいかもしれません。

> 詳しくはないのですがmknmzで気になっている２点だけ書いておきます。
> ・Namazu2.1ではインデックスはUTF-8とeuc-jpと両方サポートするのか？
>   あるいはUTF-8のみにするのか？
> 　euc-jpも選べるようにするならば、UTF-8変換ツールがない場合でも動作するよ
>   うにするのか？

  段階的移行を考えると、両方対応すべきですかね... 

> ・mknmzでいままで使っているnkfは文字コード変換だけでなくmimeデコード機能
> 　も受け持っているので、Unicode変換ツールにはUTF-8変換と同時にmimeデコード
> 　機能もあるPerl5.8もしくはnkf2.0のみを対象とするということでよいか？
> 　（iconvなども選べるようにする場合はmimeデコードルーチンが別途必要になるが
> 　それでも対応しておくか。）
> 　また、国際化を考えると日本語コード処理に特化しているnkf2.0やjcode.pmの利
> 　用は後に問題になる気もします。

  この辺りは新しいものに合わせる、で良いと思います。
-- 
野首 貴嗣
E-mail: knok@xxxxxxxxxxxxx
	knok@xxxxxxxxxx / knok@xxxxxxxxxx