環境:
・OS CentOS5
・サーバ文字コード EUC-JP
・Apache2.0にmod_encoding適用済み
症状:
1、estseek.confにて
replace: ^file:///mnt/DevelopData/データシート/{{!}}http://server/DATA/DataSheet/
とした場合、検索結果には、
file:///mnt/DevelopData/%A5%C7%A1%BC%A5%BF%A5%B7%A1%BC%A5%C8/NEC/NEC_2SK3479.pdf
とhttp://から始まらずに、file://から始まる。
2、estseek.confにて
replace: ^file:///mnt/DevelopData/DataSheet/{{!}}http://server/DATA/DataSheet/
とした場合、検索結果には、
http:///mnt/DevelopData/%A5%C7%A1%BC%A5%BF%A5%B7%A1%BC%A5%C8/NEC/NEC_2SK3479.pdf
とhttp://から始まるが、途中の日本語フォルダ名がURLエンコードされたまま
でファイルが開けない。(ファイル名が日本語の場合はファイル名もエンコード
されたまま)
個人的には先程の回答がヒントにならないのでしたらあきらめたほうがよいと思います。
一応estseek.cの書換え例を提示します。ただし、コンパイルが通ることは確認しましたが動作は一切確認していませんし、フォローもできません。少なくともエラーチェックがはいっていないのはよくないはずです。それから、コメント欄をオープンにすることをお勧めします。
estseek.cのshowdoc関数の先頭部分の当該部を以下に差し替え(最初から3行目以降最後から3行目までが差し替える内容)、
int i, id, wwidth, hwidth, awidth; char *j,*k; id = est_doc_id(doc); if(g_showlreal){ if(!(uri = est_doc_attr(doc, DATTRLREAL)) && !(uri = est_doc_attr(doc, ESTDATTRURI))) uri = "."; } else { if(!(uri = est_doc_attr(doc, ESTDATTRURI))) uri = "."; } j = cburldecode(uri, NULL); k=est_iconv(j, -1, "EUC-JP", "UTF-8", NULL, NULL); uri = k; free(j); turi = makeshownuri(uri);
showdoc関数の最後尾を以下に差し替え(2行目の追加)れば
free(turi); free(k);
先程回答したような動作になる「かもしれません」。
データの場所がapacheがアクセスできる範囲外になっているのでは。
それとローカルのURL自体がおかしいです。
http://サーバー名/~ユーザー名/.../ファイル名
とならないと。
御返答有難うございます。
データはブラウザで表示可能ですので、問題はありません。
またURLはユーザーディレクトリー配下ではありませんし、Hyperestraierのreplaceが正しく置き換え出きないのが問題なのです。
サーバ文字コードというのは、サーバ上のファイル名が EUC-JPであるという意味でしょうか?
一応その前提で書きます。
1. は
replace: ^file:///mnt/DevelopData/データシート/{{!}}http://server/DATA/DataSheet/
ではなく、
replace: ^file:///mnt/DevelopData/%A5%C7%A1%BC%A5%BF%A5%B7%A1%BC%A5%C8/{{!}}http://server/DATA/DataSheet/
のように記述する必要があります。これは、インデックスに収録する時点で既にURLエンコードされているためです。
2. は書かれているものと異なる変換ルールが適用されているように思います。更に言えば、書かれたルールでは提示されたURLにマッチしないので適用されないと思います。
replace: ^file{{!}}http
あるいは、
replace: ^file://{{!}}http://
のようなルールがどこかにありませんか?
開けないということですが、日本語を含むファイル名を見に行ったときのapacheのログはどうなっていますか? ここがURLエンコードされたままの文字列でファイルを見に行こうとしているのであればHyper Estraierではなくapacheの問題だと思います。
返答有難うございます。
ご指摘の通り、replaceにURLエンコードされた文字列を入れる方法もあるのですが、それですとファイル名が日本語だとURLエンコードされてしまうので、無理だと思うんですよ。
NamazuのようにIndexする際に、オプション-U指定で変換せずにIndexingして、CGIからは、Apacheのmod_encodingでエンコードを指定するような方法は無いかと思いまして。
最初に書きたかったのですが、ここの文字制限で記入する事が出来なかったのです。
mknmz -Uに相当するような事(実際に試したことはないですが、最終的に、検索結果の出力にある
<a href="...."
の部分がURLエンコードされていない状態と理解しました)は、少なくともestcmd + 標準のフィルタではできないと思います。
インデキシングの際に文書ドラフトを作れば可能かもしれませんが、実際にできるかどうか、動作に支障を来さないかどうかについてはよく分かりません。
確実なのはestseek.cを書き換えて、URLエンコードをデコード後、utf-8に変換して出力させる事でしょうか。estseek.c 内ではcburldecodeというURLエンコードをデコードする関数が使えるのでそんなに難しくはないと思います。
すいません、その辺りを少し詳しくご指導願えますでしょうか?
当方、余り知識が無いので、宜しくお願い致します。
もしくは、ヒントになるような物でも構いません、宜しくお願いします。
個人的には先程の回答がヒントにならないのでしたらあきらめたほうがよいと思います。
一応estseek.cの書換え例を提示します。ただし、コンパイルが通ることは確認しましたが動作は一切確認していませんし、フォローもできません。少なくともエラーチェックがはいっていないのはよくないはずです。それから、コメント欄をオープンにすることをお勧めします。
estseek.cのshowdoc関数の先頭部分の当該部を以下に差し替え(最初から3行目以降最後から3行目までが差し替える内容)、
int i, id, wwidth, hwidth, awidth; char *j,*k; id = est_doc_id(doc); if(g_showlreal){ if(!(uri = est_doc_attr(doc, DATTRLREAL)) && !(uri = est_doc_attr(doc, ESTDATTRURI))) uri = "."; } else { if(!(uri = est_doc_attr(doc, ESTDATTRURI))) uri = "."; } j = cburldecode(uri, NULL); k=est_iconv(j, -1, "EUC-JP", "UTF-8", NULL, NULL); uri = k; free(j); turi = makeshownuri(uri);
showdoc関数の最後尾を以下に差し替え(2行目の追加)れば
free(turi); free(k);
先程回答したような動作になる「かもしれません」。
ご指導ありがとうございます。
コメントを表示するようにしました。(知らずに設定していたみたいです・・・)
で、少し教えてほしいのですが、est_iconvの引数の意味を知りたいのですが、
googleで検索してもHitしないので、是非お願いします。(第1、3,4引数は何となく判るのですが、その他が)
で、改造後の結果としては、
①replaceにURLエンコード後のフォルダ名を設定
②英名のPDFファイルはアクセス可能。和名ファイルは相変わらずURLエンコードされたまま。
(再インデックス化は実行)
と言う状態です。
ご指導ありがとうございます。
コメントを表示するようにしました。(知らずに設定していたみたいです・・・)
で、少し教えてほしいのですが、est_iconvの引数の意味を知りたいのですが、
googleで検索してもHitしないので、是非お願いします。(第1、3,4引数は何となく判るのですが、その他が)
で、改造後の結果としては、
①replaceにURLエンコード後のフォルダ名を設定
②英名のPDFファイルはアクセス可能。和名ファイルは相変わらずURLエンコードされたまま。
(再インデックス化は実行)
と言う状態です。