Namazu-devel-ja(旧)

[Yukio USUDA <m6694ha392t@xxxxxxxxxxxxxxx>]

臼田です。

Tadamasa Teranishi wrote:

> > 
> > 寺西さんの案ではmknmz内の処理は
> > 
> > ・様々な日本語文字コードの文書
> >       -> utf-8 -> 正規化utf-8 -> わかちがき (5)
> > ・ファイルシステムの文字コードでのファイル名
> >       -+-> utf-8 -> NMZ.field.uri (6)
> >        +-> 表示用文字コードでのファイル名 (7)
> > 
> > というものになるのかと思っているのですが
> > これにしてもmknmz側では utf-8 -> CP932 は出番がなさそうです。
> 
> (7) にあたるのでしょうか。uri に限らず、ファイルパスの処理も utf-8 で
> 行いたいと思っています。例えば、"\" を "/" に変えたり、ファイル名を
> 取り出したり、フルパスを繋いだり...などパス処理全般です。
前のメールの(2)の形であちこち修正したのでおっしゃっている感じに
なっているつもりです。
正規化してしまっているのをやめれば(6)に転用できるはずです。

元のファイル名から直接表示用の(7)を作るのではなく(6)から(7)を
作るようにするというのであればそれも可能かと思います。

> 処理後、ファイルをオープンする際に元のコードに戻してオープンする
> といった感じですね。
該当するサブルーチンやどの処理後かわかりませんでした
基本的にはオープンする際に用いているファイル名は
文字コード変換前の元のファイル名を用いていて、再変換等はしていないようです。
Win32だけはload_documentの中でNMZ.win32というファイルにコピーして
元のファイル名を使わずにutil::readfileでオープンさせています

このあたりはutf8index-branch作業中にわたしも気になったところです。

上記とは別の問題になりますが
load_documentで $shelter_cfile を作っているのですが、
これはWin32のときはutil::readfileと各フィルタモジュールに
ファイル名扱いの心配をさせないようにするというもののようです。

元のファイルはすべて読み込み済みであるので、フィルタモジュールには
基本的には元のファイル名を用いた操作を許しておらず、
（現状でも外部プログラムに渡す際はメモリ内の文書をNMZ.tmp.*といった
ファイルに書き出してから処理しています）
結局apply_filter内では拡張子取得のために元のファイル名が必要なだけです。
load_documentからapply_filterを呼ぶ位置を$cfileを元に戻したあとに
すればapply_filterの引数が減らせるので直したいと思います。

臼田幸生