[ruby-dev:39270] 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...]

ああ、そういえばECMAScriptの仕様で、uriReserved(*)だったら
％デコードしないんだった。

(*) ECMAScriptでの定義は下記参照、RFC2396当時と合わせているので
    最近のURIのRFCの定義とは違うような記憶ががが

	uriReserved ::: one of
	    ; / ? : @ & = + $ ,


で、意図なんですが（注意、ここから先は大嘘を言っている可能性があります）、
decodeURIの結果にreservedURIが含まれていないと、encodeURI(decodeURI(str)) したときに、
エンコードがうまくいく。って事だったかと。

つまり、ユーザ入力じゃなくて、wikipediaのようなi18nなURIのデコードを
考えているとかじゃありませんでしたっけ？


> > そうですね。同意します。
> > 理念としては文脈非依存なはずだったのですが、現実のWebでは
> > 特にHTTPにおいて、広く文脈依存になっていますね。
> 
> いや、URI というのは、reserved な文字の集合に各スキームで
> (上位で使っているのと衝突しない文字に) 意味を割り当てていく
> というシステムなので、もともと意味の割り当ては状況によって異
> なるものなんです。
> 
> HTTP の場合、エスケープ済みなものがプロトコルで通信されるの
> で、HTTP というスキームがさらに各 web application などに意味
> の割り当てを委譲しており、意味の不安定さに拍車をかけていると
> いうのはそうなんですが。

なんか話が広がってしまった。URIという枠組み、共通項をうだうだやっていた
時は i18n が大きなトピックの内で i18n文字列　←→　ASCIIなURI　と
個々のプロトコル知らなくても、encode, decodeできるってのは目標として
あった気がする。というだけの意図だったのですが



> > だいたい趣旨は分かりました。
> > 上記例の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}"
> に比べて短いですし、= や & という個々の区切りを意識しなくて
> 済みますから。
> 
> また、エスケープ済みなものには少なくとも = が含まれますので、
> エスケープ済みであることが値を見るとなんとなくわかるというの
> も利点です。二重エスケープを防止するという意味で。あと、入力
> が文字列じゃなくて配列であるというのも同様な利点です。

なるほど。入力がStringだと、間違えて連結済み文字列を渡す人が後を絶たないが、
配列なら長さ１の連結文字列を渡す人はまず出ないだろう。という事ですね。
同意します。


> > と考えると、エスケープはRoRのようなレイヤでフォローしてあげるのが
> > よいような気もしますね。
> > コアライブラリでは、{encode/decode}URIComponent(string) っぽいものだけを
> > 用意してあげるのがいいのか、まったく用意しないほうがいいのかはちょっと
> > 判断がつきませんが。
> 
> application/x-www-form-urlencoded は URI それ自体じゃない、
> という意味ではそうかもしれませんが、CGI でもないしなぁ。
> 定義しているのは HTML ということもできるけれど、HTML という
> ライブラリは今は添付してないし、小さいものだし URI におまけ
> としてつけとくというのはありうると思っています。

なるほど