[#39222] [Bug #2036] AIX 5L 5.2にて、ruby-1.8.7-p174のビルド時にmake testをするとエラーになった。not ok float 7 -- ./sample/test.rb:1232 — 和弥 寺元 <redmine@...>

Bug #2036: AIX 5L 5.2にて、ruby-1.8.7-p174のビルド時にmake testをするとエラーになった。not ok float 7 -- ./sample/test.rb:1232

13 messages 2009/09/03

[#39249] [Bug #2060] DLをCからRubyに変換する事を勧めます — Aaron Patterson <redmine@...>

Bug #2060: DLをCからRubyに変換する事を勧めます

10 messages 2009/09/07

[#39282] [Bug #2067] bodyが大きいエラーページをopen-uriで取得するとfdがリークしている — takeru sasaki <redmine@...>

チケット #2067 が更新されました。 (by takeru sasaki)

15 messages 2009/09/10
[#39283] Re: [Bug #2067] bodyが大きいエラーページをopen-uriで取得するとfdがリークしている — Yukihiro Matsumoto <matz@...> 2009/09/10

まつもと ゆきひろです

[#39284] Re: [Bug #2067] bodyが大きいエラーページをopen-uriで取得するとfdがリークしている — Nobuyoshi Nakada <nobu@...> 2009/09/10

なかだです。

[#39297] Re: [Bug #2067] bodyが大きいエラーページをopen-uriで取得するとfdがリークしている — Yukihiro Matsumoto <matz@...> 2009/09/10

まつもと ゆきひろです

[#39298] Re: [Bug #2067] bodyが大きいエラーページをopen-uriで取得するとfdがリークしている — Tanaka Akira <akr@...> 2009/09/10

In article <E1MliJq-0000yc-4o@x61.netlab.jp>,

[#39302] Re: [Bug #2067] bodyが大きいエラーページをopen-uriで取得するとfdがリークしている — takeru sasaki <sasaki.takeru@...> 2009/09/10

言いだしっぺの佐々木です。

[#39307] Re: [Bug #2067] bodyが大きいエラーページをopen-uriで取得するとfdがリークしている — Yukihiro Matsumoto <matz@...> 2009/09/10

まつもと ゆきひろです

[#39345] [Bug #2111] Error:test_rm_f(TestFileUtils) — Kazuhiro NISHIYAMA <redmine@...>

Bug #2111: Error:test_rm_f(TestFileUtils)

11 messages 2009/09/17

[#39352] [ruby19] Thread 切替えが異常に遅い? — Hidetoshi NAGAI <nagai@...>

永井@知能.九工大です.

12 messages 2009/09/20

[#39367] Almost endless loop of BigMath::atan(x) when x.abs >= 1 — "Masahiro Kanai (CanI)" <cani.m.61st@...>

金井 仁弘と申します。

13 messages 2009/09/23
[#39980] Re: Almost endless loop of BigMath::atan(x) when x.abs >= 1 — TOYOFUKU Chikanobu <nobu_toyofuku@...> 2010/01/07

豊福です。遅い反応ですが。

[#39982] Re: Almost endless loop of BigMath::atan(x) when x.abs >= 1 — TOYOFUKU Chikanobu <nobu_toyofuku@...> 2010/01/07

豊福です。

[#39388] Re: [ruby-cvs:32331] Ruby:r25113 (trunk): String#inspect's encoding should be fixed. — "Martin J. Dürst" <duerst@...>

成瀬さん、こんにちは。

9 messages 2009/09/28

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

From: "Martin J. Dürst" <duerst@...>
Date: 2009-09-09 11:11:56 UTC
List: ruby-dev #39275

On 2009/09/08 13:59, Tanaka Akira wrote:
> In article<20090908093235.0CC3.A69D9226@jp.fujitsu.com>,
>    KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>  writes:
>
>>> decodeURI は、encodeURI が生成する %-encoding はすべて解きま
>>> すが、そうでない %-encoding を一部解かないことがあるようです
>>> が、これは何の役に立つのかなぁ?
>>> (例えば、decodeURI("%40") が "%40" になるとか。)
>> ちょっとついていけなかったので保留。
>> (たぶん、ruby特有の話なんだと推測)
>
> いや、JavaScript です。
>
> % js
> js>  decodeURI("%40")
> %40
> js>  decodeURI("%41")
> A
> js>  decodeURI("%25")
> %

一般の文字 (unreserved, a-zA-Z0-9など) はエスケープしてもしなくても同じ 
のはず。したがって %41 -> A はいつでも可能です。URI の文法内に意味をなす 
文字 (delimiters) はエスケープされたものとエスケープされてないものでは意 
味が違いますので、いつでも変換できるとは限られません。たとえば
http://example.com/abc#def と http://example.com/abc%23def は根本的に違 
います。前者では #def は fragment で、後者では abc#def という path (ファ 
イルまただディレクトリなど) である。無差別に %23 -> # をするのは間違いで 
ある。decode でもどの部分を decode するによっていろいろ違ってくる。

以前ちょっと考えたのはその辺を第二の引数で指定できるようなメソッドでし 
た。引数には「これだけは decode しないで」、「(delimiter/reserved の内) 
これだけは decode して」、「この部分用なので、適当にやってくれ」という三 
種類を考えたが、どちらの方がいいのか結論は出してないです。encode の方で 
は同様なことが考えられる。ある意味では JavaScript の encodeURI と 
encodeURIComponent が、二つ目の引数が与えられる選択肢の幅の両端に当たる 
かもしれません。

少し例を挙げますと、

encode系:
'abc#def', :path -> abc%23def # path 内には # はそのまま使えない
'abc#def', :fragment -> 'abc#def' 又は 'abc%23def' # fragment 内では # 
も %23 も同様
'abc#def', :uri -> 'abc#def' # URI 全体では # は fragment 前の区切りなの 
で、%23 はだめ

それ以上考えるのは今日は残念ながら遅すぎます。


もうひとつ、URI::Generic.build など先ほどみたときに考えた。引数の数がや 
たら多く、多くの場合、固定の部分がかなりあるのではないかと思いました。そ 
ういうことを考えると例えば
URI::Generic.build 'http://www.google.com/search', query: '2+3'
で http://www.google.com/search?q=2%2B3 を作ってもらえるのでしたら、

URI::Generic.build 'http', '', 'www.google.com', '', '', 'search', '', 
'2+3', ''
よりかなり便利のではないでしょうか。

よろしくお願いします。   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

In This Thread