日本語ファイル名のファイルへのリンクが使えない。

日本語ファイル名のファイルへのリンクが使えない。

- Takahiro Kagoya の投稿
返信数: 56

本日、fs_moodle24-weekly-19_20080405.zip

にアップグレードさせていただきました。その前は2080320を利用していました。

いずれの版でも、日本語ファイル名をアップロードし、そのファイルへのリンクとなるリソースを追加すると、

「申し訳ございません、ファイルが見つかりませんでした。」

と表示されてしまいます。

Win2000Server+IIS+php521という環境です。

moodleのファイル一覧(エクスプロラー?)では、文字化け等していません。

アドバイスをいただけたら幸いです。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

 当方では特に問題が無いですねぇ.
 PHPは5.2.0です.

 IISに起因する問題なのか,どうでしょうか.(当方はApacheを使用しています)

 ブラウザはIE6/7でしょうか.Firefoxでも同様でしょうか?

 リソースの場合はリソースIDの受け渡ししかしていませんので,ファイルの取得の段階でのブラウザの問題とは考えにくいですね.そうなるとリソースを登録した段階でファイル名が不適切なのか?

 もしMoodleのデータベースをphpMyAdminなどのツールで調べられる環境にあるのでしたら,mdl_resourceのreferenceの欄を見て頂けないでしょうか.idで整列させると最後に追加したリソースは一番最後(一番大きなid)にあると思います.このデータベースに登録されているファイル名(referenceの欄))が文字化けしているのであればブラウザーに送り出すことができませんからね.


 日本語ファイル名以外のファイルはリソースとして配置して,表示可能でしょうか.

 日本語ファイル名以外ではOKの場合,日本語フォルダの下にその日本語ファイル名ではないファイルをコピーし,そのファイルをリソースとして指定した場合は如何でしょう?


 もし,IISやPHPのエラーメッセージを見ることが可能ならば,そちらも教えて頂けるとどこが問題なのか少し早く分かるかも知れません.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

 いまリソース(file)のソースを追ってみました.

 データベースから$resourceというデータをガッポリと受け取った後に,ファイルの種類等に応じて色々な処理を行っていますが,最終的には,

// (IE_Problem015): IEでリソースとして日本語ファイル名のファイルを選択するとエラーが発生
//              $relativeurl = "/file.php/{$course->id}/{$resource->reference}";
                $relativeurl = "/file.php/{$course->id}/".fs_rawurlencode($resource->reference);
// (IE_Problem015): ここまで(下のブロックも同様に修正が必要)

のようにfile.phpでダウンロードするように手配を掛けているだけのようですね.(mod/resource/type/file/resource.class.phpの319行あたり).
このファイルを表示するのか,インラインで展開するのか,はともかくとして,$fullurlという変数に$relatieurlその他をくっつけて,redirect($fullurl);しています.
(画像や音楽データやPDFやZIPなどの場合は別の処理)

 ということはです.いまリソースで指定したファイルが画像のファイルではなく,たとえば”特に意味の無いファイル.doc"といったWordのファイルだったとします.ファイルの一覧でこのファイルをクリックしてファイル名が化けずにダウンロードできますか? もしファイル名が化けずにダウンロードできるのであれば出力側ではなくリソースを編集モードで編集してファイル名を割り当てた段階でおかしくなったと考えられますね.


 もう一つ重要な確認事項があります.

 データベースはUTF-8対応でしょうか?

 一つは,config.phpに,

$CFG->unicodedb = true;  // Database is utf8
$CFG->unicodecleanfilename = true;

の指定があること.それともう一つは,phpMyAdminなどで(あ!MySQLではないのでしょうか?),データベースの文字セットが'UTF-8'であることと,接続照合順序が'utf8_unicode_ci'であることを御確認下さい.

 いま調べてみたのですが,IISはWebサーバですね.データベースには何を御使用でしょうか? SQL Server2003? それともMySQLでしょうか.Windows Serverにはとんと疎いものでして.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Takahiro Kagoya の投稿

早速のご返答ありがとうございます。現在コンソールをいじれない(phpMyAdminが未インストールで、普段mysqlのコマンドラインで操作していまして、データベースの内容を確認できない)ので、moodle(Web上)で確認しています。来週には再度コンソールでいろいろとソースの修正なども行います...


こちらの説明が足りていませんでしたので、まず回答させていただきます。

  1. ブラウザはIE7とFirefoxで確認しました。どちらでも症状がでます。
  2. 英数文字のみで構成されるファイルは問題ありません。
  3. 日本語フォルダ下にある英数文字のファイル名の場合は問題があります。
  4. ファイルの選択画面で日本語ファイル名をクリックした場合もファイルの内容が表示できません。
  5. unicodedb、unicodecleanfilenameの設定はしています。ですのでリソースに指定するファイルの選択画面で、(内容はダメですが)ファイル名は問題なく表示されますし、英数文字ファイル名<->日本語ファイル名の双方向のリネーム等も問題ありません。
  6. データベースはmysql 5.0.51a-win32 で、文字セット関係はUTF-8,utf8_unicode_ciにしてあったと思います。
  7. XAMPP版Moodleを別PCに入れ、fs版にアップグレードした方ではこのような問題はなく、日本語のファイル名としてリソースファイルにアクセスできます。



それで、いろいろと試していてわかったことがあります。
まず、リソース(ファイル)へのリンクが「「申し訳ございません、ファイルが見つかりませんでした。」となった場合のURLですが、
たとえば、ファイル名が、「日本語ファイル名.xls」の場合、
https://xxx.xxxx.ac.jp/moodle/file.php/142/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%90%8D.xls
となります。
また、フォルダ名が「ふぉるだ」で、ファイル名が「aaa.xls」の場合、
https://xxx.xxxx.ac.jp/moodle/file.php/142/%E3%81%B5%E3%81%89%E3%82%8B%E3%81%A0/aaa.xls
となります。

これをみていてピンときたことがあります!!
moodle管理画面の「スラッシュを使用する」(slasharguments)がYesになっていることです。これで、上記file.php/142/というように、引数をスラッシュで区切って指定するのかと思いますが、これが、日本語ファイル・フォルダ名の場合にだけ問題があるようです。
slashargumentsをNo(チェックをはずす)にすると、確かに日本語ファイル・フォルダ名に関わらず問題なくダウンロードされます。

WebサーバはIISで、phpはそのモジュール版(isapi版)で動作させているのですが、その場合のPATH_INFO関係の問題でしょうか。
かなり昔に、自分で関連するネタを出していたことを思い出しました。
http://moodle.org/mod/forum/discuss.php?d=13910

phpinfo()を実行するphptest.phpへaaaという引数を渡す場合
https://xxx.xxxx.ac.jp/phptest.php/aaa で、

_SERVER["ORIG_PATH_INFO"] /phptest.php/aaa
_SERVER["PATH_INFO"] /aaa
_SERVER["ORIG_PATH_TRANSLATED"] D:\inetpub\wwwroot\phptest.php\aaa

となりますが、「あああ」という引数を渡した場合、
https://xxx.xxxx.ac.jp/phptest.php/あああ  で、

SERVER["ORIG_PATH_INFO"] /phptest.php/□□□□□□
_SERVER["PATH_INFO"] /□□□□□□
_SERVER["ORIG_PATH_TRANSLATED"] D:\inetpub\wwwroot\phptest.php\□□□□□□

となります。□□□□□□の部分は実際にphpinfoの結果の部分に四角(豆腐?)が並ぶ形で表示されます。


現在コンソールでの確認ができないので、moodledataのフォルダ内のファイルを確認できないのですが、IISとPATH_INFOとの関連による問題だとすると根深い問題になりそうな気がします。

以上、よろしくお願いします。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Takahiro Kagoya の投稿

以下のことも書いておく必要がありました。

/fs_config.phpですが、手元のXAMPP版では以下のようになっています。IISの方にいれた方が今確認できないのですが、たぶん同じだと思います。

$fsCFG->fsCharset = 'SJIS-WIN';
$fsCFG->oldfsCharset = 'UTF-8';
$fsCFG->USEfsPathinfo = true;
$fsCFG->USEextChars = true;
$fsCFG->fswincharset = 'SJIS-WIN';

このあたりの設定を調整すると直るのかもしれません。USEfsPathinfoという設定もあったんですね。後でこれもfalseにして試してみたいと思います。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Takahiro Kagoya の投稿

報告が細切れになってすみません。

今、フォーラムの添付ファイルに日本語ファイル名を試してみましたが、やはりファイル名自体の文字化けはしませんが、そのファイルへのリンクがたどれません。
添付ファイルへのリンクのURLには、日本語ファイル名がそのままはいります。

https://xxx.xxxx.ac.jp/moodle/file.php/92/moddata/forum/385/6959/にほんご.doc

また、ファイルアップロードをするための課題をよういし、課題ファイルを提出してみました。アップロードは問題なくされ、ファイル一覧にちゃんと含まれていませすが、その課題ファイルをクリックしてリンクをたどれません。

https://xxx.xxxx.ac.jp/moodle/file.php/92/moddata/assignment/992/4/にほんご.doc

関係ありそうな記事をみつけました。PHPの521 -> 522へのアップも試す必要がありそうです。新年度の授業がはじまってしまうのですが、間に合うかな...笑顔

http://blog.jojo.jp/?eid=632412

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

 あともう一つ気になったのは,kagoさんの環境ではhttpsを使用されているのですよね?(上記の例でURLがhttps:から始まっていますので,そのように推測しました.ログイン時だけでなく,その後もhttpsを継続して使用するのですよね.この場合にhttpsはどこまで情報を暗号化するのでしょうか.私,ログイン時も含めてhttpsを一度も使ったことが無いのでどのように機能するのかまったく知らないのです.

 もし,URLの末尾につけられる情報や$_GET, $_PUTなどの情報も暗号化されてやりとりされるとして,その復号化時にマルチバイトは影響を受けている,という可能性もありますよね.一度,試しにhttpでアクセスしてみて頂けませんか?
($CFG->wwwrootで指定されているのですよね)

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Takahiro Kagoya の投稿

はい。httpsを利用しています。ログイン時だけではなく、その他の通信時にも。

$CFG->wwwroot で指定している、https://xxx.xxxx.... を http://xxx.xxx.. に代えてみて、SSLで通信しないかたちでのリンクを確認しましたが、ダメでした。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

  ”スラッシュを使用する”ですが,当方のApacheのWindowsXPサーバでYesです.

 あまりいままで意識したことは無かったのですが,この設定のOn / Offによる影響については後日調べてみます.

 pathinfo()ですが,Moodle上では重にサーバPC上のファイルの情報を取得したり,指定したりするのに用いられていました.ですので,basename()の方が多く利用されていたと思います.そしてWindows上の(なんとなく実験に協力して頂いたLinux上でも)日本語を含む場合のpathinfo(), basename()の動きが怪しいのでfs_pathinfo(), fs_basename()といった関数を自作し,fs_moodleでは利用可能としています.それが$fsCFG->UsefsPathinfo(すみません,うろおぼえです)です.この設定をtrueにしておけば,PHPのバージョン等の影響を受けにくいはずです.

 すみません,いまは自宅ですので,今日,kagoさんがトライしてご報告いただいた情報を元にして,月曜日にこちらも調査を行ってみます.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Takahiro Kagoya の投稿

ありがとうございます。

日曜でしたが、出勤していろいろ試してみました。

まず、UsefsPathinfoをFalseにしてみましたが、ダメでした。それと、上のレスで書いたようにhttpsでなくhttpでのアクセスも試してみましたが、ダメです。

moodledataのフォルダ内に、問題なく、日本語ファイル名のファイルがアップロードされています。また、 https://xxx.xxxx.ac.jp/あああ.htm というような直接日本語ファイル名のファイルをおき、アクセスした場合問題なくアクセスできます。

やはり、file.php/ に渡される引数に日本語が含まれる場合に問題がある...というような感じです。その原因がIISにあるのか、そもそもpathinfo()やbasename()の実装に問題があるのかが、まだ分からず...といったところでしょうか。

これまで古いバージョンで運用していた場合には、日本語のファイル名でアップロードすると、リンク先となるファイル名は、文字化け(というか英数文字のみになる)しましたが、リンクは保たれていました。 今回は、ファイルが正しくアップロードされ、表示も問題ないのですが、リンクが辿れない...ということで、教員や学生が安易に日本語のファイルをアップロードしてしまうと教員も学生も確認できなくなってしまうので、ちょっと困ります。

ただ、日本語ファイル名が問題なく使えるようになることは悲願だったので、ぜひなんとか解決したいと思います。白井先生にはお手数かけて申し訳ございませんが、ご指導願いたいと思います。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

 いま自分のサイトに対してWebブラウザ(IE6)で可能なチェックを簡単にしてみたのですが,問題と思われるのはfile.php/のあとのファイル名がURLエンコードされていませんね.ApacheとIISでここの扱いが違うのかも知れません.

 この辺りを中心に調べてみましょう.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

 自宅のWindows2000SP4上のIE6では,file.php/の後のリンクが日本語で表示されていたのですが,いま学校のPC(WindowsXP,IE6/7)上からアドレスを調べてみるとfs_rawurlencode()されていますね.('/'はurlencodeされていない)
 気のせいだったのだろうか???


files/index.php中のdirdisplay()では,IE対策として,UTF-8の文字列(フォルダ名,ファイル名)をfs_rawurlencode()で'/'等以外をrawurlencode()モドキを行なっていますねぇ.ですので,WebサーバからはUTF-8形式を擬似rawurlencode()してブラウザに送り,ブラウザ側はそれをハイパーリンクのアドレスとして,クリックされたらWebブラウザに送り返します(擬似rawurlencode()のまま).IISでは擬似rawurlencode()みたいな変なものは受け付けられないのでしょうか.

php.iniのmagic_quote_gpcをonだoffだ,という議論もあるようですが,当方の環境ではoffになっていました.デフォルトではonのように書いてあるのですが...自分で変えたのかどうか覚えていません(変更した箇所にはコメントを付けるようにしていたのですが...).なお,onにしても変化は認められませんでした.ファイル名に'ソ'などの文字がある時に影響を受けると書いてあったので,意図的に'ソ'を含むフィアル名で試した結果です.apacheもrestartしました.

'スラッシュを使う'のOn/Offも当方の環境では影響無しです.

うーん,IISだけ試しにインストールすることはできないですよね.Windows Serverを買わないと.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Takahiro Kagoya の投稿

文字コードのことをよく理解していないのですが...

先の私の例である、「日本語ファイル」のような場合、

こちら http://urlencode.net/result.cgi で確認した感じだと、

UTF-8で
%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB

S-JISで
%93%FA%96%7B%8C%EA%83t%83%40%83C%83%8B

というエンコードのされかたのようです。

ということは、上のリンクが辿れなかった例の場合、file.phpの以下の処理により、UTF-8で、以下の$pathnameを指定することになるのでしょうか。
$pathname = $CFG->dataroot.$relativepath;

ためしに、
https://xxx.xxxx.ac.jp/moodle/file.php/142/%93%FA%96%7B%8C%EA%83t%83%40%83C%83%8B%96%BC.xls とS-JISでエンコードしたURLでもアクセスしてみましたが、やはり、アクセスできませんでした。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

 ちょっと乱暴ですが,以下,試して頂けませんか?

  moodle/file.phpの冒頭,

    require_once('config.php');
    require_once('lib/filelib.php');

    if (!isset($CFG->filelifetime)) {
        $lifetime = 86400;     // Seconds for files to remain in caches
    } else {
        $lifetime = $CFG->filelifetime;
    }

    // disable moodle specific debug messages
    disable_debugging();

    $relativepath = get_file_argument('file.php');
var_dump($relativepath);
    $forcedownload = optional_param('forcedownload', 0, PARAM_BOOL);

$relativepathに何が受け渡されたのかが見えます.何か”ファイル”からフォルダを辿るなどして,ファイル名をクリックすると(ヘッダーよりも先に文字列を送出するのでエラーになりますが)$relativepathの内容が表示されます.

string(43) "/42/ソート順のテスト/テスト3.zip"
Warning: Cannot modify header information - headers already sent by (output started at C:\xampplite\htdocs\mech\moodle18\file.php:27) in C:\xampplite\htdocs\mech\moodle18\lib\filelib.php on line 346
%PDF-1.2 1 0 obj << /Type ....

こんな感じです.これはコースID42の”ソート順のテスト”というフォルダの下にある”テスト3.zip”というファイルをクリックした場合の例です.このようにUTF-8で化けずに表示されればファイル名の受け渡しまではOKのはずです.  

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

http://oshiete1.goo.ne.jp/qa393705.html

詳細は分からないのですが,URL ScanというソフトがIISのサーバにインストールされていると悪さをするようなことが書いてあります.でも,日本語.htmlは問題ないのですよね.だとしますと別問題かも知れませんが,一応,念のために報告しておきます.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(一歩前進)

- Takahiro Kagoya の投稿

教えていただいた、va_dumpを入れてみました。添付画像の上のようになりました。

やはり、「日本語ファイル名.xls」というファイルへのリンクが文字化けしてファイルシステムに渡されているようです。

最初、バックスラッシュとスラッシュが混在していることが原因かとも疑いましたが、英語のファイル名の場合、以下のように表示され、問題なくダウンロードできることから、関係ないと思いました。やはり、ファイルシステムへ渡されるファイル名の文字コードの問題という感じ。

string(32) "d:\moodledata/142/englishfilename.xls" 

そこで、file.phpにて
$pathname = $CFG->dataroot.$relativepath;
$pathname=mb_convert_encoding($pathname,'UTF-8', "auto");

としてみました。(赤字の行を追加)

すると、var_dumpによる表示($pathname)で文字化けせずに、
"d:\moodledata/142/日本語ファイル名.xls"
とマッピングされました。

しかし、このファイルをIE7でダウンロードする画面になった際、添付画像の下のような表示になり、エンコードされた文字列のままファイルとしてローカルPCにダウンロードしようとしてしまいます。これができるようになっただけでも大助かりです。

もしやと思い、Firefox2で、同じファイルへのリンクをたどったところ、こちらは問題なく「日本語ファイル名.xls」として保存されました。リソースだけでなく、フォーラムの添付、課題のアップロードファイルなども問題ありません。

...となると、今度はブラウザ側の問題との関係でしょうか。

ちょうどいろいろ探していたら、ちょっと前のこれらのスレッドが気になり出しました。

http://moodle.org/mod/forum/discuss.php?d=67425
http://moodle.org/mod/forum/discuss.php?d=72567
http://moodle.org/mod/forum/discuss.php?d=73653

まだ全部読み切れていませんが...関連性がありそうな気がします。

これでFireFox2で問題ないというのはありがたいです。あとは普段学生が使うIE7で問題なければ、ばっちりなのですが。


添付 moodleErrorImage.jpg
Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(一歩前進)

- Tatsuya Shirai の投稿

 つまりfile.phpに渡されるファイル名がS-JISに変換されているようですね.
 files/index.phpのdisplaydir()では単にfs_rawurlencode()しているだけですので,表面上はUTF-8でデータの受け渡しをしているはずです.誰かがUTF-8からS-JISに変換している.IISか?

 受け取ったfile.phpでは,ファイルの有無の確認をfs_is_dir()やfs_file_exists()などのfs関数で行なっていますので,$pathnameがUTF-8形式であるのは正しいです.ですので,kagoさんが行なった(たぶんS-JISから)UTF-8への変換で次のステップに進むことが出来たというのはその証拠です.

 ファイルの有無を確認した後,file.phpは実際のダウンロードをsend_file()という関数に任せます.このsend_file()はUTF-8形式のファイル名を受け取って,それをブラウザの種別に合わせて送出するように改造済みです.これもなんとなくうまく働いていないようですね.


 とりあえずkagoさんの行なったようにUTF-8に変換する処理をfs_moodleに取り込んでも副作用は少ないでしょう.元がUTF-8ならば,UTF-8からUTF-8への変換ですからね.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(一歩前進)

- Tatsuya Shirai の投稿

 憶測ですが,もしかしたらIISにはURLに含まれるUTF-8のデータをシフトJISに変換してしまう機能とかありませんか.サーバ上の日本語.htmlのようなものにアクセスするのに,UTF-8で記述されたhttp://www.mydomain.com/日本語.htmlをアクセスの段階でシフトJISに変換する作業は是非ともお願いしたいところですが,受け取った段階で変換されてしまう,それもPHPのオプションパラメータまで手を入れられると困ったことになります.こういうことが起きているような気がします.

 考えてみたら,機能の制限されたものではありますが,WindowsXPにもIISが存在するのを思い出しました.いまインストールしています.これで何か情報が得られればいいのですが.

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(一歩前進)

- Tatsuya Shirai の投稿

 send_file()に渡されたファイル名(パス名ではなく)はクライアントPCのブラウザがMSIEの場合だけちょっと特殊なことをします.21文字よりも長いファイル名の場合のみS-JISに変換し,そうでない場合はUTF-8のままrawurlencode()します.Firefoxの場合はrawurlencode()しないでUTF-8のままです.

 IE側がエンコードされたファイル名でダウンロードしてしまうのも困ったものですね.

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(解決かも!)

- Takahiro Kagoya の投稿

ありがとうございます。本当に頭の下がる思いです。

いろいろしていたら、解決したかも...と思える状態になりました。

まず、上の記事のとおり、FF2では問題なくIE7で問題がありましたが、以下の処理により、リソース、フォーラムの添付、課題のアップロード、いずれもIE7で正しく日本語ファイル名でダウンロードされるようになりました。

lib/filelib.php の569行目をコメントアウト
// (IE_Problem009): ここから追加
//    $filename = convert_download_filename_encoding($filename);
// (IE_Problem009): ここまで追加

この009の問題というのが、先生のWikiページによると、必要とのことですが、はずして解決しました。文字数の問題に触れているので、ファイル名を30文字以上にしてみましたが、IE7では問題ありませんでした。

逆に、他に影響のでる部分があるのかもしれないのですが、とりあえずなんとかなりそうな気がして歓喜しております。

IISの問題なのかどうか分からずじまいですが、しばらく安心して使えます。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(解決かも!)

- Tatsuya Shirai の投稿

 つまりUTF-8のファイル名のままでもIISを介す場合は問題ないということですね.

 さすがMicrosoft製品,お互いの間では問題解決がされているのかも知れませんね!

 サーバがIISの場合にはkagoさんのされたように,UTF-8への再変換とsend_file()のIEのための偽装を外して良いかどうか,手元のPC(WindowsXP)にインストールしたIISで少し検証してみます.

 とりあえず新年度が無事に迎えられそうですね.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(解決かも!)

- Takahiro Kagoya の投稿

やはりいろいろIISに関連する問題が潜んでいそうですね。

ところで、また、不具合を見つけてしまいました。

課題でのファイルのアップロード(単一のファイル)が問題ないと言っていましたが、昔なかった課題タイプで「高度なファイルのアップロード」というのがありますが、こちらに日本語ファイル名のファイルをアップロードしたときに、表示および実際のファイルシステムへのアップロードは問題ないのですが、リンクをクリックすると、文字化けしてダウンロードされます。

たとえば、「ああああ.doc」という場合、「縺ゅ≠縺ゅ≠.doc」という名前でダウンロードしようとします。(この化けたファイル名のままローカルPCにダウンロード・保存することも可能)

明日再度、ソースを追っかけてみたいと思います。

今ブラウザからわかる範囲でおかしいのは、このリンクが、

https://xxx.xxxx.ac.jp/moodle/file.php?file=/92/moddata/assignment/995/4/%E3%81%82%E3%81%82%E3%81%82%E3%81%82.doc

このように、slashargumentsをyesにしているにもかかわらず、file.php?file= ...というslashargumentsを使わないリンクになっています。

ってことはオリジナルでのバグですかね。

試しに、

https://xxx.xxxx.ac.jp/moodle/file.php/92/moddata/assignment/995/4/%E3%81%82%E3%81%82%E3%81%82%E3%81%82.doc

と修正してアクセスすると問題がありません。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(解決かも!)

- Takahiro Kagoya の投稿

手元にある、XAMPPにインストールしたmoodle1.9 (fs版)でも高度なファイルのアップロードにてアップされたファイルへのリンクは、file.php?file=... となりますね。

しかし、問題なく日本語ファイル名のままダウンロードされます。

  1. そもそも課題の「高度なファイルのアップロード」タイプのリンクの扱いのバグ
  2. IISによる、file.php?file=以下の引数で指定されるファイル名がUTF-8で扱われないことによる問題

という2点について考える必要がありそうです。


と考えていて、mod/assignment/type/uppload/assignment.class.php を眺めていたら、366-367行目に、

//                  $ffurl   = "$CFG->wwwroot/file.php?file=/$filearea/$file";
                   $ffurl   = "$CFG->wwwroot/file.php?file=/$filearea/" . fs_rawurlencode($file);

という行をみつけました。

367行目を
$ffurl   = "$CFG->wwwroot/file.php/$filearea/" . fs_rawurlencode($file);   

としてよいものでしょうか。本当はslashargumentsの設定を考えた処理にすべきだと思いますが。となるとif ($CFG->slasharguments) {}で挟めばいいかの...

ここでこの行の変更については白井先生が触れられていましたね。 http://moodle.org/mod/forum/discuss.php?d=73653

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(解決かも!)

- Takahiro Kagoya の投稿

探していたら、こんなのがありました。あれれ、なんかこのスレと似た流れのような。

http://tracker.moodle.org/browse/MDL-13792

ここの、このパッチがあります。

http://tracker.moodle.org/secure/attachment/13555/patch-urlencode-skodak_18.txt

get_file_urlで、扱う処理にするようです。

この処理は、オリジナルのCVS更新を待つべきでしょうかね。

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。(解決かも!)

- Tatsuya Shirai の投稿

 お,本当ですね.

 Moodle1.8.4+で,3月末頃に,$filenameをurlencode()する表記に変更し,それをまた元に戻したりと,課題関係の箇所に変化が見られました.なんらかの問題意識は芽生えているようですね.

 4月7日のログのようですね.もし多くの処理がget_file_url()にまとめていく方向になるのであれば修正箇所が減る可能性が高くなりますね.


 いまIISの設定中です.moodledataが大きすぎるのでコピーに時間が掛かっています.

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

 file.phpがファイル名の情報を受け取る関数はfunction get_file_argument()で,これはlib/weblib.phpの1304行辺りにあります.いままで私は未チェックでした.

function get_file_argument($scriptname) {
    global $_SERVER;

    $relativepath = FALSE;

    // first try normal parameter (compatible method == no relative links!)
    $relativepath = optional_param('file', FALSE, PARAM_PATH);
    if ($relativepath === '/testslasharguments') {
        echo 'test -1      : Incorrect use - try "file.php/testslasharguments" instead'; //indicate fopen/fread works for health center
        die;
    }

    // then try extract file from PATH_INFO (slasharguments method)
    if (!$relativepath and !empty($_SERVER['PATH_INFO'])) {
        $path_info = $_SERVER['PATH_INFO'];
        // check that PATH_INFO works == must not contain the script name
        if (!strpos($path_info, $scriptname)) {
            $relativepath = clean_param(rawurldecode($path_info), PARAM_PATH);
            if ($relativepath === '/testslasharguments') {
                echo 'test 1      : Slasharguments test passed. Server confguration is compatible with file.php/1/pic.jpg slashargument setting.'; //indicate ok for health center
                die;
            }
        }
    }

    // now if both fail try the old way
    // (for compatibility with misconfigured or older buggy php implementations)
    if (!$relativepath) {
        $arr = explode($scriptname, me());
        if (!empty($arr[1])) {
            $path_info = strip_querystring($arr[1]);
            $relativepath = clean_param(rawurldecode($path_info), PARAM_PATH);
            if ($relativepath === '/testslasharguments') {
                echo 'test 2      : Slasharguments test passed (compatibility hack). Server confguration may be compatible with file.php/1/pic.jpg slashargument setting'; //indicate ok for health center
                die;
            }
        }
    }

    return $relativepath;
}

 青い文字で表した辺りが今回は関わっていると思われるところです.この辺りに的を絞って,IISでもApacheでも互換性のある方法を探ってみましょう.kagoさん,申し訳ありませんが,当方にはIISの環境が無いので,動作確認に付き合って頂けないでしょうか.

Tatsuya Shirai への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Takahiro Kagoya の投稿

ありがとうございます。

ぜひIISでの動作を解決したいのでおつきあい願います。授業が始まり、稼働マシンなので、放課後等リセットの必要がある部分はちょっと確認が遅れますが...

当方のphp.iniをみてみて、関係ありそうな項目だけリストアップしてみます。

;magic_quotes_gpc = On  コメントアウトされています。
default_charset ="UTF-8"
[mbstring]
mbstring.language = Japanese
mbstring.internal_encoding = UTF-8
mbstring.http_input = auto
mbstring.http_output = UTF-8
mbstring.encoding_translation = On
mbstring.detect_order = auto
mbstring.substitute_character = none;
mbstring.func_overload = 0

Takahiro Kagoya への返信

Re: 日本語ファイル名のファイルへのリンクが使えない。

- Tatsuya Shirai の投稿

 当方のphp.iniではこうですね.

; Magic quotes for incoming GET/POST/Cookie data.
;magic_quotes_gpc = On
magic_quotes_gpc = Off

[mbstring]
mbstring.language = Japanese
mbstring.internal_encoding = "UTF-8"
;mbstring.http_input = auto
mbstring.http_output = "UTF-8"
mbstring.encoding_translation = On
;mbstring.detect_order = auto
;mbstring.substitute_character = none;
mbstring.func_overload = 0

ちなみに,mbstring.language = が Xlanguageに変換されているのはMoodleの(セキュリティ上の)都合で,HTMLエディタではlanguageと入力しています.と思ったのですが,化けないですね??? kagoさん,設定をどこかからコピーする際に,Moodle等からコピーしませんでした? その際にXが紛れ込んだ可能性もありますよ.もしここに書き込んだ際に化けたのであれば問題ないのですが.

なんか,私の設定はコメントアウトのままが多いですね^^;

Takahiro Kagoya への返信

IIS5.1でトライ

- Tatsuya Shirai の投稿

 WindowsXP Professional SP2 に IIS5.1 と ISAPI版のPHP (5.2.5)をインストールして見ました.残念ながら(?)現象が再現しませんねぇ.何か設定の違いかも知れませんので,この環境でphp.iniを変更し色々と試してみようと思います.

 何故かIPアドレスでないとアクセスできない(Firefoxは問題なし)現象が発生しています.プロキシを使用しないアドレスにきちんと追加しているはずなのですが...


mysqlのパスワード(2箇所)のみ修正したphp.iniを添付します.

kagoさん,現在御利用のphp.iniとの違いがどこにあるのかチェックしてみて頂けませんか?

Tatsuya Shirai への返信

Re: IIS5.1でトライ

- Tatsuya Shirai の投稿

 なお,FastCGI for IISなるものは使用していません.

 上の,kagoさんが書かれた設定の箇所は同一にしてみました.

 となると,それ以外の箇所ですかねぇ.

 Extensionの辺りはどうでしょう?

Tatsuya Shirai への返信

Re: IIS5.1でトライ

- Tatsuya Shirai の投稿

 スラッシュを使用する,をoffにすると,IEは”ページが見つかりません”のエラーを出しますね.これは別問題?かと思いますが...

 Apacheの場合は特に問題無しです.


後はhttpsの場合ですが...実はどう設定したら良いのかよくわかっていません.

おっと,httpsとhttpは既にkagoさんが試されていますね.


IIS4の時代ですと,逆にURL内の文字データがUTF-8に勝手に変換される問題があったようですね.

http://support.microsoft.com/kb/193812/ja

なんとなく,このような現象が起きているのかなぁと当初は考えていました.ISAPIで特別な処理を行っているのではないか,とも.当方のIIS5.1のISAPIフィルタは,sspifilt, Compression, md5filt, pwsdata, fpexedll.dll の5種類がWebサイトのプロパティのISAPIフィルタの項目にあります.

Tatsuya Shirai への返信

Re: IIS5.1でトライ

- Takahiro Kagoya の投稿

こちら Win2Kserver+IIS5+ISAPI版PHP521です。

まずは、php.iniを添付しておきます。

さほど違いは分からないのですが、extensionはこちらは最低限必要そうなものだけ生かしてあります。

mbstring関係も同じですよね。ただ、先生の方はUTF-8をダブルクォーテーションで囲っていますね。 これ、囲っても囲まなくても同じでしたっけ。 それと、mbstring.substitute_character = none;

それと、PHPのアクセラレータとして、こちらでは、1.9を機にeAccelerator.dllを動かすようにしてみました。

ということで、根本的な違いと思える部分はすくないですね。あるとすると、IISのバージョンやOSの違い程度かもしれません。

Takahiro Kagoya への返信

Re: IIS5.1でトライ

- Tatsuya Shirai の投稿

 限りなくphp.iniの内容を同じにしたのですが,再現しませんね.

 それよりも”スラッシュを使用する”をonにすると,file.php/*** の形式でアクセスすることになるのですが,当方のIISではページが見つかりません,となります.これは根本的に仕方が無いことのように書いてあるページがあり,解決するためにISAPI_Rewriteなるものをフィルタとして導入している事例をいくつか読みました.ちょっと特殊なもののようですので,これをご利用とは思えないのですが,何か似たような物を用いて”スラッシュを使用する”がonにできているのでしょうか?


 やはり”スラッシュを使用する”がOnの状態ではコースのカレントフォルダにある半角英数字だけのファイル名のファイルであってもダウンロードできず,IEは「ページが見つかりません」とエラーを返して来ます.

Tatsuya Shirai への返信

Re: IIS5.1でトライ

- Takahiro Kagoya の投稿

ここの、最後の方に書いたことで...

http://moodle.org/mod/forum/discuss.php?d=13910

IISの.phpのアプリケーションマッピングに「ファイルの存在を確認する」というチェックボックスがあるのですが、これをオフにしないと、file.php/pic.jpg の設定にした場合、ファイルが存在しないというページ(つまり404)が返される。

ということでしょうか。

Takahiro Kagoya への返信

Re: IIS5.1でトライ

- Tatsuya Shirai の投稿

ああ,その設定は確かにチェックを外していませんでした.

そして,「ファイルの存在を確認する」のチェックボックスを外し,”スラッシュを使用する”のチェックボックスを'On'にしたところ,やりましたよ,再現しました!


申し訳ございません、ファイルが見つかりませんでした。
これですね,これ.いやぁ,良かった,再現しましたね.
”スラッシュを使用する”をOffの状態で使えば文字化けはしませんね.
これで,あとはなぜ「ファイルの存在を確認する」をOffにするとおかしくなるのか,だけを調べれば良さそうです.
Tatsuya Shirai への返信

Re: IIS5.1でトライ

- Tatsuya Shirai の投稿

 すこし追い込めて来ましたよ.

 やはりget_file_argument() , lib/weblib.phpが怪しいですね.

 当然ながら,”スラッシュを使う”場合はoptional_param()ではパラメータを受け取れないので,$relativepathは空っぽです.その場合には,

        $path_info = $_SERVER['PATH_INFO'];

を解析しています.無関係だと思っていましたけれど,思いっきりこちらが関係していますね.

 そして,$path_infoを出力すると,これが化けています.

 もしかしたらsend_file()関数に問題があるのかも知れません.

Tatsuya Shirai への返信

Re: IIS5.1でトライ

- Tatsuya Shirai の投稿

 Apacheでは,"スラッシュを使う"がOnでも$_SERVER['PATH_INFO']から生成される$relativepathは化けていません.それに対して,IIS + ISAPI版PHPの場合は,file.phpの冒頭,config.phpが読み込まれる前の段階でvar_dump($_SERVER['PATH_INFO'])をしても化けています.
 ISAPI版PHPの特徴なのか,php.iniなのか,IISならではなのか,この辺に的を絞ってみます.

 files/index.phpが生成するファイルダウンロードのためのリンクをIEの”ソースを見る”で見ても,rawurlencode()されたUTF-8形式でしたので,files/index.phpやsend_file()のせいでは無さそうです.

Tatsuya Shirai への返信

原因ほぼ解明(日本版IISの仕組みの推測)

- Tatsuya Shirai の投稿

 以下の話は推測に過ぎません.

 $_SERVERはWebサーバ(IIS, Apache)が値をセットするようです.
 ここで,IISは日本向けにカスタマイズされていると仮定します.例えば日本語URLへの対応を含めて.Webブラウザから送られてくる'HTTP_ACCEPT_LANGUAGE'や'HTTP_ACCEPT_CHARSET'(IEは送出しない!)の如何に関わらず,IIS(日本版Windows2000/XP/Server用)はPATH_INFOなどのパラメータを強制的にシフトJISに変換してしまうのではないかという疑いが濃厚です.

 IEはIE5より,URLを(サーバへ)UTF-8で送信する,がデフォルトになっていると聞きます.そしてfs_moodleで苦慮したように,日本版Windowsのファイルシステムは原則的にシフトJISです.当然,IIS(Webサーバ)側に保管されるHTMLその他のファイル名/フォルダ名にマルチバイト文字を使う場合,シフトJISで取り扱う必要があります.「HTMLファイルなどの名前には英数文字を使うべき」という原則論は一般ユーザに強制できませんので,IISを使って手軽にWebサーバを構築しようとする日本語WindowsユーザはHTMLファイル名に日本語を使う場合が多々あるでしょう.その際に,PHPやPerlやJavaScriptなどの動的なWebページだけではなく,静的なWebページを作成しても問題にならないように,UTF-8をシフトJISに自動変換する仕組みが日本版IISには仕様として随所に組み込まれているのではないでしょうか.$_SERVERスーパーグローバル変数の要素の一つであるPATH_INFOも同じ理由でUTF-8からシフトJISに(意図的かつ自動的に)変換されていると予想されます.

 Firefoxでは,'HTTP_ACCEPT_LANGUAGE'は日本語抜きに設定することができました.それでも日本版IISはPATH_INFOをシフトJISに変換しています.'HTTP_ACCEPT_CHARSET'からShift-JISを除外することは標準的な操作ではできませんでしたし,そもそもIEは送出していません.したがって,Webブラウザからの制御で,日本版IISがPATH_INFOをシフトJISに変換するのを防ぐことは無理でしょう.
 では,日本版IISがPATH_INFOを御親切にもシフトJISに自動変換するのを何らかの方法で抑制できないのか.IISの設定を見た限りでは分かりません.レジストリを操作することで抑制できるのかも知れませんが,システムを不安定にさせる危険や他のWebサービスに悪影響が生じる恐れがあることを考えると避けなくてはいけない.


 本件を通して日本版IISと日本版IEの間のマルチバイト文字コードの取り扱いが何となく見えてきました.

IE:サーバへの情報の送出はUTF-8で行なうが,サーバから受け取る情報はシフトJISである.

IIS:ブラウザから受け取る情報はUTF-8で受け,ブラウザおよびPHPなどの実行プログラムにはシフトJISに変換して提供する.

 全ては日本語WindowsのファイルシステムがシフトJISである,という点に根源があるようです.


 では,どう対策するか.$_SERVER変数をvar_dump()してみると分かるのですが,

  • $_SERVER['PATH_TRANSLATED']
  • $_SERVER['REQUEST_URI']
  • $_SERVER['URL']
  • $_SERVER['ORIG_PATH_INFO']
  • $_SERVER['PATH_INFO']
  • $_SERVER['ORIG_PATH_TRANSLATED']

以上の変数が自動変換されています.

 もし,URL部に日本語を含む(Moodleの場合は心配しなくて良いでしょう)場合は,

  • $_SERVER['SCRIPT_NAME']
  • $_SERVER['SCRIPT_FILENAME']
  • $_SERVER['PHP_SELF']

も自動変換されます.

 $_SERVER['HTTP_COOKIE']は自動変換などの処理から逃れられているようです.

 Moodleのソースリストの早い段階で,$_SERVER['PATH_TRANSLATED'],_$SERVER['REQUEST_URI'],$_SERVER['URL'],$_SERVER['ORIG_PATH_INFO'],$_SERVER['PATH_INFO'],$_SERVER['ORIG_PATH_TRANSLATED']をUTF-8に再エンコーディングして元に戻す.サーバが日本版IISかどうかは,$_SESSION["SERVER_SOFTWARE"]="Microsoft-IIS/5.1"だけですので判断が出来ませんので,シフトJISからUTF-8と明示しないで,'auto'に任せた方が良いかも知れません.
 場所としては,config.phpで必ず読み込まれるlib/setup.phpの冒頭あたりで手を打つべきでしょうか.あるいはlib/setup.phpから比較的速やかに呼び出されるlib/setuplib.php,fs_moodleですとlib/setuplib.phpの冒頭でlib/fs_moodle/fs_index.phpを読み込みますので,ここで対策を施しても間に合いそうです.

 原因が分からずに対策だけを打つのはイヤでしたが,大体のメカニズムが読めてきましたので,以上の方針でfs_moodleは対策を行ないます.

Tatsuya Shirai への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿

非常に興味深い分析ですね。きっとMoodle以外のCMS・Webアプリ等でも生かされそうです。

Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Tatsuya Shirai の投稿

 本件とは直接の関係はありませんが,以下のマイクロソフト社の資料(日本語)を見つけました.シフトJISを使うメリットとデメリットについても触れられています.

http://download.microsoft.com/download/2/7/1/271f89d1-2be9-44a4-8973-a8130ba98bcf/PHPonWindowsServer2008.pdf

 Microsoftのホームページで検索しても出てきた資料はこれだけですね.
 もし仮定が正しいのであれば影響の大きな仕様ですから,誰かが何かを知っていると思うのですけれども.何か証拠になるような情報はどこかにないでしょうか.

Tatsuya Shirai への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Haruhiko Okumura の投稿
Microsoftがこんなのを出していたのですね。

IISでPHPなんて使う人の気が知れないと思っていましたが(失礼),FastCGIを使えば実用になるということなんですね。
Haruhiko Okumura への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Tatsuya Shirai の投稿
前半部は読んでいなかったので,いま読んでみました.なるほどー.
php.iniの設定のあちこちにあったfastCGIとはこのことだったのですね.

Haruhiko Okumura への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿

ですね。

当方もあっさりLAMPにしてもいいかな...と思わなくもないのですが、それはそれで切り替えが面倒だったり、それに伴う問題なども起こりそうで躊躇しています。

あと、IISを使っているのは、別のWebアプリの都合です。Win+Apacheの方がもしかしたら良いのかもしれないのですが。

FastCGI、んー、まだ内容を理解しきれていませんが、ISAPI版から切り替えて、激変するなら試してみようかな。

Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Haruhiko Okumura の投稿
> 当方もあっさりLAMPにしても

いえ,大切な実験台がいなくなっては困りますので,ぜひIISで悩んでください。 ウインク

Haruhiko Okumura への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Tatsuya Shirai の投稿

 そうですね.Using MoodleのWindows関係のフォーラムを読んでいると,IISを使用している方は結構居ますね.

 IISをちょこっと使ってみた感じでは,導入が楽だなぁと思いました.サーバOSではないWindowsにも(機能が限定されているらしいですが)IISは付いてきますし.一体どのパッケージをインストールしたらいいのだ?とか,英語で書いてあるhttpd.confを試行錯誤しながら(パスの記号は\でいいのかなとか)悩んで設定するのに比べると楽でしたね.フォルダのプロパティというやり方でGUIを用いて設定するので,敷居は低いですね.

 閉じたLAN環境で静的なページのみを用いてWebページを作成するならば,IISも使わないでできますので,”ホームページ”を作る作業も随分と楽になったものです.

Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Tatsuya Shirai の投稿

 では,修正版のlib/fs_moodle/fs_index.phpを添付します.

 IISにて”スラッシュを使用する”をOn, Offにおいて,IE7,Firefoxにて日本語を含むファイルがダウンロード可能であることを確認しました.

 Apacheにて同様にIE7とFirefoxで動作確認しました.

 変換しなくても良いときも変換しています.無駄と思われるかも知れませんが,安全を考えての判断です.


 kagoさん,以前に試された,

lib/filelib.php の569行目をコメントアウト
// (IE_Problem009): ここから追加
//    $filename = convert_download_filename_encoding($filename);
// (IE_Problem009): ここまで追加

ここのconvert_download_filename_encoding()を有効にした上でチェックして頂けませんか? 当方ではこれを生かしておいてもうまくダウンロードできました.もしこれを生かしているとNGであるとするとするならば,また別の現象が存在することになります.

Tatsuya Shirai への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿

試してみました。

行ってみたこと

  1. lib/filelib.php 569行目のコメントアウトを解除(生かす)
  2. IEでダウンロードしようとするファイルの日本語ファイル名がおかしくなることが再現されることを確認
  3. 添付して頂いた、lib/fs_moodle/fs_index.phpに差し替え


IE7とFF2で、リソース、課題、フォーラム添付、について、ファイルのダウンロードダイアログで「保存」については問題ないことを確認しました。

例:「ああああ.docx」(Word2007のファイル)

ただ、いくつか気づいた点があります。

まず、IE7でファイルへのリンクをクリックして表示されるファイルのダウンロードダイアログで、「保存」ではなく、「開く」を選択すると、すぐさま、Wordが起動しますが、そのタイトルバーがエンコードされたままのファイル名となってしまいます。
例:%E3%81%82%E3%81%82%E3%81%82%E3%81%82[1].docx
名前をつけて保存などしようとすると、ファイル名欄にこの文字がまず表示されるので、学生は混乱する気がします。
569行をコメントアウトして、昔のfs_index.phpに戻すと、「開く」でも「保存」でも問題なく、「ああああ.docx」として開きます。

次に、FF2でファイルへのリンクをクリックして表示されるダイアログで、「ディスクに保存する」を選択した場合は問題ないのですが、「アプリケーションで開く」を選択すると、Word2007では開くのですが、「ああああ.docx.doc」と、勝手に拡張子に.docを追加してしまいます。これはもしかするとFF2の問題でしょうか。今回のfs_index.phpの差し替えに関係なく起こっている気がします。Excel2007のファイルの場合、Book1.xlsx.xls となり、開けません。英語のファイル名でも起こるので、今回の日本語のファイル名の問題とは関係ありませんが...別スレッドにすべきかも。

一応、Office2007に対応させるため、IISのmime設定に、
.docxの拡張子のコンテンツの種類として
application/vnd.openxmlformats-officedocument.wordprocessingml.document
と指定しています。
.xlsxや.pptxもMIME設定しています。


ひとまず、コメントアウト+以前のfs_index.phpに戻しておきます。

Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Tatsuya Shirai の投稿

 うーん,残念!

 当方,Office2003しかありませんので,Office2007の圧縮形式のファイルは検証できません.

(1)IE7で「保存」ではなく「開く」でファイル名がエンコードされてしまう問題

 これはApacheでは再現しませんでした.「開く」で,確かにMS-Wordは開くのですが,IEのウィンドウの一つとして組み込まれた状態で開くため,通常のメニューが存在せず名前を付けて保存ができず...と,思ったらウィンドウ右下,F12のところが”名前を付けて保存でした.クリックしたところ,ファイル名の欄にはURLエンコードされていないシフトJISのファイル名がデフォルトとして入っていました.

(2)FF2で「保存」ではなく「アプリケーションで開く」で勝手に拡張子を追加されてしまう.

 当方のFF2の設定ではファイル名をクリックした瞬間にダウンロードしてしまいますので,「ツール」-「オプション」-”コンテンツ”タブ-”ファイルタイプ”の「管理」で,拡張子docのファイルを「規定のアプリケーションで開く」(MS-Word)に変更しました.でも,特に問題ないですねぇ.
 ところが,アップロード済みの拡張子.docのファイルを拡張子.docxに変えたら,仰るとおりの現象が発生しました! アイコンが.docと.docxで異なることから,Moodleの方でファイルの種類を拡張子によって認識しているようです.誰が勝手に.docxに.docを追加しているのかについては,確かに,本家Moodleの方が怪しいですね.


 ファイルがサーバから送られてきた時の挙動の違いが,Offce2003とOffice2007の違いなのか,サーバの違いなのか,あるいはブラウザの設定の違いなのか分かりませんねぇ.あ,試しに以下のアドレスのコースにアクセスして,試して頂けませんか?

こちら:ゲストで入室できます.

 ”特に意味の無いソサンプル.doc” ('ソ'が化けるという噂があったので)と
 ”特に意味の無いソサンプル.docx" (でも中身はOffice2003の.docです)

をアップロードしておきました.

 もしこれで現象が発生しないのであれば,IISの”仕様”か,あるいはIISの設定の違い(mimeの追加など)が影響しているのかも知れません.


 これとは別件になるのですが,上記サンプルのコースにあるZIPファイルを解凍しようとしたらエラーが出て解凍できませんでした.試しに.docファイルをZIP書庫化しようとしたら,これもNotice(一応,圧縮はできましたが).Moodle1.8.4からMoodle1.9にパッチを移植した際に何かミスをしたのか,あるいはPCLZIP関係の本家での修正が悪影響をしているのか.Moodle1.8.5+の方でも試してみます.Windowsで圧縮したファイルをアップロードして展開した時にはNoticeはでなかったのに.

----

Noticeの件は元もとのコードにあった手抜きが原因でした.問題はないですが,気持ち悪いので直します.ZIP書庫の解凍でエラーが出るのはMoodle1.8.5+ (fs_moodle2.4a)でも同じですね.改めてよくチェックしてみます.そういえばあまり関係の無さそうな修正がオリジナルのMoodleのPCLZIP周りにあったような気がします.

Tatsuya Shirai への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿

ご呈示いただいたリンクですが、以下のエラーが出て、学外用のページ http://www.suzuka-ct.ac.jp/mech/moodle/index.php に移ってしまいます。

申し訳ございません、あなたには現在「 ファイルを管理する 」のパーミッションがありません。

こちら
http://www.suzuka-ct.ac.jp/mech/moodle/course/view.php?id=42
に移って、06/5-06/11にある「日本語ファイルへのリソースが正常に動作しない?」を拝見しましたが、これですよね。?
上記サンプルコースの「ファイルの高度なアップロード(課題)のテスト」や、「get_file_url()のテスト」には何もありませんでした。

リンクをIE7とFF2でクリックしてみました。
またまたややこしい話ですが、
IE7では、「特に意味の無いソサンプル.doc」として保存しようとします。「開く」を選ぶと、「特に意味の無いソサンプル.docx」として開かれます。
FF2では、「特に意味の無いソサンプル.docx」として保存しようとします。「開く」を選ぶと、「特に意味の無いソサンプル.docx.doc」として開かれません。
一つのリンクなのに...


話はまた当方のサイトの話にもどりますが、
「ててて.txt」というファイルをアップロードして、FF2でダウンロードしようとすると、「ててて.txt.htm」とまたまた.htm拡張子がつきます。

とうことで、かなり私の頭の中は混乱していますが、一応、Moodle Japaneseでも確認するために、以下の返信でファイルを添付してみます。

Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Tatsuya Shirai の投稿

 すみません,うっかりしていました.

  こちらのリソースでフォルダにアクセスできると思います.

Tatsuya Shirai への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿

ありがとうございます。

まず、IE7で試しました。

docのファイル:
ファイル名をクリックすると、まず背景のみのウィンドウが開きます。そして、ファイルのダウンロードダイアログが開き、「保存」を選択し、保存できます。「開く」を選択した場合、小さなダイアログがさらに出て、開いていますと数秒間出ますが、その後Word2007が起動して開きます。背景のみのウィンドウは残ります。

docxのファイル:
ファイル名をクリックすると、まず背景のみのウィンドウが開きます。そして、ファイルのダウンロードダイアログが開くのですが、すでにそこに示されているファイル名がdocxではなくdocになっています。「開く」を選択した場合、上と同様小さなダイアログがさらに出て、Word2007が起動して開きますが、タイトルバーには拡張子がdocxとなっています。背景のみのウィンドウは残ります。

zipのファイル:
ダウンロードして、Vista標準の「すべて展開」で展開できません。Lhaplusで解凍しようとすると、「テキストファイル"テスト1.zip"の文字コードを変換しますか?」と出て、はいを選ぶのですが、解凍されたファイルやフォルダは見あたりません。


次に、FF2でためしました。

docのファイル:
ファイル名をクリックするとウィンドウは開かず(一瞬でます)、すぐに、「アプリケーションで開く」のか「ディスクに保存する」のか選択するダイアログがでます。「アプリケーションで開く」を選択すると、問題なくWord2007で開きます。「ディスクに保存する」を選択すると、こちらも問題なく保存されます。

docxのファイル:
ファイル名をクリックするとウィンドウは開かず(一瞬でます)、すぐに、「アプリケーションで開く」のか「ディスクに保存する」のか選択するダイアログがでます。ファイル名の拡張子は、docxになっていますが、ファイルの種類がWord97-2003文書として認識されます。(たぶんこれは、サーバー側のMIMEの設定によるものと思われます。)保存した場合は問題ありませんが、開いた場合は、.docx.docと勝手にdocがつきます。

zipのファイル:
IEと同様、ダウンロードしても解凍できないようです。

んー、いろんな原因が混じって問題になっている気がします。MIMEやHTMLのヘッダが原因となっている問題もありそうな。

Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Tatsuya Shirai の投稿

 すみません,テスト.zipの類は私が実験的に拡張子をzipに変えただけのPDFだったようです.(削除して下さい)

 いやぁ,ちょっとビックリしました.

Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿
ああああ.docxのファイルを添付してみます。
Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿
ファイル名の日本語部分が_になってしまいますね。これは昔と同じ。

で、IE7でクリックすると、「開く」も「保存」も問題なし。(ファイル名はつけないといけないけど)
FF2でクリックすると、「保存」は問題なしですが、「開く」だと、.docx.docとなります。やはりこれは、本家の問題のようですね。
Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿
ててて.txtを添付してみます。
Takahiro Kagoya への返信

Re: 原因ほぼ解明(日本版IISの仕組みの推測)

- Takahiro Kagoya の投稿
これだと、FF2でも.htmの拡張子を勝手につけたりはしないようですね。 課題の場合だけ?