いとさん、
たとえば SJIS->UTF-8のテキスト変換をしてディレクトリ／ファイルを作るスクリプトにすれば作れるものは作れます。
Apache(UTF8) の生文字のところは、生のUTF-8なら○でしょう。
日本語の文字を使う時に文字コードを意識するのは大変なので、それぞれのクライアントの文字コードで生のアドレスを書き、ブラウザがURLを適切にエンコードして、受け取ったサーバ側はサーバの文字コードに変換するようにするというのがいいと思っています。
> Linux の %hh のところは、SJISコードの %hh 表記を入れているのではないでしょうか？
はい、「えむけい」をエンコードしたサンプルの「え」を使って以下のようなリンクで試しました。
<A HREF="…/%82%86/…">え(%hh)</A>
<A HREF="…/%E3%81%88/…">え(UTF8)</A>
<A HREF="…/え/…">え(生)</A>
しかし考えてみると、URLで使うコードはサーバ登録したものに合わせないといけないので、Apache(EUC)にアクセスするときには
<A HREF="…/%A4%A8/…">え(%hh-EUC)</A>
としないといけなかったですね。実際これをWinNNで試してみると〇でした。
もう一度整理し直すと、(?)は今すぐテストできないので予想ですが、以下のようになるでしょうか。
-----------------------------------
Webサーバ URL WinNN LinNN URL例
-----------------------------------
Apache(SJIS) %hh-SJIS ○ ○ /%82%86/
生文字 ○ × /え/
-----------------------------------
Apache(EUC) %hh-EUC 〇 〇(?) /%A4%A8/
生文字 × ○ /え/
-----------------------------------
Apache(UTF8) %hh-UTF8 〇(?) 〇(?) /%E3%81%88/
生文字 ×(?) ×(?) /え/
-----------------------------------
AN HTTPD %hh ○ ○ /%82%86/
UTF8 ○ ○ /%E3%81%88/
生文字 ○ × /え/
-----------------------------------
いとさんへ追記。
Linux の %hh のところは、SJISコードの %hh 表記を入れているのではないでしょうか？
EUCコードを %hh にエンコードすべきところではないかと思います。
そうすると、LinNN の %hh の段は上から ×○× となって納得できます。
いとさん、
どうも検証ありがとうございます。
Apacheで(%hhの）UTF-8 が Not Found なのは、Apache が %hh をデコードしているだけだからでしょう。つまり(生の)UTF-8 でファイルを探すので当然ないわけです。
えむけいさんが ftp を例に言っているように、ファイル名を(生の）UTF-8 コードで作っておけばOKになるはずだと思います。
まあ、しばらくの間はいろいろ混在するでしょうから、 AN HTTPD は EUCが(%hhにしろ生にしろ）はいってきてもそれに対応させようとしています。
2バイトパス使用について、Webサーバとブラウザの組み合わせの実態を調べてみました。
特に新しい事実はないかもしれませんが、条件と結果は以下の通りです。
Apache：Apache 1.3.6 on Solaris
S-JIS/EUC：ffftpでサーバ側に作成したディレクトリ、ファイル名の漢字コード
AN HTTPD：v1.27c(v1.28dはバグありなので。v1.27cでもUTF-8は2文字以上不可)
WinNN：Mozilla/4.7 [ja] (WinNT; I)
LinNN：Mozilla/4.08 [muriyari-ja_euc] (X11; I; Linux 2.2.9 i586)
%hh/UTF-8/生漢字：URL中の日本語のコード
×はNot Found
-----------------------------------過去私がどうしても2バイトパスを使わざるを得なかったケースは、CD-ROM内のファイルをブラウザから直にアクセスできるようにしたときくらいだと思います。ただ、Web用にではなく作られたファイルをWebアクセスできるようにするときには、ファイル名を変えずにそのまま使いたいと思いますね。また、URLを%hhにするとわけが分からなくなってしまうので、生漢字を使いたいですね。
Webサーバ URL WinNN LinNN
-----------------------------------
Apache(S-JIS) %hh ○ ○
UTF-8 × ×
生漢字 ○ ×
-----------------------------------
Apache(EUC) %hh × ×
UTF-8 × ×
生漢字 × ○
-----------------------------------
AN HTTPD %hh ○ ○
UTF-8 ○ ○
生漢字 ○ ×
-----------------------------------
>%hh のデコード段階では漢字コードは常にそのままです。
そういう実装もありだと思います。
>となっています。この "a future modification of this specification" というのはもう出ているのでしょうか。。。？
RFC2277により、事前のネゴシエーションが不可能だから将来的にはUTF-8にすべしという解釈は可能かもしれません。
>ブラウザのアドレス指定では生の漢字が使えて HTTPリクエストにする段階でブラウザが適宜エスケープしてくれればいいと思うのですが。
IEはすでにそういう実装です。
むしろftpクライアントが漢字のファイル名をアップロードするとき適宜UTF-8に変換してくれれば8ビット透過でありさえすれば「そのまま」のサーバでもUTF-8が使えるのにとか夢想しています。
%hh のデコード段階では漢字コードは常にそのままです。
たとえば "えむけい" は SJIS の場合、%hh にすると、
%82%A6%82%DE%82%AF%82%A2
ですが、 UTF-8 だと、
%E3%81%88%E3%82%80%E3%81%91%E3%81%84
になりますよね。
AN HTTPD は %hh のデコードはそれぞれ元に戻すだけでその後実際のローカルのファイル名にするときに漢字コードをSJISにしてからファイルのオープンを試みます、というのを「変換する」と言いました。
%hh にエンコードすべしという話と、ファイルパスの漢字コードとは別の話だと思います。
ただし、バージョン1.28d では連続した %hh をうまくデコードできないというとんでもないバグがあります。
RFC2396 では non-ASCII characters について、%hh のエスケープエンコーディングはするとしても、
For original character sequences that contain non-ASCII characters, however, the situation is more difficult. Internet protocols that transmit octet sequences intended to represent character sequences are expected to provide some way of identifying the charset used, if there might be more than one [RFC2277]. However, there is currently no provision within the generic URI syntax to accomplish this identification. An individual URI scheme may require a single charset, define a default charset, or provide a way to indicate the charset used.
It is expected that a systematic treatment of character encoding within URI will be developed as a future modification of this specification.
となっています。この "a future modification of this specification" というのはもう出ているのでしょうか。。。？
ブラウザのアドレス指定では生の漢字が使えて HTTPリクエストにする段階でブラウザが適宜エスケープしてくれればいいと思うのですが。
>AN HTTPD も、UTF-8 は SJIS に変換しますが、他はそのままです。IIS/PWS もそうなのでしょうか。。。？
%hhの形式で送られてきたらUTF-8でエンコードされているとみなして、そうでない場合はそのままのようです。
いずれにしてもRFC2396あたりには非ASCIIの文字をそのままURIに使ってはいけないとか書いていたはずですし。
2バイト文字もそれが使えるシステムであれば問題はないと思いますが、漢字コードの問題はありますね。HTTPサーバの機能としては、漢字コードをそのシステムの漢字コードに変換する機能は持たないでしょうから。
AN HTTPD も、UTF-8 は SJIS に変換しますが、他はそのままです。IIS/PWS もそうなのでしょうか。。。？
一般的には確かに ぴゅあさんの言うとおり、すべてで使えるとは思わない方がいいというのが正解なのでしょう。