it looks like Crystal URI.escape has the same behaviour as URI.encode_www_form_component in Ruby. why not copy Ruby? it has:

• URI.escape
• URI.encode_www_form_component
• URI.decode_www_form_component

Ruby's encode_www_form_component replaces reserved characters as well.

[Ruby]
URI.encode_www_form_component("https://crystal-lang.org") # => https%3A%2F%2Fcrystal-lang.org
URI.escape("https://crystal-lang.org") # => https://crystal-lang.org (I need this!)

[Crystal]
URI.escape("https://crystal-lang.org") # => https%3A%2F%2Fcrystal-lang.org
URI.escape_uri_safe("https://crystal-lang.org") # => https://crystal-lang.org (My implementation)

I agree that the relation between Ruby's implementation and mine is very confusing.
So if it is ok, I want to rename the original 'escape' method to 'encode_www_form_component' and mine to 'escape'.
On the other hand, I need to keep the backward compatibility.
Any comments?

👍

I wouldn't mind keeping "Ruby compatibility". I'm not sure I understand why so many methods are needed. I see:

URI.escape("https://crystal-lang.org") # => https://crystal-lang.org (I need this!)

Isn't that just the original string? In which case it would make a difference?

Or, another question, when do you need the behaviour of Ruby's URI.escape?

parts of uri paths usually escaped like this:

ruby

URI.escape '/bla-жж/'
=> "/bla-%D0%B6%D0%B6/"

crystal

URI.escape '/bla-жж/'
=> %2Fbla-%D0%B6%D0%B6%2F"

right now crystal URI.escape = CGI.escape, and no method for URI parts escape

I wouldn't mind keeping "Ruby compatibility". I'm not sure I understand why so many methods are needed. I see:

Although I'm quite aware of that and that there are some actual use-cases for URI.escape, I think you would better pay attention to that URI.escape had become obsolete in Ruby many years ago.

http://stackoverflow.com/questions/34274838/why-is-uri-escape-marked-as-obsolete-and-where-is-this-regexpunsafe-constant/34275499

@5t111111 Thank you for the link!

I was also having a hard time imagining a use case for this. For example:

• somebody gives me an URI: it is supposed to be escaped already, right? So nothing to do.
• I want to build an URI from components (host, schema, etc.): I use URI.new, optionally using URI.escape to escape each of the query params.
• Other scenario...?

when you parse uri from html, for example, need to normalize it (escape, and ...)

Another scenario besides creating a URI from individual components is encoding a string which is not directly used in a URI. URI encoding is also relevant for other applications like sending HTTP POST data as x-www-form-urlencoded.

We need the following transformations for strings:

• https://en.wikipedia.org/wiki/Crystal (programming language) => https://en.wikipedia.org/wiki/Crystal%20(programming%20language) (reserved characters are not escaped)
• foo=bar baz&hello/ => foo%3Dbar+baz%26hello%2F (reserved charachters are escaped)

These should be implement in two different methods called encode and encode_www_form (not escape: it is an encoding), as most other API's (except Ruby originally) do:

• Elixir: URI.encode, URI.encode_www_form
• PHP: rawurlencode
• Ruby: CGI.escape, URI.encode_www_form_component
• Javascript: encodeURI, encodeURIComponent

Please note that there are different rules for URI encoding with slight differences. I think it is sufficient to implement only the most recent RFC 3986 (but keep the option to encode space as +)

@tbrand Are you still up for this?

I think we should do something about this. We should have a distinction between encoding an URI (Ruby's URI.encode/URI.escape, which also exists in Elixir) and encoding a query component (Ruby's URI.encode_www_form_component, Elixir's URI.encode_www_form) and we should probably use names similar to Ruby/Elixir.

Also worth noting is that in Ruby, URI.escape/URI.encode is deprecated, and they advise using CGI.escape, which works exactly like Crystal's URI.escape.

So... I guess I don't know. But following what Elixir does seems good and safe.

IIRC I have a branch with a new implementation laying around. I think it was delayed because I did the URI normalize stuff first.