Date:  Sun, 9 Apr 2000 23:24:32 +0900
From:  monyo@home.monyo.com
Subject:  [analog-jp:00066] Re: analog.cfg を	JIS コードで実行できない理由 ( Re:  FW: Analog 4.04)
To:  analog-jp@monyo.com
Message-Id:  <20000409232429P.monyo@home.monyo.com>
In-Reply-To:  Your message of "Sun, 9 Apr 2000 23:10:30 +0900"	<200004091410.XAA15212@pegasus.tokyo-kasei.ac.jp>
References:  <200004091410.XAA15212@pegasus.tokyo-kasei.ac.jp>
Posted:  Sun, 09 Apr 2000 23:24:29 +0900
X-Mail-Count: 00066

  たかはしもとのぶです。

>わかりました。これは、前にたかはしさんが書かれたように
>「結局 2byte 文字コード処理はもっときちんとやらないとダメという所に落ち
>着きそうです。」
>ですね。

そうですね。2byte 文字コードの処理を行なうためには、最低でも char* の
データを扱う関数は、基本的に全て対応しているかどうかをチェックする必要
があると思います。対応していない場合は、必要な処理を行なわなければなり
ません。

Samba とかは、そこまでやっているのでかなり対応できているのですが、
Analog の利用目的などを考えると、そこまでの事を求めるのはちょっと厳し
いと思います。現状 EUC であまり問題が出ていないことを考えると、とりあ
えず日本語に関しては、EUC で問題が出ないことに注力するというのが妥当な
結論のように思います。これで Turner の方には、報告しておきませんか?

必要であれば、EUC の出力結果を他の文字コードに変換することはできるわけ
ですから、運用面でもそんなに困らないと思います。

HTMLのアウトプットを調べていましたが、

検索結果レポート	日本語化されている（EUCとShiftJISが混ざっている場合には
			もちろん、ShiftJISは文字化けしている）
検索語レポート		日本語化されている（上と同じ）

>というふうに、プログラム側でコードを揃えておいても、結果のアウトプットには、
>結局コードが混ざっている場合が生じているので、jcode.pl を使うか、nkf を使うか
>して、コードを統一するという作業が必要になります。

これも、検索文字列がどのようなロケールで入力されたものかが分からないと、
原理的に文字列を常に正しく処理することはできないので、対応には限度があ
ります。とりあえず Turner には問題点があるという報告だけをしておけば良
いのではないかと思います。

-----
TAKAHASHI Motonobu (高橋 基信)        mailto:monyo@home.monyo.com
                                      http://home.monyo.com/