[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FDclone-users:00375] Re: 日本語文字コード(UTF8)環境での動作について

　レスポンスが遅れまして、申し訳ありません。
　前回までの patch の動作検証結果をご報告させて頂きます。


　まず、patch(2005/04/06)についての動作報告です。

　カレントを UTF-8 な日本語名のディレクトリに置いた場合での起動を確認しました
。
　いくつか別名でディレクトリ名を用意し、複数のパターンを試してみましたが、今の
所は特に問題は無いようです。

　一応、気になった点としましては、

　　1.通常（日本語ファイル名以外）からの起動時に比べ、若干時間がかかる
　　2. UTF-8 以外のディレクトリからの起動は不可のまま

の二点です。
　1.は、単純に判定ルーチンが入る関係なのでしょうね。
　2.については、あくまでも今回の patch は UTF-8 に対する adhoc な対応と言うこ
とでしたんで、まぁ、予想の範囲内です(^^;)。


　続いて、patch(2005/04/08 - 内部コードのUTF-8化）の確認です。

　FD上で、日本語ファイル/ディレクトリ名を用いるパターンをいくつか想定し検証し
てみました。


1.ディレクトリ移動１（IN_DIR）
　問題無し


2.ディレクトリ移動２（LOG_DIR）
　問題無し


3.ディレクトリ移動３（内蔵シェル使用）
　EXECUTE_SH にて、内蔵シェルを起動し、以下のコマンドを実行

　$ cd <日本語ディレクトリ名> 

　結果、日本語文字列が文字化けして表示された後、「bad directory」と表示され、
ディレクトリ移動は出来ません。
　エラーメッセージをリダイレクトしてファイルに保存し、コンソールの設定や、エデ
ィタ等で確認した所、 UTF-8 のコードとしては認識されていますが、やはり文字化け
しています。
　念の為、 Charset を他の文字コードに設定し、それぞれ表示させてみましたがどの
コードでも元の正常な文字列として表示されませんでした。


4.日本語名ディレクトリの作成１（MAKE_DIR）
　問題なし


5.日本語名ディレクトリの作成２（内蔵シェル使用）
　EXECUTE_SH にて、内蔵シェルを起動し、以下のコマンドを実行

　$ mkdir <日本語ディレクトリ名> 

　問題なし


6.日本語名ディレクトリの削除１（DELETE_DIR）
　問題なし


7.日本語名ディレクトリの削除２（内蔵シェル経由１）
　EXECUTE_SH にて、内蔵シェルを起動し、以下のコマンドを実行

　$ rmdir <日本語ディレクトリ名> 

　問題なし


8.日本語名ディレクトリの削除２（内蔵シェル経由２）
　EXECUTE_FILE にて、内蔵シェルを起動し、以下のコマンドを付加して実行

　$ rmdir <日本語ディレクトリ名> 

　問題なし


9.日本語名ファイルの作成(内蔵シェル経由)
　EXECUTE_SH にて、内蔵シェルを起動し、以下のコマンドを実行

　$ touch <日本語ファイル名> 

　問題なし


10.日本語ファイル／ディレクトリ名の変更(RENAME_FILE)

　日本語＞日本語
　日本語＞ascii
　ascii＞日本語

　上記、３パターンをそれぞれ確認。
　問題なし。


11.日本語ファイル／ディレクトリ名の変更(内蔵シェル経由)
　EXECUTE_SH にて、内蔵シェルを起動し、以下のコマンドを実行

　$ mv <日本語ファイル名> <asciiファイル名> 
　$ mv <asciiファイル名>  <日本語ファイル名> 
　$ mv <日本語ファイル名>  <日本語ファイル名> 

　問題なし。


10.カレントファイルを引数として実行１（LAUNCH_FILE）
　問題なし


11.カレントファイルを引数として実行２（VIEW_FILE）
　問題なし


12.カレントファイルを引数として実行３（EDIT_FILE）
　問題なし


13.カレントファイルを引数として実行４（EXECUTE_FILE）

　EXECUTE_FILE にて、内蔵シェルを起動し、以下のコマンドを付加して実行

　$ cat <日本語ファイル名> 

　問題なし


　一応、この patch は内部コードを UTF-8 固定とする adhoc な対応とのことでした
んで、基本的に UTF-8 の日本語ファイル／ディレクトリについてのみ動作を確認して
います。

　おおむね、問題無く動作しているようですが、上記の通り唯一 3. の事例でエラーと
なりました。 5.や 7.のパターンでは正常に動いてるんで、 cd コマンド固有の問題に
なるのかが、微妙なところですね。

　まぁ、 FD 使ってる最中にわざわざコマンドラインから cd でディレクトリ移動なん
かはしないと思うんで(^^;)、実用上はクリティカルな問題かもしれませんが。
　ただこれが本当に cd コマンドだけの問題なのか、それとも他のコマンドでも特定条
件下で発生するのか？、は少し気になるところです。


　さらに、引数のマクロ展開についても試してみました。

　まず、%C、%X、%T等ですが lancher や 内蔵シェル等で”ファイルネームとして”引
数を渡す分には正常に引き渡されます。
　逆に、 patch を当てた状態で FNAMEKCODE=euc に設定し、 euc の日本語ファイルを
扱おうとするとエラーが出ますんで、確かに文字コードが UTF-8 固定でやりとりされ
ていることが分かります。

　ただ、ちょっと色々試してみたんですが、このへん内部の文字コードって完全に UTF
-8 でやりとりされてるんじゃないんでしょうか？。

　んと、例えば現在、 FD 上でマークしているファイルの一覧を取ろうと

　$ echo %T > markfile.txt

とかやってみました。

　この場合、引数がファイルネームであることを特定出来ないパターンなんで、内部の
文字コードがそのまま引き渡ることになると思うんですが、記録された内容を確認する
と日本語が文字化けして記録されてます。
　念の為、ビューワ側で他の文字コードでの表示を試してみましたが、先程の cd コマ
ンドの場合と同じく、文字化けしたままになってます。

　こうなると、単純な文字コードの誤認識と言った問題では無いような気がするんで、
そうなると内部での取り扱いの問題なのかなぁ？、と。

　また、これに付随した問題なのかどうか分かりませんが、 %JS〜JAの文字コード変換
マクロが動作しなくなっています。


　とりあえず、ざっと検証した限りではこんな所です。
　なお、両 patch をそれぞれ単独で当てた場合、両方同時に当てた場合とも確認して
みましたが、特に挙動に差異は見られませんでした。


　他にも、いくつか検証中に気付いたことはあるのですが、このへん正直自分でもどこ
からどこまで報告したら良いものかと・・・。

　個人的な実用の範囲で見るのであれば、状況次第で FD の起動自体が出来ないと言う
ことと、少なくとも FD の画面上から選択出来るファイル名が、引数として正常に外部
アプリケーションに引き渡せないのは致命的だと思います。

　ただ、それ以上に関しては、結局のところ、どこまでを FD に負担させるか？って話
に行き着いちゃう話だとも思うんですよね。

　言うだけなら、いくらでも何とでも言えるわけですが(^^;)。


                                                        TAKETYON こと 武貞一三