[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: w3m-decode-buffer and handling URIs containing non-ASCII characters
>> On Thu, 27 Sep 2007 20:11:18 +0900
>> 「土」== tsuchiya@xxxxxxxxxx (TSUCHIYA Masatoshi) said as follows:
土> ;; チェックしていませんが，最近の RFC は utf-8 だと言ってましたっけ?
土> w3m-url-transfer-encode-string() は，とりあえずの代替案として，「現在
土> 表示中のページで使われている文字コードでエンコードする」という実装に
土> なっていますが，これは暫定案に過ぎません．
これですが暫定案だと思っていたら，意外にも，割と広く通用しそうだというこ
とに気付きました．
URI に関する RFC3986 の邦訳 <http://www.studyinghttp.net/cgi-bin/rfc.cgi?3986>
によると，
2.3. 非予約文字
URI 内に含む事が認められており、予約目的のない文字は、予約されていな
い(unreserved)と呼ばれる。これは、大文字と小文字のアルファベット、数
字、ハイフン、ピリオド、アンダースコア、チルダが含まれる。
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ということになっていますので，HTML 文書中において，
<a href="サンプル.html"> ‥‥(A)
というような記述をするのは，少なくとも，規格上は認められていないはず(なに
しろ，サンプルという文字は unreserved に含まれていないのですから)．
問題は，(A)のような記述は規格上認められていないので，(A)の記述を escape
するための規格上正しい方法というのは存在しない，ということです．
しかし，RFC3986 の前段
2. 文字
URI 構文は、おそらくリソースを識別するために、データを文字列をしてエ
ンコードする方法を提供する。 URI 文字は、順に、転送や表示のためにオ
クテットに頻繁にエンコードされる。この仕様書では、それらの文字を保存
したり、転送するために使用される URI 文字とオクテットの間のマッピン
グについていかなる特定の文字エンコーディングも強制しない。 URI がプ
ロトコル要素内に現れる場合、文字エンコーディングはそのプロトコルによっ
て定義される; もしそのような定義がなければ、URI は周囲のテキストと同
じ文字エンコーディングであると仮定される。
の記述によると，EUC-JP の HTML 文書中に
<a href="%A5%B5%A5%F3%A5%D7%A5%EB.html">
という指定がある場合に，この URI を「サンプル.html」と unescape するのは，
規格上はおかしくない．
ということは，この仮定を満たすように escape するという方針(つまり，文書ファ
イルの文字コードに基づいて escape するという方針)は，unescape 時に発生す
る問題を避けるためには良い方針である，ということになると思います．
HTTP/1.1 を定めている RFC2616 および，W3C の HTML4 規格も調べたのですが，
URI の文字コードに関しては特に記述はなく，「RFC3986 に従え」としか書いて
いないように見えます．
さんざん調べた結果として，このような解釈にたどり着いたのですが，さて，本
当にこれで良いのかな…?
--
土屋 雅稔 ( TSUCHIYA Masatoshi )