2009/09/07 14:38, Tanaka Akira wrote:
> encodeURI の出力から、入力を得るには、無差別に %-encoding を
> 解けばいいので、decodeURI でなくてもいいんじゃないでしょうか。
> decodeURIComponent でもいいですし、CGI.unescape でもかまいま
> せん。
> 
> decodeURI は、encodeURI が生成する %-encoding はすべて解きま
> すが、そうでない %-encoding を一部解かないことがあるようです
> が、これは何の役に立つのかなぁ?
> (例えば、decodeURI("%40") が "%40" になるとか。)

どうも、encodeURI/decodeURI はオレオレ IRI と URI を
相互変換するためのもののようで、引数や結果に一定の仮定が
あるように見えます。

例えば、userinfo に @ が含まれている場合、
それを解いちゃうと解いた結果が IRI っぽい何か的にまずい、とか。

なので、decodeURI が欲しい場合は decodeURI そのものでないと
都合が悪いように思います。
いまさらそんな似非 IRI をサポートする義理はない、
というのも有りだとは思いますが、
まぁ、あえて URI.encode_uri なんていう名前で入れておいても
悪くはないかな、とは感じます。

>> あと、encodeURIComponent()は、その名の通りURIの個々のコンポーネントを
>> 引数に取る事を念頭においた関数で、javascriptではString型しかないから、
>> URIをコンポーネントに分割する責務を利用者に投げている。
>> URI型を作るなら、もうちょっとインテリジェントにやって欲しいという気もしなくはないかも。
>> よく知らないけど、URI.split()があるからには、URIの構造をしってるクラスなんですよね?この人。
> 
> encodeURIComponent は基本的な考え方としては悪くないと思いま
> す。! などがそのままなのは甘いと思いますが、古い RFC の影響
> でしょうね。今だったら unreserved 以外を一律に %-encoding に
> してしまうのがいいでしょう。

HTML5 の 4.10.16.4 URL-encoded form data を見ると、
それに近い動きを言っていますね。
http://www.whatwg.org/specs/web-apps/current-work/#application/x-www-form-urlencoded-encoding-algorithm
SP を + に置換してたりはしますが。

> そういうわけで、URI クラスには、&  と %26 を区別して指定でき
> る API が必要です。そういう API として、文字列の "&" と
> "%26" を受け渡すものが使われているというのが現状でしょう。
> つまり、エスケープ済みのものを渡す、ということです。

直接 URI の query をいじる場合は、引数は基本的にエスケープ済み
を要求することになるのでしょうね。

> たとえば、URI.escape_component というのを考えて、コンポーネ
> ントとしてエスケープするというメソッドとすると、区切り文字に
> なりうる文字をぜんぶエスケープすることになります。
> (URI に入れられない文字もエスケープしないといけないので、結
> 局 unreserved 以外をエスケープするのが適切でしょうが)

まずこういうのは必要でしょうね。

> あるいは、URI.escape_html_form([[k1, v1], [k2, v2], ...]) と
> いうメソッドが、application/x-www-form-urlencoded に従って
> (エスケープして) k1=v1&k2=v2&... という形式を生成するメソッ
> ドだとすると、k, v の中では、query に使えない文字と =,&  を
> エスケープすることになります。(あと + と ; もかな)

これも必要だとは思うのですが、
名前は www_form_urlencode の方がよくありませんか。
www_ は取ってもいいかもしれませんが。
あと、値が String か String の Array な Hash も引数に取れるとか。
# 多くの場合 CGI 等への引数は Hash で得ることができるので、
# それを再度このメソッドに投げ込みたい、とか

-- 
NARUSE, Yui  <naruse / airemix.jp>