[ruby-core:29414] Re: URI.(un)escape deprecated?

Hi,

On Sat, Apr 10, 2010 at 4:30 AM, NARUSE, Yui <[e-mail]> wrote:
> If the use case of URI.unescape is to show a human readable format,
> why escaping is needed?

To do the reverse: to allow a user to enter a human readable format
for a URL and convert it to the format the internet requires.

In most if not all browsers, if I type in
"http://example.com/?name=Marc André+42", this string will be
URI.escaped and used for http request.

So any application that requests a URL from its user needs URI.escape.

> If it is the use case of URI.unescape, the algorithm of it should follow
> web browsers, doesn't it? Try make a link and mouse over following url;
> You'll find some of them aren't decoded.
> http://www.google.com/search?hl=en&q=%2F%3F%23%25%2B%26

Indeed, Safari and Chrome do not. It can definitely be argued that
Firefox is mistaken, because the shown string doesn't round trip. If
you type it in the URL bar, you will not get to the same URL.

> Decoding URI is difficult problem and at least URI.unescape is not enough.
> HTML5/IRI-bis people seem discussing about related this, like
> http://lists.w3.org/Archives/Public/public-iri/2010Apr/0006.html
> But if we follow, it must cause breaking compatibility.

I will not argue that URI.{un}escape could be improved/modified.

I will argue that we must find a better solution that deprecating a
useful method before any replacement is available.

We don't even know what the future api will be, right?

What do you think of the following:
URI.{un}escape are renamed URI.{un}escape_chars (or percent_{de/en}code)
URI.{un}escape become aliases
URI.{un}escape_uri will become available as soon as possible, with the
desired treatment (will it translate "http://www.xn--e5h.com/" <=>
"http://www.♀.com/" ?)

This keeps full compatibility, makes the distinction clearer,
continues to provide a usefull feature, and gives us time to spec and
implement the new feature.

---
Marc-André