[ruby-dev:39256] Re: Is URI.decode() broken?

In article <[e-mail]>,
  KOSAKI Motohiro <[e-mail]> writes:

>> decodeURI は、encodeURI が生成する %-encoding はすべて解きま
>> すが、そうでない %-encoding を一部解かないことがあるようです
>> が、これは何の役に立つのかなぁ?
>> (例えば、decodeURI("%40") が "%40" になるとか。)
>
> ちょっとついていけなかったので保留。
> （たぶん、ruby特有の話なんだと推測）

いや、JavaScript です。

% js
js> decodeURI("%40")
%40
js> decodeURI("%41")
A
js> decodeURI("%25")
%
js> 

えーと、手元のマシンで js の実体は /usr/bin/smjs で、
spidermonkey-bin - standalone JavaScript/ECMAScript (ECMA-262) interpreter
というもののようです。

% js --version
JavaScript-C 1.8.0 pre-release 1 2009-02-16
usage: js [-zKPswWxCi] [-b branchlimit] [-c stackchunksize] [-o option] [-v version] [-f scriptfile] [-e script] [-S maxstacksize] [scriptfile] [scriptarg...]

> そうですね。同意します。
> 理念としては文脈非依存なはずだったのですが、現実のWebでは
> 特にHTTPにおいて、広く文脈依存になっていますね。

いや、URI というのは、reserved な文字の集合に各スキームで
(上位で使っているのと衝突しない文字に) 意味を割り当てていく
というシステムなので、もともと意味の割り当ては状況によって異
なるものなんです。

HTTP の場合、エスケープ済みなものがプロトコルで通信されるの
で、HTTP というスキームがさらに各 web application などに意味
の割り当てを委譲しており、意味の不安定さに拍車をかけていると
いうのはそうなんですが。

> だいたい趣旨は分かりました。
> 上記例のURI.escape_html_form()は見るからに使いにくいので
> これだったらない方がいいと思います。
> で、使いやすさを考えると、もっと上位レイヤ、keyとvalueでモノを考えている
> レイヤでエスケープしないと使いやすさが向上しない。という主張だと
> 受けとめました。

URI.escape_html_form() はそれなりにいいと思いますけどね。

URI.escape_html_form([[k1, v1], [k2, v2]])
というのは
"#{CGI.escape k1}=#{CGI.escape v1}&#{CGI.escape k2}=#{CGI.escape v2}"
に比べて短いですし、= や & という個々の区切りを意識しなくて
済みますから。

また、エスケープ済みなものには少なくとも = が含まれますので、
エスケープ済みであることが値を見るとなんとなくわかるというの
も利点です。二重エスケープを防止するという意味で。あと、入力
が文字列じゃなくて配列であるというのも同様な利点です。

> と考えると、エスケープはRoRのようなレイヤでフォローしてあげるのが
> よいような気もしますね。
> コアライブラリでは、{encode/decode}URIComponent(string) っぽいものだけを
> 用意してあげるのがいいのか、まったく用意しないほうがいいのかはちょっと
> 判断がつきませんが。

application/x-www-form-urlencoded は URI それ自体じゃない、
という意味ではそうかもしれませんが、CGI でもないしなぁ。
定義しているのは HTML ということもできるけれど、HTML という
ライブラリは今は添付してないし、小さいものだし URI におまけ
としてつけとくというのはありうると思っています。
-- 
[田中 哲][たなか あきら][Tanaka Akira]