gonzui で、識別子を全て検索のリンクにしたときに、URL のエスケープの問題を見つけた。
gonzui-1.2/gonzui/webapp/markup.rb:81-83
81: query_string = sprintf("%s:%s", tt, text)
82: uri = @search_uri + query_string
83: part = [:a, {:href => uri}, part]
ここで text はソースコード内の関数名であり、@search_uri は ...?q= という URL の前部である。また、tt は fundef や funcall といった検索の種類を表している。
問題は、ここで URL の中に関数名をそのまま入れることである。ただ、これは C のような関数に使える名前が十分に制限された言語では問題にならない。しかし、Lisp のように名前の自由度が大きな言語では問題になる。
具体的に問題の起こる関数名を探したところ、Emacs の float.el というものの中に、f+ という関数が見付かった。
emacs-21.4/lisp/emacs-lisp/float.el:167,181
167: (defun f+ (a1 a2)
...
181: (f+ a1 (f- a2))
へー、Emacs って昔は浮動小数点演算を elisp で実装してたんだ、という話はさておき、 f+ の関数呼び出しをクリックして検索すると、f+ の関数定義を探すべきところが f の関数定義を探すようになっていた。
これは、URL が ...?q=fundef:f+ となって、この query を受け取った側が HTML form としてデコードすると + が space になってしまうからである。
そのため、ここは修正して query_string に form 用のエスケープ関数 (WEBrick::HTTPUtils.escape_form) を適用し、...?q=fundef%3Af%2B という URL を生成するようにした。
さて、ここで疑問に思ったのが、+ だけでなく : もエスケープされてしまうというところである。エスケープされて URL がわかりにくくなってしまっているが、これをエスケープするのは本当に必要だろうか?
というわけで、ひさしぶりに RFC:3986 と HTML4.01 を眺めて考えてみる。
考えた結果、: はエスケープしないでよいという結論に達した。
というか、一般に form の値でエスケープしないといけないのは &, ;, =, +, #, %, [, ], space, 非ASCII printable 文字だけでいいんじゃないだろうか。(= は微妙なところだが)
RFC:3986 の仕様は、文字列の上に URI という構文を定義している。そして、その構文に対して意味も定義している。もちろん全ての意味を定義しているわけではなく、ごく基礎的な部分だけである。
その基礎の上に、HTML4.01 は form への入力を URI の query として表現する方法を定義している。
そして、各 web application は各 application で扱う意味を URI や form の上に表現する方法を決めるわけである。
ここで、RFC:3986 自身が query に定義している構文と意味は次の通りである。
・ 構文: *( unreserved / pct-encoded / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" / ":" / "@" / "/" / "?" )
・ 意味: unreserved な文字は percent encoding してもしなくても意味が変わらない
ここで、unreserved は ALPHA / DIGIT / "-" / "." / "_" / "~" であり、また、"!" から "?" は reserved の部分集合になっている。
そして、HTML4.01 は query の中身を [&;] で区切った name=value の並びとし、また + は space を意味すると定義している。つまり、RFC:3986 が用意してくれた reserved の中で query に使える文字 (percent encoding するかどうかで意味が変わっても良い文字) のうち、&, ;, = , + を使って (name, value) という対の並びを表現するということである。
ここでデリミタに reserved 内の文字を使っているのはそれらの文字をデリミタとしてでなく表現するのに percent encoding を使えるようにするためである。もし、unreserved 内の文字をデリミタにしたとすると、percent encoding してもしなくても意味が変わらないという定義により、デリミタでない意味を表現する方法を何か他に考えなければならなくなる。
さて、やっと本題の : であるが、これは RFC:3986 の定義からすると query 内に使ってよい文字で、percent encoding するかどうかで意味が変わって「も」よい文字である。
しかし、HTML4.01 form では、: はデリミタとしては使っていない。そして RFC:3986 では、デリミタとして使っていない文字はその文字自身を意味するとして扱うと定義されている。従って、form の場合は percent encoding するかどうかでは意味は変わらない。つまり、form に使うときには : をエスケープする理由はない。 (むろん、エスケープしてはいけない理由もない - URL の美しさを除けば)
というわけで、form 用のエスケープ関数は form で使用しているデリミタ以外は reserved であってもエスケープしないでもよさそうである。
逆に、reserved 全てをエスケープする関数の用途は、使われる文脈が不明でもともかくその文字自身の意味として扱わせるというものになる。しかし、使われる文脈が不明という状況はどのくらいあるのだろうか。あまりないような気がするので、そういう関数は使いにくく (長く) しておいてもいいかもしれない。危険ではないのでそれほど使いにくい必要はないが。
さて、では、エスケープ関数はどういう API がいいだろうか。
まず、現在のエスケープ関数はたいてい文字列を受け取って文字列を返す関数であり、どうも使い分けが難しい。実際、space を表現する + を使えないところで使ってしまうケースを何回か見たことがある。
これをどうにかしたいと以前から思っているのだが、form を扱っているという文脈をもっと利用するといいのではないだろうか。
つまり、form が生成するのと同様な URL を生成するときに form 用のエスケープ関数が必要になるわけで、そのエスケープ関数が呼ばれるときには、多くの場合、呼出元では (name, value) 対の並びをもっていて、順にエスケープして & ないし ; でつなぐという処理をしているわけである。とすると、(name,value)対の並び自体を受け取って、全部エスケープしてつないで返すというのがいいのではなかろうか。
こうすることによる利点はいくつも考えられる。
・ いままでよりも多くの処理をライブラリにまかせられ、簡単になる。
・ 受け取る引数の型が違うので、単純な文字列のエスケープと間違いようがない。
まぁ、間違いを防ぐという意味ではどこでも使える確実なのをひとつ使いやすいところにおいておく (reserved 全てを percent encoding するのを短い名前で用意する) という方法も考えられるのだが、そうすると percent encoding が余計に行われるので、URL が汚くなる。
URL はユーザインターフェースの一部であり、そこを不要に汚すのはよろしくない。
なぜ WEBrick::HTTPUtils#escape_form は (私の視点からすると) 余計にエスケープするのだろう? コードを読んでみよう。
ruby-1.8.4/lib/webrick/httputils.rb:344,350,352-354,364,377-381
344: reserved = ';/?:@&=+$,'
...
350: control = (0x0..0x1f).collect{|c| c.chr }.join + "\x7f"
...
352: delims = '<>#%"'
353: unwise = '{}|\\^[]`'
354: nonascii = (0x80..0xff).collect{|c| c.chr }.join
...
364: UNESCAPED_FORM = _make_regex(reserved+control+delims+unwise+nonascii)
...
377: def escape_form(str)
378: ret = _escape(str, UNESCAPED_FORM)
379: ret.gsub!(/ /, "+")
380: ret
381: end
ふむ。unwise ってことはRFC:3986じゃないな。RFC:2396か。
こっちの視点からすると、&;=+#%[] だけでいいわけだが、それらを含むのは、reserved, delims, unwise にわかれていて、ちょうどそれだけという集合がない。もちろん、それだけの集合を決定するためには HTML form の知識を使わないといけないので、URI の RFC に載っていたら逆に変なわけだけど。にもかかわらず、reserved とかの定義された集合の和でエスケープすべき文字を定義しているから、余計なのまで含めてしまう、というわけかな。
